Package: java-propose-classpath Severity: wishlist X-Debbugs-CC: Dmitry Smirnov <only...@member.fsf.org>
On 2012-02-09 12:00, Dmitry Smirnov wrote:
> Dear Niels and Java Maintainers,
>
Hi,
Sorry for the late reply. With this mail I will open a bug for this. I
will mark you as the submitter when I get the bug id. I am also
(re-)attaching your script, so we have it in the bug log.
> Let me thank you sincerely for your work.
>
Thanks, though if you are talking about "java-propose-classpath", I
believe you want to thank Matthew Johnson. :)
> I'm writing to you to share some feedback and improvements to java-propose-
> classpath which I hope you might find useful.
>
> But first please excuse me for starting with describing a problem:
>
> java-propose-classpath in its current form is not very useful, to say the
> least.
> The problem is that it makes assumptions that all the required dependencies
> can be satisfied with installed shared java libraries (jars).
>
> If the dependency is not installed the proposed class path is incomplete and
> there is no warning for incomplete dependency. This is very misleading.
>
Agreed, that does sound suboptimal.
> But the problem is much worse: if java-propose-classpath is given two jars,
> one primary and the other one providing needed classes,
> java-propose-classpath
> tries to calculate class path for both of them, completely ignoring their
> relationships. (unless all dependent jars are installed to /usr/share/java
> the
> calculated class path would be incorrect)
>
> Needless to say there are many cases when application may need to install
> private jars and java-propose-classpath could be a very useful tool to help
> calculate what libraries are really needed.
>
Sounds reasonable as well.
> Sadly many Java developers distribute their stuff as a bunch of jars some of
> which are not even needed and some of which can be substituted with debian
> packages providing needed dependencies. We need a better java-propose-
> classpath to help maintainers to package not so perfect java software.
>
> For example, java-propose-classpath could suggest what package provides the
> dependent java library. This could significantly ease tedious Depends
> calculation which for a moment can only be done manually.
>
On a related note, I would love for jh_depends to be smarter and
generate ${java:Depends} based on the actual usage[0]. Actually, I
believe I have some code somewhere that might could be useful for this.
[0] Including checking for useless/overlinking and erroing out if
classes are missing etc.
> =====
>
> I experienced all the above problems when I was struggling with packaging one
> Java application. To overcome the issues I wrote a helper bash script which
> successfully deals with all described problems and more.
>
> Initially I thought I would use my script to improve java-propose-classpath
> but this would replace over 90% of java-propose-classpath code.
> It appears to me that doing it the other way (merging java-propose-classpath
> with my script or using my slightly modified script to replace java-propose-
> classpath) may be an easier task. Sadly at the moment I can't afford spending
> enough time to do the merging work hence I'm sharing my script with you in
> hope that you can accommodate improvements, ideas and implementation to the
> package.
>
:)
> ===
>
> The attached bash script takes one or more jars as arguments and extract all
> the used classes to associative arrays using the method similar to one java-
> propose-classpath uses. If the required class is present in given jars it
> considered as satisfied dependency.
>
> Then script scans the jars installed to /usr/share/java and print out all the
> needed classes which are not provided by neither given nor shared jars.
>
> The identified shared jars providing classes required by given jars are then
> printed out, with corresponding packages providing them, if 'dlocate' is
> installed.
>
> My implementation is slightly faster and more flexible:
>
> it can use 'fastjar', but falls back to use 'jar' provided by openjdk;
>
> it can use 'jcf-dump' from gcj-jdk but falls back to 'javap' from openjdk.
>
> Because script heavily rely on bash associative arrays it is very important
> to
> use bash (>= 4.2) because older versions affected by nasty memory leak.
>
Ok.
> Without the license my script have roughly the same number of lines as java-
> propose-classpath so in the same size it does a bit more, including some
> progress indication which I find very useful when scanning large jars (it
> sometimes takes over 20 minutes).
>
> Please let me know what do you think.
>
> Hopefully with your suggestions we can accommodate improvements into
> javatools
> package easy enough.
>
While I do not have time right now to give it a detailed review, I hope
we can use it (partly or even fully).
> Please CC to me as I'm not subscribed to pkg-java-maintainers list.
>
> All the best,
> Dmitry.
>
> P.S. Please don't worry about license compatibility because for javatools I
> give permission to use GPL-2+ license.
I appreciate the gesture, but I cannot accept it[1]. It is possible
that we could bump the license of the existing javatools code to GPL-2+
or alternatively, I can also accept an unconditional GPL-2+ license on
your code.
~Niels
[1] http://www.debian.org/social_contract
"""
8. License Must Not Be Specific to Debian
"""
listdeps-jar.sh
Description: Bourne shell script
