From owner-freebsd-java@FreeBSD.ORG Wed Sep 10 06:26:24 2003 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA4B16A4BF for ; Wed, 10 Sep 2003 06:26:24 -0700 (PDT) Received: from puget.esil.univ-mrs.fr (puget.esil.univ-mrs.fr [139.124.41.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9498443FE5 for ; Wed, 10 Sep 2003 06:26:23 -0700 (PDT) (envelope-from herve.quiroz@esil.univ-mrs.fr) Received: from puget.esil.univ-mrs.fr (localhost.esil.univ-mrs.fr [127.0.0.1]) h8ADFr6n035321; Wed, 10 Sep 2003 15:15:54 +0200 (CEST) (envelope-from herve.quiroz@esil.univ-mrs.fr) Received: from localhost (rv@localhost)h8ADFqwe035318; Wed, 10 Sep 2003 15:15:52 +0200 (CEST) X-Authentication-Warning: puget.esil.univ-mrs.fr: rv owned process doing -bs Date: Wed, 10 Sep 2003 15:15:51 +0200 (CEST) From: Herve Quiroz X-X-Sender: rv@puget.esil.univ-mrs.fr To: Ernst de Haan In-Reply-To: <200309100913.34213.ernst.dehaan@nl.wanadoo.com> Message-ID: <20030910143418.H34811@puget.esil.univ-mrs.fr> References: <20030909215210.GA5404@grimoire.chen.org.nz> <200309100913.34213.ernst.dehaan@nl.wanadoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-java@freebsd.org Subject: Re: ant script annoyances X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 13:26:25 -0000 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 which would translate into: ANT_CLASSPATH=/usr/local/share/java/classes/log4j.jar:/usr/local/share/java/classes/commons-logging.jar ant >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.