Date: Wed, 10 Sep 2003 15:15:51 +0200 (CEST) From: Herve Quiroz <herve.quiroz@esil.univ-mrs.fr> To: Ernst de Haan <ernst.dehaan@nl.wanadoo.com> Cc: freebsd-java@freebsd.org Subject: Re: ant script annoyances Message-ID: <20030910143418.H34811@puget.esil.univ-mrs.fr> In-Reply-To: <200309100913.34213.ernst.dehaan@nl.wanadoo.com> References: <20030909215210.GA5404@grimoire.chen.org.nz> <200309100913.34213.ernst.dehaan@nl.wanadoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
IMHO the solution would be to revert to the former 'ant' behaviour and
use a new variable to specify any addition to the standard classpath.
Then build some shell tool to include all jars from ${JAVASHAREDIR} in
the classpath (or any other).
The 'ant' executable (I mean the shell script) would look for some
different variable (e.g. ANT_CLASSPATH) to be included in the CLASSPATH.
The ANT_CLASSPATH would replace LOCALCLASSPATH, whose name is not
implicit enough IMHO if it has to be used from outside of the ant shell
script.
Then having a shell tool (such as the usual libXXX-config tools out
there) would allow us to populate this ANT_CLASSPATH:
bash$ `ant-config --classpath` ant <user parameters...>
which would translate into:
ANT_CLASSPATH=/usr/local/share/java/classes/log4j.jar:/usr/local/share/java/classes/commons-logging.jar ant <user parameters...>
>From here, we could imagine any behaviour we want for this ant-config
tool. It could even handle the case where several versions of the same
library are installed. I remember we discussed this issue long ago with
no trivial/simple/transparent/flexible solution to the problem. I even
suggested the use of symlinks like it is already the case for C shared
libraries (I can't remember what sort of chemical substance I was on
this day BTW...).
Just think of the possibilities:
ant-config --classpath --with-lib=log4j:1.2 --with-lib=commons-logging
would add the log4j (but the 1.2 version which has support for JDK1.1)
JAR file as well as the commons-logging (any version, latest preferably)
JAR file to the classpath (the ant one, that is ANT_CLASSPATH).
In my opinion, this solution addresses the "separation of concerns" and
allows us to use the provided tools "as-is". No special behaviour,
specific to FreeBSD, should be expected unless of course you specify one
using the additional FreeBSD facilities.
So for now, we could just implement the following changes:
- Remove any automatic/enforced classpath consideration in 'ant'
(other that what is expected from the original ant tool.
- Add support for ANT_CLASSPATH in 'ant'
That means users will not have to specify ANT_CLASSPATH manually.
The next step would be to implement the 'ant-config' tool with (very)
limited support. Only the '--classpath' parameter would be recognized at
first, thus providing a way for the user to get the ANT_CLASSPATH filled
quickly (and automatically) with all installed Java libraries. Of course
such a tool requires to be in the ports tree, within java/apache-ant or
as a separate port (I prefer the later personaly).
Then, anyone is free to maintain and improve the tool, just like it is
the case with java/javavmwrapper.
Damn, this mail was supposed to be a "quick and short answer"... I drink
too much coffee probably ;)
Regards,
Herve
On Wed, 10 Sep 2003, Ernst de Haan wrote:
> Although I do see the usefulness of the current behaviour of the 'ant'
> script, I also recognize the need for different behaviour in some cases.
>
> The fastest and easiest short-term solution for this is to add an
> environment variable that will make the 'ant' script behave as you would
> like it to.
>
> Ernst
>
> On dinsdag 9 september 2003 23:52, Jonathan Chen wrote:
> > Hi,
> >
> > I'd like to make a plea to remove the following bits from the "ant"
> > script of the port:
> >
> > # FreeBSD-specific: Add the .jar files from
> > ${PREFIX}/share/java/classes for JAR_FILE in
> > "/usr/local/share/java/classes"/*.jar; do
> >
> > # If the directory is empty, then the input string is returned
> > if [ -f "${JAR_FILE}" ]; then
> > if [ -z "${LOCALCLASSPATH}" ]; then
> > LOCALCLASSPATH="${JAR_FILE}"
> > else
> > LOCALCLASSPATH="${JAR_FILE}":"${LOCALCLASSPATH}"
> > fi
> > fi
> > done
> >
> > I can't see the rationale for the addition of the jar files; any
> > decent project that reference the common jar files would make a copy
> > of it in the project's supplementary lib directory for maximum
> > portability. The adverse effects of adding this are:
> >
> > 1. it pollutes the environment.
> > 2. build.xml files fails in subtle ways on FreeBSD compared
> > to other Java platforms (eg: xdoclet task definition
> > with classpathref). This means I can't just move project from
> > other systems to FreeBSD simply, and vice versa.
> >
> > Cheers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030910143418.H34811>