[fedora-java] [mjj29 at debian.org: Re: Developing with Java on Debian]

[Andrew Overholt]

Has anyone from JPackage or Fedora spoken with the Debian java people?

----- Forwarded message from Matthew Johnson <mjj29 at debian.org> -----

> From: Matthew Johnson <mjj29 at debian.org>
> To: Florian Grandel <jerico.dev at gmail.com>
> Cc: debian-java at lists.debian.org
> User-Agent: Mutt/1.5.17 (2007-11-01)
> Date: Mon, 30 Jun 2008 14:26:45 +0100
> Subject: Re: Developing with Java on Debian
> X-Mailing-List: <debian-java at lists.debian.org> archive/latest/9812
> 
> On Mon Jun 30 10:01, Florian Grandel wrote:
> > Hi Java developers,
> >
> >> One problem that I haven't solved so far is how to get the classpath
> >> into the MANIFEST file as was proposed earlier in this thread.
> >
> > As you may have remarked from my earlier posts I am working with the 
> > JPackage guys recently. Their "recommendation to Java developers" arguments 
> > against adding classpaths to the manifest. 
> 
> Well, they are wrong.
> 
> > Probably the first three arguments do not apply to the Debian
> > environment, but the last one may. I have not yet made up my mind on
> > that. I just didn't want you to loose their arguments:
> 
> > "Do not use Class-Path references in MANIFESTs
> >
> > The Class-Path system of MANIFESTs is evil because:
> >
> >     * It doesn't work with JDK 1.x.
> >     * It only works at runtime, not at build time.
> >     * It only works for a specific installation hierarchy.
> 
> These are, as you say, not relevant for Debian. I particularly like the
> second point, since their solution of wrapper scripts means maintaining
> two lists of classpath, one in the build system and one in the wrapper
> _anyway_. The specific installation heirarchy thing is interesting. The
> wrapper script is going to have to have _some_ guess at the heirarchy
> and if that doesn't work you are just pushing the problem of creating
> the classpath onto the user, which is clearly bad.
> 
> Sufficiently clever build systems should propagate the build CLASSPATH
> to the manifest automatically anyway.
> 
> >     * It can not be configured.
> 
> It's unclear to me what they want to be configured at runtime by
> changing the classpath.
> 
> > Wrapper scripts are much versatile and universal. We provide a set of 
> > convenient shell helper functions for setting up such Unix scripts easily 
> > (see jpackage-utils in project CVS)." [1]
> 
> Wrapper scripts without classpath manifest items also result in
> large classpaths containing items you shouldn't have to know about (your
> dependencies' dependencies) and causes unnecessary transitions when
> these change.
> 
> > You may also have a look at their build support system as they have some 
> > quite useful helper scripts as well. jpackage-utils is available in 
> > universe/contrib.
> 
> But not available in Debian.
> 
> > And as Richard was asking earlier how to identify dependencies within jar 
> > packages: I am using Matthew's java-propose-classpath a lot and it works 
> > fine (Thank you Matthew!). But sometimes it seems to miss some 
> > dependencies, I have not yet found out why.
> 
> Hmm, if you can give me a test case, I'd be very interested. It
> _should_ only suffer from giving you too many dependencies when there
> are multiple jars containing the same class.
> 
> Matt
> -- 
> Matthew Johnson



----- End forwarded message -----