[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: java dependency substvars and native compilation

On Thu May 03 00:00, Paul Cager wrote:
> Thanks for submitting this idea - you've reawakened my interest in
> compiling a "Java Packagers Wishlist"!
> I think the idea of writing a program to determine Jar dependencies is a
> good one, but I'm not sure it can ever be fully automatic, for the
> reasons Michael has given above. As such I don't think it would be
> appropriate to make it a debhelper dh_xxxxxx command - these are
> expected to work flawlessly without the need for any user "tweaking".
> But I think your idea would work very well if integrated into "dh_make".
>  The expectation of dh_make is that it will make a good "first draft"
> which must then be tweaked by the user. (Assuming dh_make is ever
> enhanced to recognise Java packages of course).

It's a tricky one. A debhelper command in debian/rules is exactly where
it _ought_ to be. Does dh_shlibs not have similar problems which they've

> I've got a couple of queries about your program:
>   * It's getting late so I may have misread the regular expressions, but
> are you only searching for a matching _class_ name (without the package
> part). E.g. org.codehaus.plexus.classworlds.realm.Entry might match
> against org.someone.else.Entry? Or have I misunderstood your RE?

No, it matches the whole path to the package (actually uses the internal
package/class representation, which is convenient for finding them in

>   * Using the "strings" command seems to me a bit unsafe, in that you
> could get false positives if there are (normal) strings that end in
> "class". I'm not sure if that is a real-life concern, or just my
> over-active imagination.

Not even that, anything that matches identifier/..../identifier. Ideally
I'd write (not in bash) a real byte-code parser which can find the class
references properly. This was just a first cut to find what the issues
were though.

> At this point I should probably confess that I've written a fairly
> similar utility myself. It generates a package cross-reference as an
> HTML file, and has its own set of problems - e.g. if more than one Jar
> provides a class. I've never got around to finishing it, so it's a bit
> rough around the edges.

cool (-:

The other thing I wondered about was a pkg-config-alike for making it
easier to write wrappers for Java programs. It would generate the
correct classpath for the libraries you use. Something like:

#!/bin/sh --

java -cp `pkg-config --classpath libcvs-java libunix-java`:/usr/share/java/myprogram.jar org.me.MyProgram "$@"

Incidentally, is:

   java -cp <a bunch of jars> -jar <my program jar> 

meant to work?

Attachment: signature.asc
Description: Digital signature

Reply to: