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?


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

Richard wrote:
> 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.


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

Hi 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


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

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.

On Fri, Jun 20, 2008 at 8:18 AM, Florian Grandel <jerico.dev@gmail.com> wrote:
> Hi 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
>


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

On Tue Jun 24 09:39, Richard Cole wrote:
> 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.

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

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

> 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
javaepends substvar to satisfy the Classpath manifest item in any
jars in the package.

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

Not many, but we need to have more (-:

> [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 wrote:

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



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

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.


On Tue, Jun 24, 2008 at 10:05 AM, Matthew Johnson <mjj29@debian.org> wrote:
> On Tue Jun 24 09:39, Richard Cole wrote:
>> 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.
>
>> 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.
>
>> (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.
>
>> 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
> javaepends substvar to satisfy the Classpath manifest item in any
> jars in the package.
>
>> 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?
>
> Not many, but we need to have more (-:
>
>> [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)
>
> iD8DBQFIYSlv2XtckeYvo1gRAmcPAKCXSp3n0zj2gwv8gc0Psa llwAykLQCgqQE7
> So4TccJOPgwIbmWNxRiXVDY=
> =8g5h
> -----END PGP SIGNATURE-----
>
>


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

On Sun Jun 29 15:04, Richard Cole wrote:
> 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

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

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.

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

> 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

On Sun, Jun 29, 2008 at 11:56:52PM +0100, Matthew Johnson wrote:
> On Sun Jun 29 15:04, Richard Cole wrote:
> > 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


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

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.

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


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