Re: Developing with Java on Debian
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
> java:Depends 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)
>
> iD8DBQFIYSlv2XtckeYvo1gRAmcPAKCXSp3n0zj2gwv8gc0PsallwAykLQCgqQE7
> So4TccJOPgwIbmWNxRiXVDY=
> =8g5h
> -----END PGP SIGNATURE-----
>
>
Reply to: