[fedora-java] [mjj29@debian.org: Re: Developing with Java on Debian]
Has anyone from JPackage or Fedora spoken with the Debian java people?
----- Forwarded message from Matthew Johnson <mjj29(a)debian.org> -----
From: Matthew Johnson <mjj29(a)debian.org>
To: Florian Grandel <jerico.dev(a)gmail.com>
Cc: debian-java(a)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(a)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 -----