FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 12-28-2007, 12:08 AM
Vincent Fourmond
 
Default Java wrappers and java-common

Hello,

Many java packages provide runnable programs living in /usr/bin under
the form of a wrapper sh script. Most of them use essentially the same
or very similar code, although some are obviously of much better quality
than others.

What about collecting reusable bits of these scripts and gather them
in a /usr/lib/java/wrappers.sh (or something) in java-common so it would
be easier for everyone to make wrapper scripts, and easier to undergo
any transition after that ? Wrappers would then just look like something
in the spirit of:

#!/bin/sh

. /usr/lib/java/wrappers.sh

find_java_runtime
find_jars alibrary.jar anotherone.jar

exec $JAVACMD $JAVA_ARGS -cp $JAVA_CLASSPATH classname


It does look better than what is currently made. It would just require
an appropriate versioned Depends on java-common, which shouldn't be much
trouble. Code would include tricky bits to make sure that we have a java
runtime supporting swing and other contrib/non-free things that might
move to main in a (maybe not so ?) distant future.

Of course, I'd volunteer to review a fair amount of the wrappers and
come up with a tentative wrappers.sh.

Cheers,

Vincent, definitely in a Java mood tonight.

--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-29-2007, 01:05 PM
Michael Koch
 
Default Java wrappers and java-common

On Fri, Dec 28, 2007 at 02:08:33AM +0100, Vincent Fourmond wrote:
>
> Hello,
>
> Many java packages provide runnable programs living in /usr/bin under
> the form of a wrapper sh script. Most of them use essentially the same
> or very similar code, although some are obviously of much better quality
> than others.
>
> What about collecting reusable bits of these scripts and gather them
> in a /usr/lib/java/wrappers.sh (or something) in java-common so it would
> be easier for everyone to make wrapper scripts, and easier to undergo
> any transition after that ? Wrappers would then just look like something
> in the spirit of:
>
> #!/bin/sh
>
> . /usr/lib/java/wrappers.sh
>
> find_java_runtime
> find_jars alibrary.jar anotherone.jar
>
> exec $JAVACMD $JAVA_ARGS -cp $JAVA_CLASSPATH classname
>
>
> It does look better than what is currently made. It would just require
> an appropriate versioned Depends on java-common, which shouldn't be much
> trouble. Code would include tricky bits to make sure that we have a java
> runtime supporting swing and other contrib/non-free things that might
> move to main in a (maybe not so ?) distant future.
>
> Of course, I'd volunteer to review a fair amount of the wrappers and
> come up with a tentative wrappers.sh.

"find_jars" is suimple. Just prepend "/usr/share/java". We have that
mechanism already in CDBS ant.mk task. There we also append ".jar". So
its really simple. Just set "DEB_JARS := alibrary anotherone" for
building.

"find_java_runtime" is harder. You actually need to run the programs to
really find out if a runtime works with a given program.

Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-30-2007, 04:57 PM
"Arnaud Vandyck"
 
Default Java wrappers and java-common

2007/12/29, Michael Koch <konqueror@gmx.de>:
> On Fri, Dec 28, 2007 at 02:08:33AM +0100, Vincent Fourmond wrote:

Hello Vincent,

Thanks for your suggestion.

> "find_java_runtime" is harder. You actually need to run the programs to
> really find out if a runtime works with a given program.

Maybe the wrapper could usr /usr/bin/java and if a JAVA_HOME is set,
then use that one. So in the script that call the wrapper, you could
set a default JVM or let the user do so or even read it from
/etc/some_java_program_conf. The script would have to define a
classpath and default JVM args (or in a conffile).

--
Arnaud Vandyck


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 02:42 PM
Vincent Fourmond
 
Default Java wrappers and java-common

Hello,

Michael Koch wrote:
> "find_java_runtime" is harder. You actually need to run the programs to
> really find out if a runtime works with a given program.

Well, this approach won't be practical. I preferred to use a system of
'capacities' : do we need swing, some of sun's classes, a java2 runtime ?

I've written a tentative /usr/lib/java/wrappers.sh in batik (already
uploaded). You can view it at

http://svn.debian.org/wsvn/pkg-java/trunk/batik/debian/wrappers.sh?op=file&rev=0&sc=0

It is of course far from complete, as I lack experience with Debian
java packaging. However, I hope it makes a good starting point. A
typical script would look like:

[ttf2svg]:
#!/bin/sh

# Include the wrappers utility script
. /usr/lib/java/wrappers.sh

find_java_runtime
find_jars xercesImpl.jar batik-all.jar

run_java org.apache.batik.apps.ttf2svg.Main "$@"

[extract from rasterizer]
#!/bin/sh

# Include the wrappers utility script
. /usr/lib/java/wrappers.sh

# We need sun runtime.
find_java_runtime sun || {
echo "$0: Sun's java not found, some things won't work" >&2
find_java_runtime || echo "$0: No java found at all ! Aborting" >&2 &&
exit 1
}
find_jars xercesImpl.jar batik-all.jar fop-transcoder.jar
find_jars avalon-framework.jar commons-logging.jar commons-io.jar



I'm thinking about moving wrappers.sh to java-common, so more packages
could use this approach. Here are the advantages I see:

* only one place to modify when features of the various jvm change;
* a consistent interface for the user, with possibilities for
debugging the processes of finding jars/java runtime. For instance:

~ DEBUG=1 ttf2svg
[debug] /usr/bin/ttf2svg: Found JAVA_HOME =
/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0
[debug] /usr/bin/ttf2svg: Found JAVACMD =
/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/java
[debug] /usr/bin/ttf2svg: Runnning
/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/java -cp
:/usr/share/java/xercesImpl.jar:/usr/share/java/batik-all.jar
org.apache.batik.apps.ttf2svg.Main
usage: java org.apache.batik.svggen.font.SVGFont <ttf-path> [-l
<range-begin>] [-h <range-end>] [-autorange] [-ascii] [-id <id>] [-o
<output-path>] [-testcard]

* the writing of the scripts is much simpler, and the scripts more
general/resistant;
* some documentation could be shared in the form of a java_wrapper(7)
manual page, explaining how the wrapper script work, the error messages
and the possibilities for debugging.

I don't see any drawbacks to this approach, as packages can transition
to using that whenever they want, and that would only requires a
versioned Depends on java-common.

My questions to the team are:

* do anyone object moving this wrappers.sh to java-common ? I believe
this is where it belongs.
* what 'capacities' could be interesting for find_java_runtime ? How
could that be improved ?
* any thoughts about other functions that would gain in being common ?
A proper way to handle error/warning messages would be nice.
* is there something I completely overlooked or missed ?

Cheers,

Vincent

--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 03:01 PM
Michael Koch
 
Default Java wrappers and java-common

On Fri, Jan 04, 2008 at 04:42:30PM +0100, Vincent Fourmond wrote:
>
> Hello,
>
> Michael Koch wrote:
> > "find_java_runtime" is harder. You actually need to run the programs to
> > really find out if a runtime works with a given program.
>
> Well, this approach won't be practical. I preferred to use a system of
> 'capacities' : do we need swing, some of sun's classes, a java2 runtime ?
>
> I've written a tentative /usr/lib/java/wrappers.sh in batik (already
> uploaded). You can view it at
>
> http://svn.debian.org/wsvn/pkg-java/trunk/batik/debian/wrappers.sh?op=file&rev=0&sc=0
>
> It is of course far from complete, as I lack experience with Debian
> java packaging. However, I hope it makes a good starting point. A
> typical script would look like:
>
> [ttf2svg]:
> #!/bin/sh
>
> # Include the wrappers utility script
> . /usr/lib/java/wrappers.sh
>
> find_java_runtime
> find_jars xercesImpl.jar batik-all.jar
>
> run_java org.apache.batik.apps.ttf2svg.Main "$@"
>
> [extract from rasterizer]
> #!/bin/sh
>
> # Include the wrappers utility script
> . /usr/lib/java/wrappers.sh
>
> # We need sun runtime.
> find_java_runtime sun || {
> echo "$0: Sun's java not found, some things won't work" >&2
> find_java_runtime || echo "$0: No java found at all ! Aborting" >&2 &&
> exit 1
> }
> find_jars xercesImpl.jar batik-all.jar fop-transcoder.jar
> find_jars avalon-framework.jar commons-logging.jar commons-io.jar
>
>
>
> I'm thinking about moving wrappers.sh to java-common, so more packages
> could use this approach. Here are the advantages I see:
>
> * only one place to modify when features of the various jvm change;
> * a consistent interface for the user, with possibilities for
> debugging the processes of finding jars/java runtime. For instance:
>
> ~ DEBUG=1 ttf2svg
> [debug] /usr/bin/ttf2svg: Found JAVA_HOME =
> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0
> [debug] /usr/bin/ttf2svg: Found JAVACMD =
> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/java
> [debug] /usr/bin/ttf2svg: Runnning
> /usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/bin/java -cp
> :/usr/share/java/xercesImpl.jar:/usr/share/java/batik-all.jar
> org.apache.batik.apps.ttf2svg.Main
> usage: java org.apache.batik.svggen.font.SVGFont <ttf-path> [-l
> <range-begin>] [-h <range-end>] [-autorange] [-ascii] [-id <id>] [-o
> <output-path>] [-testcard]
>
> * the writing of the scripts is much simpler, and the scripts more
> general/resistant;
> * some documentation could be shared in the form of a java_wrapper(7)
> manual page, explaining how the wrapper script work, the error messages
> and the possibilities for debugging.
>
> I don't see any drawbacks to this approach, as packages can transition
> to using that whenever they want, and that would only requires a
> versioned Depends on java-common.
>
> My questions to the team are:
>
> * do anyone object moving this wrappers.sh to java-common ? I believe
> this is where it belongs.
> * what 'capacities' could be interesting for find_java_runtime ? How
> could that be improved ?
> * any thoughts about other functions that would gain in being common ?
> A proper way to handle error/warning messages would be nice.
> * is there something I completely overlooked or missed ?

java-common in Ubuntu has another mechanism applied to it (but its
unused currently). Perhaps its possible to merge stuff from that.

Gentoo has a mechanism that is more similar to yours. Can you pleas
compare it with yours. Perhaps its also possible to re-use stuff.

Before we move stuff into Debian java-common it should be completely
working for most cases. Otherwise stuff tends to get another nominal
member. We have enough of them already.


Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 04:18 PM
Vincent Fourmond
 
Default Java wrappers and java-common

Michael Koch wrote:
> On Fri, Jan 04, 2008 at 04:42:30PM +0100, Vincent Fourmond wrote:
> java-common in Ubuntu has another mechanism applied to it (but its
> unused currently). Perhaps its possible to merge stuff from that.

If I read the code right, they just have a list of possible JAVA_HOME
in a configuration file, and they try them in turn. Pretty basic, no
means to look for swing/xml/sun's classes and so on. No lookup for jar
files neither.

> Gentoo has a mechanism that is more similar to yours. Can you pleas
> compare it with yours. Perhaps its also possible to re-use stuff.

Actually, it looks similar, but it is based on a rather large python
program to find dependencies and a JVM able to run them. This apparently
relies on a database of the various jar's dependencies and requirements
in terms of JVM version and capacities. While this is definitely the way
to go, it is a much larger project than a simple shell script help.

> Before we move stuff into Debian java-common it should be completely
> working for most cases.

Do you mind me moving to the SVN of java-common, as I don't think it
is a good idea to go on in batik ? It wouldn't be installed if a new
version of java-common is necessary, it would only be present in the
source tarball. (but I understand if you don't like the idea).

> Otherwise stuff tends to get another nominal
> member. We have enough of them already.

When it comes to a more usable state, I'll check with a fair number of
packages from the svn repository.

Cheers,

Vincent

--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-05-2008, 07:49 AM
Michael Koch
 
Default Java wrappers and java-common

Hello,


On Fri, Jan 04, 2008 at 06:18:48PM +0100, Vincent Fourmond wrote:
> Michael Koch wrote:
> > On Fri, Jan 04, 2008 at 04:42:30PM +0100, Vincent Fourmond wrote:
> > java-common in Ubuntu has another mechanism applied to it (but its
> > unused currently). Perhaps its possible to merge stuff from that.
>
> If I read the code right, they just have a list of possible JAVA_HOME
> in a configuration file, and they try them in turn. Pretty basic, no
> means to look for swing/xml/sun's classes and so on. No lookup for jar
> files neither.
>
> > Gentoo has a mechanism that is more similar to yours. Can you pleas
> > compare it with yours. Perhaps its also possible to re-use stuff.
>
> Actually, it looks similar, but it is based on a rather large python
> program to find dependencies and a JVM able to run them. This apparently
> relies on a database of the various jar's dependencies and requirements
> in terms of JVM version and capacities. While this is definitely the way
> to go, it is a much larger project than a simple shell script help.

Thanks for these short analysises.
>
> > Before we move stuff into Debian java-common it should be completely
> > working for most cases.
>
> Do you mind me moving to the SVN of java-common, as I don't think it
> is a good idea to go on in batik ? It wouldn't be installed if a new
> version of java-common is necessary, it would only be present in the
> source tarball. (but I understand if you don't like the idea).

I dont like that idea, but I can understand it. I think that would be
acceptable as long as the packages depending on java-common have the
right versioned depends.

> > Otherwise stuff tends to get another nominal
> > member. We have enough of them already.
>
> When it comes to a more usable state, I'll check with a fair number of
> packages from the svn repository.

Thanks for your work. Its really appreciated.


Cheers,
Michael


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-05-2008, 02:35 PM
Vincent Fourmond
 
Default Java wrappers and java-common

Hello,

Michael Koch wrote:
>>> Before we move stuff into Debian java-common it should be completely
>>> working for most cases.

I've looked at a fair amount of wrapper scripts, and the wrappers.sh
library I propose can be used to provide all their functionalities
easily save one, for bsh, where users can provide an additional
classpath with a -classpath option. (this can be done with wrapper.sh
but via an environment variable, though). There are a few wrapper
scripts (such as ant and others copied from it) which are quite complex,
and I'm not sure that they could benefit from wrappers.sh, but this is
just a couple.

That means that there would be no problem using this wrappers.sh for
most of the wrapper scripts in the wild. This way, we would win:
* adaptability: only one package to modify for new jvms (or new
properties)
* consistence: several possibilities of customization and debugging
shared across all scripts (and that really should help, especially for
bug reports...)
* and, for us maintainers, it should be painless to write wrapper scripts.

We would lose only in one point:
* all packages with a wrapper script would need a versioned Depends on
java-common. That shouldn't be much trouble, though.

The wrapper is LGPLed so it should not pose legal problems of any kind.

>> Do you mind me moving to the SVN of java-common, as I don't think it
>> is a good idea to go on in batik ? It wouldn't be installed if a new
>> version of java-common is necessary, it would only be present in the
>> source tarball. (but I understand if you don't like the idea).
>
> I dont like that idea, but I can understand it. I think that would be
> acceptable as long as the packages depending on java-common have the
> right versioned depends.

I just committed the code into the java-common SVN[1]. This code *does
not get installed for now*. I'd like people to review and tell what they
think.

[1]: http://svn.debian.org/viewsvn/pkg-java/trunk/java-common/wrappers/

I'll let this thread stew for a while, and when everyone is happy (if
everyone is happy), I'll start thinking about uploading a new version of
java-common.

Cheers !

Vincent

--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-06-2008, 11:35 AM
Eric Lavarde
 
Default Java wrappers and java-common

Hi Vincent,

comparing the wrapper script from FreeMind, version 0.9.0, not yet in
Debian [1], and your script, I'm missing the following features:


- no check that JAVA_CMD actually exists and is executable if the
variable is set.

- /usr/bin/java as last fallback if nothing else helps.
- debug output of java version found, and how the java command was found
(it helps a great lot when users ask for help and have e.g. a dangling
environment variable).
- a warning if the find_java_runtime is called with criteria and the
java command returned doesn't respect those criteria: i.e. JAVA_CMD is
set to gcj, and the script asks for 'sun'. I don't have a good solution
for this one, but it also helps avoiding bug reports where the user
forces the wrong Java command.
- the ability to ask for a maximum Sun version, as certain Java programs
don't work with newer versions. Perhaps create things like sunmin5 and
sunmax5 variables and be able to ask for those!?
- in my script, I also use JAVA_BINDIR to find the "right" java command.
It's a SuSE thing, but if we try to be truly cross-platform, we should
also consider it.
- I would define $DESTDIR/usr/share/java once as a variable and reuse it
throughout the functions.

- I also defined a variable ADD_JARS which is put in front of the CLASSPATH.
- the CLASSPATH variable is also used by the java command, do we have
here a consistent behavior across all binaries?


Cheers, Eric

[1]
http://freemind.cvs.sourceforge.net/freemind/freemind/freemind.sh?view=log&pathrev=fm_060405_integration


Vincent Fourmond wrote:

Hello,

Michael Koch wrote:

Before we move stuff into Debian java-common it should be completely
working for most cases.


I've looked at a fair amount of wrapper scripts, and the wrappers.sh
library I propose can be used to provide all their functionalities
easily save one, for bsh, where users can provide an additional
classpath with a -classpath option. (this can be done with wrapper.sh
but via an environment variable, though). There are a few wrapper
scripts (such as ant and others copied from it) which are quite complex,
and I'm not sure that they could benefit from wrappers.sh, but this is
just a couple.

That means that there would be no problem using this wrappers.sh for
most of the wrapper scripts in the wild. This way, we would win:
* adaptability: only one package to modify for new jvms (or new
properties)
* consistence: several possibilities of customization and debugging
shared across all scripts (and that really should help, especially for
bug reports...)
* and, for us maintainers, it should be painless to write wrapper scripts.

We would lose only in one point:
* all packages with a wrapper script would need a versioned Depends on
java-common. That shouldn't be much trouble, though.

The wrapper is LGPLed so it should not pose legal problems of any kind.


Do you mind me moving to the SVN of java-common, as I don't think it
is a good idea to go on in batik ? It wouldn't be installed if a new
version of java-common is necessary, it would only be present in the
source tarball. (but I understand if you don't like the idea).

I dont like that idea, but I can understand it. I think that would be
acceptable as long as the packages depending on java-common have the
right versioned depends.


I just committed the code into the java-common SVN[1]. This code *does
not get installed for now*. I'd like people to review and tell what they
think.

[1]: http://svn.debian.org/viewsvn/pkg-java/trunk/java-common/wrappers/

I'll let this thread stew for a while, and when everyone is happy (if
everyone is happy), I'll start thinking about uploading a new version of
java-common.

Cheers !

Vincent




--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-07-2008, 08:19 PM
Vincent Fourmond
 
Default Java wrappers and java-common

Hello,

Eric Lavarde wrote:
> comparing the wrapper script from FreeMind, version 0.9.0, not yet in
> Debian [1], and your script, I'm missing the following features:
>
> - no check that JAVA_CMD actually exists and is executable if the
> variable is set.

I've modified that.

> - /usr/bin/java as last fallback if nothing else helps.

I used simply java, which leaves up to the sysadmin the possibility to
have something is /usr/local/bin. It is done in run_java.

> - debug output of java version found, and how the java command was found
> (it helps a great lot when users ask for help and have e.g. a dangling
> environment variable).

When DEBUG_WRAPPERS is set, the JAVA_HOME found is written.

> - a warning if the find_java_runtime is called with criteria and the
> java command returned doesn't respect those criteria: i.e. JAVA_CMD is
> set to gcj, and the script asks for 'sun'. I don't have a good solution
> for this one, but it also helps avoiding bug reports where the user
> forces the wrong Java command.

I don't think we'll manage this correctly. In any bug report, we would
have to ask the output of DEBUG_WRAPPERS=1 command.

> - the ability to ask for a maximum Sun version, as certain Java programs
> don't work with newer versions. Perhaps create things like sunmin5 and
> sunmax5 variables and be able to ask for those!?

Done.

> - in my script, I also use JAVA_BINDIR to find the "right" java command.
> It's a SuSE thing, but if we try to be truly cross-platform, we should
> also consider it.

Done

> - I would define $DESTDIR/usr/share/java once as a variable and reuse it
> throughout the functions.

Done. I've also provided a way to customize that should the need
arise. I don't think DESTDIR will be of use to any but a developer.

Maybe one day I'll try to turn that into a real path lookup, like for
PATH. Not today.

> - I also defined a variable ADD_JARS which is put in front of the
> CLASSPATH.

Defining JAVA_CLASSPATH beforehand does the trick with what I wrote.
Is there a need for another way to do so ?

> - the CLASSPATH variable is also used by the java command, do we have
> here a consistent behavior across all binaries?

I don't know. Apparently, from cacao, sun5, sun6 and gij, the
-classpath environment variable necessarily overrides the CLASSPATH
settings. Which means that if there is a call to find_jar, it is
useless. But I provided debug output for it nevertheless.

Modifications just committed, many thanks !

Vincent

--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?


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

Thread Tools




All times are GMT. The time now is 07:27 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org