Discussion:
Developing with Java on Debian
(too old to reply)
Richard
2008-06-20 04:34:10 UTC
Permalink
This is a bit of a newby question.

What I'm wondering is whether one can use the debian package system as
a kind of build system. Let me illustrate with an example, say for
example I want to write an app and package it with debian and this app
uses Hibernate, then I would like to declare a dependency on the
hibernate libary package and start developing in eclipse right away.

Right now I see that hibernate is available as a library package that
has put jars in /usr/share/java. If I depend on these jars and write a
unit test I discover that there are more dependencies, I need some of
the apache commons libraries and the log4j library, but I can't see
those as dependencies.

I'm guessing what I want is a vanilla java library debian source
package and a plugin for eclipse that understands how to read the
build dependencies, but I would not like to have to rediscover the
dependencies of the hibernate, they should have been specified by the
package maintainer for that system, and I should get them for free.

I would also be nice to be able to get the source in a package called
for example: libhibernate3-java-dev or libhibernate3-java-dbg that
would make go-to-definition work much better in eclipse.

Is any of this possible with Debian? What should I be reading? Are
there examples I can look at? Are there forums where the strategy for
java and debian is being discussed?
Andrew Haley
2008-06-20 10:54:34 UTC
Permalink
Post by Richard
This is a bit of a newby question.
What I'm wondering is whether one can use the debian package system as
a kind of build system. Let me illustrate with an example, say for
example I want to write an app and package it with debian and this app
uses Hibernate, then I would like to declare a dependency on the
hibernate libary package and start developing in eclipse right away.
Right now I see that hibernate is available as a library package that
has put jars in /usr/share/java. If I depend on these jars and write a
unit test I discover that there are more dependencies, I need some of
the apache commons libraries and the log4j library, but I can't see
those as dependencies.
So report a bug against the hibernate package: it certainly should
require all of its dependencies.

Andrew.
Gianluca
2008-06-20 13:30:27 UTC
Permalink
Hi,
in Ubuntu 8.0.4 I installed Eclipse and I used OpenJdk to compile my
program described here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484273
If I make java-jar MyRecipes.jar on the shell, it works perfectly. But if I
click the mouse right on jar files and select "open with OpenJdk Runtime"
the program does not work. . Why?
thanks for any answers.
Regards
Paul Wise
2008-06-20 23:31:09 UTC
Permalink
Post by Gianluca
in Ubuntu 8.0.4 I installed Eclipse and I used OpenJdk to compile my
OpenJDK is not available in Debian yet.
Post by Gianluca
If I make java-jar MyRecipes.jar on the shell, it works perfectly. But if I
click the mouse right on jar files and select "open with OpenJdk Runtime"
the program does not work. . Why?
Sounds like a bug in the Ubuntu OpenJDK package, please file a bug in Launchpad.
--
bye,
pabs

http://wiki.debian.org/PaulWise
Florian Grandel
2008-06-20 15:18:24 UTC
Permalink
Hi Richard,
Post by Richard
Right now I see that hibernate is available as a library package that
has put jars in /usr/share/java. If I depend on these jars and write a
unit test I discover that there are more dependencies, I need some of
the apache commons libraries and the log4j library, but I can't see
those as dependencies.
Are you speaking about declaring dependencies within Eclipse
(=configuring the project's build path)?

Or are you speaking about missing jar-packages required for the
hibernate package on the Debian package layer?

In the second case, if there are dependencies that have not been
automatically installed on the system you should probably file a bug as
Andrew said.

In the first case however (which I think you were talking about) I don't
know about an Eclipse plugin that is capable of interpreting Debian
package dependencies and "importing" them as build path dependencies to
Eclipse. The only thing I can think of is that you manually look at the
package dependencies (either through a script using dpkg or through
Synaptic GUI -> package properties) and see which jars or sources have
been installed by packages depending on the library you are interested in.

If you are an advanced scripter you might write a script that updates
your .classpath-File in the Eclipse project folder based on information
retrieved from Debian packages. I'd be really interested if you invented
something like this. It might even not be very hard to do it that way. :-)

Florian
Richard Cole
2008-06-24 16:39:40 UTC
Permalink
So I'm still wondering how the packaging of java packages in Debian works.

Lets say that I do some more research on Hibernate and discover it
really cannot run without Log4j because classes in Hibernate directly
reference Log4j. [1] Then I submit a bug report and the dependency
gets added. Where's the classpath? Are there any tools for (i) working
out whether a classpath is closed with respect to resolution of direct
class references [2], (ii) do java libraries in debian express their
classpath? Should they have a classpath, something like
/usr/share/java/hibernate-annotations-1.2.jar.classpath ?

My guess is that if we had (i) and (ii) we would not be very far from
(a) an automated way to verify package binary correctness, and (b) an
automated way to infer dependencies that integrates with debhelper and
cdbs.

Storing classpath's in addition to package dependencies would allow
for finer grained dependencies, e.g. if package X provides jars A and
B, and Y has a jar C that needs A, then Y requires X, but the
classpath for C would mention just A (and we would close the
classpaths before using them).

I'm new to Debian packaging, still trying to understand and practice
packaging, so I'm wondering if I'm thinking in the right direction.
Are there records of discussions had by the java packaging team at
Debian?

regards,

Richard.

[1] A side question on policy here, should I submit a bug report with
some limited knowledge, or should I wait and research the issue in
detail before submitting a bug report?

[2] .i.e. if one class references another class directly, not through
a string or some such, then we should be able to resolve that class
with the classpath.
Post by Florian Grandel
Hi Richard,
Post by Richard
Right now I see that hibernate is available as a library package that
has put jars in /usr/share/java. If I depend on these jars and write a
unit test I discover that there are more dependencies, I need some of
the apache commons libraries and the log4j library, but I can't see
those as dependencies.
Are you speaking about declaring dependencies within Eclipse (=configuring
the project's build path)?
Or are you speaking about missing jar-packages required for the hibernate
package on the Debian package layer?
In the second case, if there are dependencies that have not been
automatically installed on the system you should probably file a bug as
Andrew said.
In the first case however (which I think you were talking about) I don't
know about an Eclipse plugin that is capable of interpreting Debian package
dependencies and "importing" them as build path dependencies to Eclipse. The
only thing I can think of is that you manually look at the package
dependencies (either through a script using dpkg or through Synaptic GUI ->
package properties) and see which jars or sources have been installed by
packages depending on the library you are interested in.
If you are an advanced scripter you might write a script that updates your
.classpath-File in the Eclipse project folder based on information retrieved
from Debian packages. I'd be really interested if you invented something
like this. It might even not be very hard to do it that way. :-)
Florian
Matthew Johnson
2008-06-24 17:05:51 UTC
Permalink
Post by Richard Cole
So I'm still wondering how the packaging of java packages in Debian works.
Hi, I am very interested in improving the state of Java packaging in
Debian. In fact, I have written a set of tools to help with it which do
some of the things you described below. Have a look at
javatools/javahelper.
Post by Richard Cole
Lets say that I do some more research on Hibernate and discover it
really cannot run without Log4j because classes in Hibernate directly
reference Log4j. [1] Then I submit a bug report and the dependency
gets added. Where's the classpath? Are there any tools for (i) working
out whether a classpath is closed with respect to resolution of direct
class references [2],
I was looking at the problem of automatically constructing classpaths,
which is intractable because there are jars with duplicate classes in
them. However, javahelper has a script which guess a classpath based on
that, but which needs checking. It's called java-propose-classpath.
Post by Richard Cole
(ii) do java libraries in debian express their
classpath? Should they have a classpath, something like
/usr/share/java/hibernate-annotations-1.2.jar.classpath ?
Currently there is no policy that libraries should include the Classpath
manifest item for recursive dependency resolution. I think this is
definitely something we should do. At the moment people are constructing
the entire classpath in their wrapper scripts, which needs to pain,
suffering and unneeded transitions. It also allows people to use a tool
such as jarwrapper to launch Java programs via executable jar files,
rather that with wrapper scripts.
Post by Richard Cole
My guess is that if we had (i) and (ii) we would not be very far from
(a) an automated way to verify package binary correctness, and (b) an
automated way to infer dependencies that integrates with debhelper and
cdbs.
I have written such a tool in javahelper. jh_depends will set the
java:Depends substvar to satisfy the Classpath manifest item in any
jars in the package.
Post by Richard Cole
I'm new to Debian packaging, still trying to understand and practice
packaging, so I'm wondering if I'm thinking in the right direction.
Are there records of discussions had by the java packaging team at
Debian?
[1] A side question on policy here, should I submit a bug report with
some limited knowledge, or should I wait and research the issue in
detail before submitting a bug report?
You can always add followups to the bug report, so there's no reason not
to submit it earlier.

Matt
--
Matthew Johnson
Richard Cole
2008-06-29 22:04:50 UTC
Permalink
I've started looking into javahelper, very nice package.

I tried to package a small library (jarjar) following the javahelper
tutorial but I got stuck. I was trying to build with sun-j2sdk1.6. I
tried calling jh_build from debian/rules:

jh_build jarjar.jar src/main

jh_build then tried to call javac src/main, but javac said that
src/main was an invalid flag. It seems that you have to list all the
java files to be compiled when you call the sunjava version of javac.

So it seems that most software in debian is being compiled with
java-gcj. Is there a significant difference in the class files that
are produced by java-gcj and sunjava? Is java-gcj the current
preferred compiler in debian by virtue of it being open source? Is
anyone thinking of ways to select either a java-gcj or sunjava built
system? Are their issues mixing jars from the two compilers? How
stable is java-gcj?

Is there any plan to integrate javahelper with common debian build
system, so that one can reduce the size of ones debian/rules files?

regards,

Richard.
Post by Matthew Johnson
Post by Richard Cole
So I'm still wondering how the packaging of java packages in Debian works.
Hi, I am very interested in improving the state of Java packaging in
Debian. In fact, I have written a set of tools to help with it which do
some of the things you described below. Have a look at
javatools/javahelper.
Post by Richard Cole
Lets say that I do some more research on Hibernate and discover it
really cannot run without Log4j because classes in Hibernate directly
reference Log4j. [1] Then I submit a bug report and the dependency
gets added. Where's the classpath? Are there any tools for (i) working
out whether a classpath is closed with respect to resolution of direct
class references [2],
I was looking at the problem of automatically constructing classpaths,
which is intractable because there are jars with duplicate classes in
them. However, javahelper has a script which guess a classpath based on
that, but which needs checking. It's called java-propose-classpath.
Post by Richard Cole
(ii) do java libraries in debian express their
classpath? Should they have a classpath, something like
/usr/share/java/hibernate-annotations-1.2.jar.classpath ?
Currently there is no policy that libraries should include the Classpath
manifest item for recursive dependency resolution. I think this is
definitely something we should do. At the moment people are constructing
the entire classpath in their wrapper scripts, which needs to pain,
suffering and unneeded transitions. It also allows people to use a tool
such as jarwrapper to launch Java programs via executable jar files,
rather that with wrapper scripts.
Post by Richard Cole
My guess is that if we had (i) and (ii) we would not be very far from
(a) an automated way to verify package binary correctness, and (b) an
automated way to infer dependencies that integrates with debhelper and
cdbs.
I have written such a tool in javahelper. jh_depends will set the
java:Depends substvar to satisfy the Classpath manifest item in any
jars in the package.
Post by Richard Cole
I'm new to Debian packaging, still trying to understand and practice
packaging, so I'm wondering if I'm thinking in the right direction.
Are there records of discussions had by the java packaging team at
Debian?
[1] A side question on policy here, should I submit a bug report with
some limited knowledge, or should I wait and research the issue in
detail before submitting a bug report?
You can always add followups to the bug report, so there's no reason not
to submit it earlier.
Matt
--
Matthew Johnson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIYSlv2XtckeYvo1gRAmcPAKCXSp3n0zj2gwv8gc0PsallwAykLQCgqQE7
So4TccJOPgwIbmWNxRiXVDY=
=8g5h
-----END PGP SIGNATURE-----
Matthew Johnson
2008-06-29 22:56:52 UTC
Permalink
Post by Richard Cole
I've started looking into javahelper, very nice package.
I tried to package a small library (jarjar) following the javahelper
tutorial but I got stuck. I was trying to build with sun-j2sdk1.6. I
by which you presumably mean sun-java6-jdk, if you haven't noticed that
it's now in non-free
Post by Richard Cole
jh_build jarjar.jar src/main
jh_build then tried to call javac src/main, but javac said that
src/main was an invalid flag. It seems that you have to list all the
java files to be compiled when you call the sunjava version of javac.
Hmm, I remember changing something related to that. But I can't now find
it. Indeed you are correct, GCJ does what you would expect and Sun javac
does not. I shall change it to find | xargs, but be annoyed at having to
do so. There doesn't seem to be a way (afaict) to compile more java
files than will fit on a command line, which is a bit of a pain.

The fix will be in the next upload.
Post by Richard Cole
So it seems that most software in debian is being compiled with
java-gcj. Is there a significant difference in the class files that
are produced by java-gcj and sunjava? Is java-gcj the current
preferred compiler in debian by virtue of it being open source? Is
anyone thinking of ways to select either a java-gcj or sunjava built
system? Are their issues mixing jars from the two compilers? How
stable is java-gcj?
The only difference is the default version of class file produced. As
long as you are producing class files of at most as new a version as
your runtime supports, it doesn't matter which compiler you use. Since
it is only compiled to byte code there is not much of an issue of
optimization either. The main difference is whether there are any
language features etc which you use that gcj doesn't support yet. It is
pretty good with 1.5 features, but as yet does not have a class library
with generics to compile against, so using generics from the standard
library won't work (but will in your own classes).

Of course, the main difference is that if you compile with gcj the
package can go in main, not contrib. openjdk should fix that. Generally
we recommend building with gcj (or, rather, default-jdk) where possible.
Post by Richard Cole
Is there any plan to integrate javahelper with common debian build
system, so that one can reduce the size of ones debian/rules files?
Well, it is already as terse as debhelperized packages (which amount of
code I personally like). If someone who knows cdbs would like to
integrate it into there I would be more than happy, however, I don't
know cdbs and therefore cannot do so myself.

Matt
--
Matthew Johnson
Michael Koch
2008-06-30 05:58:09 UTC
Permalink
Post by Matthew Johnson
Post by Richard Cole
I've started looking into javahelper, very nice package.
I tried to package a small library (jarjar) following the javahelper
tutorial but I got stuck. I was trying to build with sun-j2sdk1.6. I
by which you presumably mean sun-java6-jdk, if you haven't noticed that
it's now in non-free
sun-j2sdk1.6 is the package generated by java-package. If you want to
really epend on a propriatory JDK please use sun-java6-jdk instead.


Cheers,
Michael
Richard Cole
2008-06-30 06:25:38 UTC
Permalink
To better understand debian packaging java libraries I used javahelper
to package joda-time which is a pretty nice date-time library for
java.

I've put my effort at:

deb http://debian.richcole.org.s3.amazonaws.com unstable/
deb-src http://debian.richcole.org.s3.amazonaws.com unstable/

You can't get a directory listing there, so here's the contents:

2$ s3cmd ls s3://debian.richcole.org/
Bucket 'debian.richcole.org':
2008-06-30 05:35 570 s3://debian.richcole.org/unstable/Packages
2008-06-30 05:35 434 s3://debian.richcole.org/unstable/Packages.bz2
2008-06-30 05:35 422 s3://debian.richcole.org/unstable/Packages.gz
2008-06-30 05:35 1523 s3://debian.richcole.org/unstable/Release
2008-06-30 05:35 529 s3://debian.richcole.org/unstable/Sources
2008-06-30 05:35 412 s3://debian.richcole.org/unstable/Sources.bz2
2008-06-30 05:35 392 s3://debian.richcole.org/unstable/Sources.gz
2008-06-30 05:35 1592
s3://debian.richcole.org/unstable/joda-time_1.5.2-1.diff.gz
2008-06-30 05:35 685
s3://debian.richcole.org/unstable/joda-time_1.5.2-1.dsc
2008-06-30 05:35 1017
s3://debian.richcole.org/unstable/joda-time_1.5.2-1_i386.changes
2008-06-30 05:35 1270854
s3://debian.richcole.org/unstable/joda-time_1.5.2.orig.tar.gz
2008-06-30 05:35 1434758
s3://debian.richcole.org/unstable/libjoda-time-java_1.5.2-1_all.deb


I'd be pleased if you (the collective of debian java packagers) would
look over what I've done and provide comments, hints and suggestions.

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.

I presume that the standard java class loader honours the classpath in
the MANIFEST. Is that right? Should javahelper be adding junit.jar to
the classpath.

I choose not to use the ant-script that came with Joda-time but
instead used the java-helper primitives.One issue I encountered was
that joda-time generates timezone files as part of the build process
using itself and then includes those in the jar. You'll see that I
call jh_build twice, one to build the jar, then again to package the
jar after adding the generated timezone files.

At this stage I just tested with gcj.
Post by Michael Koch
by which you presumably mean sun-java6-jdk, if you haven't noticed that it's now in non-free
sun-j2sdk1.6 is the package generated by java-package. If you want to
really epend on a propriatory JDK please use sun-java6-jdk instead.
Ah, I hadn't noticed that it was in non-free now. I presume this means
I can get rid of java-package and the packages it produced and swap to
the sun-java6-jdk.

regards,

Richard.
Matthew Johnson
2008-06-30 11:03:06 UTC
Permalink
Post by Richard Cole
I'd be pleased if you (the collective of debian java packagers) would
look over what I've done and provide comments, hints and suggestions.
Well, some general observations just looking at the packaging. There is
a built jar in the source, which isn't a problem, as long as it _has_
source (which it does) and you don't use it during the build (or rebuild
it first, which you don't). You have also missed changing some of the
templates such as the javadoc author and the ITP close, but you were
presumably leaving those until later.

In the rules file you do:

jh_build -o-nowarn joda-time.jar src/*
mkdir -p $(TZ_DEST_DIR)
java -cp joda-time-1.5.2.jar org.joda.time.tz.ZoneInfoCompiler -dst $(TZ_DEST_DIR) -src $(TZ_SRC_DIR) $(TZ_ZONES)
jh_build -o-nowarn joda-time.jar src/*

You should use joda-time.jar not joda-time-1.5.2.jar, since the former
is the one built from source. You should also call a specific version of
Java, not which ever is first in path. If you are setting JAVA_HOME for
jh_build, then $JAVA_HOME/bin/java is correct.

I also think it would be better to manually add the classes to the jar
with fastjar uf joda-time.jar <files>, in which case those lines become
something like:

jh_build -o-nowarn joda-time.jar src/*
$JAVA_HOME/bin/java -cp joda-time.jar org.joda.time.tz.ZoneInfoCompiler -dst $(TZ_DEST_DIR) -src $(TZ_SRC_DIR) $(TZ_ZONES)
fastjar uf joda-time.jar $(TZ_DEST_DIR)/*
Post by Richard Cole
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.
I presume that the standard java class loader honours the classpath in
the MANIFEST. Is that right? Should javahelper be adding junit.jar to
the classpath.
Yes, it does and javahelper provides a couple of ways of doing so.
jh_build should add it automatically. If you used the ant script then
jh_manifest can be used to add it to the jar afterwards.

In fact, testing it here, it does:

$ jar xf joda-time.jar META-INF/MANIFEST.MF
$ cat META-INF/MANIFEST.MF
Class-Path: /usr/share/java/junit.jar

This also causes junit to be added to the depends (and so, you don't
need it in your debian/control file):

$ cat debian/libjoda-time-java.substvars
java:Depends=junit
Post by Richard Cole
I choose not to use the ant-script that came with Joda-time but
instead used the java-helper primitives.One issue I encountered was
that joda-time generates timezone files as part of the build process
using itself and then includes those in the jar. You'll see that I
call jh_build twice, one to build the jar, then again to package the
jar after adding the generated timezone files.
At this stage I just tested with gcj.
I had some problems building, but I appear to have a broken installation
of gcj on the machine I have available to test at the moment. As you
say, this is a slightly unusual build, so it will not fit exactly with
the simple work flow in javahelper.
Post by Richard Cole
Post by Michael Koch
by which you presumably mean sun-java6-jdk, if you haven't noticed that it's now in non-free
sun-j2sdk1.6 is the package generated by java-package. If you want to
really epend on a propriatory JDK please use sun-java6-jdk instead.
Ah, I hadn't noticed that it was in non-free now. I presume this means
I can get rid of java-package and the packages it produced and swap to
the sun-java6-jdk.
Yes, you can.

Hope those comments were useful,

Matt

--
Matthew Johnson
Richard Cole
2008-07-01 08:04:08 UTC
Permalink
Thanks Matt for taking the time to look through my package. Your
comments helped a lot. I've updated the package:

deb http://debian.richcole.org.s3.amazonaws.com unstable/
deb-src http://debian.richcole.org.s3.amazonaws.com unstable/

in line with your suggestions. I had originally mistakenly believed it
was building correctly but it was using the jar that came with the
source to create the timezone files rather than the built jar. (Hence
my confusion about the classpath in the manifest :)

After fixing that issue the process to generate the timezone files
bombs out with

[java] Exception in thread "main" java.lang.ArithmeticException:
Adding time zone offset caused overflow

This only occurs when running with gcj on the built jar, a jar built
with gcj but run on the sun jvm on the other hand succeeds. It is also
the case that gcj requires a modification to one of the source files
to compile (it has to do with a class extending Calendar which
implements Comparable<Calendar>)

I wonder if the exception I'm getting is due to me having chosen a bad
version of gcj or whether for the time being its a showstopper for
compiling with gcj. To make some progress time being I changed the
dependency to sun-java6-jdk.

I went to create an ITP and discovered that joda-time has already been
packaged. Somehow I missed it previously. Credit to reportbug for
asking me to search :)

The current version of the package (libjoda-time-java) doesn't build
on my system. It gets the same exception as I listed above when trying
to generate the timezone files.

If an existing package doesn't build at what point is it a bug. Should
it build in the current version of testing? Is there any system that
regularly tests that existing packages are still buildable? Or is it
developers who test? I guess if it built and the tests ran before and
now it doesn't then its more likely the latest version of gcj that is
to blame.

regards,

Richard.
Florian Grandel
2008-06-30 13:01:07 UTC
Permalink
Hi Java developers,
Post by Richard Cole
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. 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.
* It can not be configured.

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]

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.

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. Maybe it's just a
configuration error on my side. I also found
http://www.kirkk.com/main/Main/JarAnalyzer. Looks promising as it should
give you all dependencies in one run. Has anybody of you already used this?

Cheers,

Florian


[1] http://www.jpackage.org/jpprequest.php
Matthew Johnson
2008-06-30 13:26:45 UTC
Permalink
Post by Florian Grandel
Hi Java developers,
Post by Richard Cole
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.
Post by Florian Grandel
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
"Do not use Class-Path references in MANIFESTs
* 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.
Post by Florian Grandel
* It can not be configured.
It's unclear to me what they want to be configured at runtime by
changing the classpath.
Post by Florian Grandel
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.
Post by Florian Grandel
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.
Post by Florian Grandel
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
Florian Grandel
2008-06-30 14:18:16 UTC
Permalink
Hi Matthew,
Post by Matthew Johnson
It's unclear to me what they want to be configured at runtime by
changing the classpath.
I'll ask them and report back.
Post by Matthew Johnson
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.
Ok, that makes sense to me.
Post by Matthew Johnson
Post by Florian Grandel
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.
Sorry, didn't know that. It must be a Ubuntu-only package then.
Post by Matthew Johnson
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.
Sure. The problem occurred for me when I tried to build the jbossmq.jar
in the jbossas4 package. To reproduce you'd have to download the jboss
source code package from [1].

This package comes with a lot of binaries (which we are now replacing by
jars built from source). Extract all the jars from the source package
and put them in one directory. Then try to establish the dependencies of
jbossmq.jar. It has a build dependency on jboss-j2ee.jar which doesn't
show up for me when I analyze jbossmq.jar. All other dependencies are
correctly discovered.

Rgds,

Florian

[1]
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=548923
Florian Grandel
2008-06-30 16:43:33 UTC
Permalink
Hi Matthew,
Ah, hmm, I think it only looks in /usr/share/java, since this was a tool
for Debian, and thats where all our jars are stored.
I forgot to mention that I modified your script to look into "my"
directory. This is a very simple modification and makes your script
_very_ useful to analyse not-yet-installed package dependencies during
packaging. This should therefore not be the problem. And as I said, your
script correctly retrieves the dependencies on other packages that are
included in "my" directory.

My modification is hardcoded so not very useful as a general patch to
your script. If you like you might add a parameter to your script that
allows addition of further jar repositories to be included in the
analysis. I think this would be useful for other packagers as well.

Rgds,

Florian
Florian Grandel
2008-07-04 03:38:28 UTC
Permalink
Hi Matthew,

I am currently trying to use your jh_manifest script. I have the
following problem however:

The standard ant jar task creates a manifest with an empty line at the
end. If I apply jh_manifest this empty line remains untouched and leads
to the following MANIFEST.MF (jh_manifest added the lines starting with
Main-Class and below):

"Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 4.2.3 (Ubuntu 4.2.3-2ubuntu6) (Free Software Foundation, I
nc.)

Main-Class: com.kirkk.analyzer.textui.DOTSummary
Debian-Java-Home: /usr/lib/jvm/java-gcj
Class-Path: /usr/share/java/bcel.jar /usr/share/java/regexp.jar
/usr/share/jaranalyzer/jaranalyzer.jar"

Executing "java -jar jaranalyzer-1.2.jar" then generates the following
error:

Exception in thread "main" java.io.IOException: invalid manifest format
at java.util.jar.Manifest.read(Manifest.java:225)
at java.util.jar.Manifest.<init>(Manifest.java:69)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:177)
at java.util.jar.JarFile.getManifest(JarFile.java:163)

When I manually delete the empty line, the error disappears and the main
class is correctly executed.

How do you work around this problem when building your jars with
<jar...> + jh_manifest?

Bye,

Florian
Matthew Johnson
2008-07-04 07:46:00 UTC
Permalink
The standard ant jar task creates a manifest with an empty line at the end.
If I apply jh_manifest this empty line remains untouched and leads to the
following MANIFEST.MF (jh_manifest added the lines starting with Main-Class
Ah, that is, indeed, a bug. I'll fix it in the next upload

Matt
--
Matthew Johnson
Florian Grandel
2008-07-11 18:32:50 UTC
Permalink
Hi Matthew,
Post by Florian Grandel
Post by Matthew Johnson
It's unclear to me what they want to be configured at runtime by
changing the classpath.
I'll ask them and report back.
I talked about the classpath issue with the jpackage guys. We didn't go
into detailed arguments as it is a minor policy issue that doesn't
concern my current work too much and may be easily switched when
changed. They just said that they still maintain the policy and that
they may respond themselves here on the list. They are subscribed.

Florian

Paul Cager
2008-07-01 11:19:46 UTC
Permalink
Post by Matthew Johnson
Sufficiently clever build systems should propagate the build CLASSPATH
to the manifest automatically anyway.
I'm a bit confused by this. Doesn't that assume that the build and runtime
classpaths are identical?
--
To UNSUBSCRIBE, email to debian-java-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
David Herron
2008-06-24 17:52:39 UTC
Permalink
Post by Richard Cole
So I'm still wondering how the packaging of java packages in Debian works.
Lets say that I do some more research on Hibernate and discover it
really cannot run without Log4j because classes in Hibernate directly
reference Log4j. [1] Then I submit a bug report and the dependency
gets added. Where's the classpath? Are there any tools for (i) working
out whether a classpath is closed with respect to resolution of direct
class references [2], (ii) do java libraries in debian express their
classpath? Should they have a classpath, something like
/usr/share/java/hibernate-annotations-1.2.jar.classpath ?
The current state doesn't (so far as I understand) seem very good since
the idea is to put jars under /usr/share/java or perhaps
/usr/share/xyzzy and the package probably works out the classpath based
on assuming everything is there.

However I've been talking with the people who are developing the modules
support planned for Java 7 (JSR 277). Something I've asked them is how
this should play out for the linux distros (in general).

What they're telling me is it will be possible for a distro (e.g.
Debian) to have a module repository built into the packaging system.
With that the Java runtime would be automatically able to handle a lot
of this for you.

This will require some kind of glue layer (service provider
implementations) to interface ... But that's Java 7, and by the
statement we made at JavaOne last month it won't be available until
mid-2009.

As for today...

http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html
http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html

Jar files can directly express their classpath requirements using the
Class-Path entry in the JAR manifest. I suppose the debian packaged
jar's could interpolate their dependencies into these JAR manifest
entries. No need for a separate file.


- David Herron
Florian Grandel
2008-07-04 04:58:33 UTC
Permalink
Hi Matthew,

I have further researched this problem. To me it seems a (not too
trivial) bug in jh_manifest. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489214. Maybe better to
discuss the topic there to keep this list clean...

Cheers,

Florian
Continue reading on narkive:
Loading...