On Sun Jun 29 23:25, Richard Cole wrote:
>
> 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)/*

> 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
javaepends=junit

> 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.

> >> 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

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. 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


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

Hi Matthew,

Matthew Johnson schrieb:

It's unclear to me what they want to be configured at runtime by
changing the classpath.


I'll ask them and report back.


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.

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.


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&rele ase_id=548923



--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Matthew,

Matthew Johnson schrieb:

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


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, June 30, 2008 14:26, Matthew Johnson wrote:
>
> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Matthew,


Matthew Johnson schrieb:

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


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org