ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Mailhot <Nicolas.Mail...@laposte.net>
Subject Re: [JPackage-devel] FW: jakarta ant 1.4.1/1.5 ant script
Date Mon, 06 May 2002 13:58:28 GMT
Le lun 06/05/2002 à 14:53, Guillaume Rousse a écrit :
> Ainsi parlait Vendredi 3 Mai 2002 13:33, Nicolas Mailhot :
> > Le ven 03/05/2002 à 12:22, GOMEZ Henri a écrit :
> > > Ok, if your script is ready, thank to send us the patch file against
> > > 1.5b so I could release the 1.5b rpm asap
> >
> > Here it is :
> >         1. ant.5 latest script
> >         2. ant-4.5.patch diff of latest changes of the script :
> >             1. fix some very stupid typos,
> >             2. ANT_HOME=/usr/share/ant in rpmmode,
> >             3. add ANT_HOME/lib to classpath even in rpmmode,
> >             4. build all classpath elements :-ended so I don't have to
> >                bother anymore if the previous classpath element was void
> >                or not
> >             5. -> LOCALCLASSPATH = LOCALCLASSPATH RPMCOREJARS COREJARS
> >                CLASSPATH
> >         3. jvm.list.patch add OSX JAVA_HOME to list
> >         4. java-functions+setjavacmd.patch : add setjavacmd to
> >            java-functions for AIX hack inclusion
> >
> > Note that the patched version of jpackage-utils is required by this
> > script if JAVA_HOME and JAVACMD are not set.
> >
> > This works on my box with ant 1.4 and a pretty complex build.xml
> I had a look at script shipped with latest ant beta, here are some remarks:

Please look at the one I posted, it's a much more abitious rewrite that
the one in ant cvs, and tries to solve a lot of the points you raise?

> - usejikes option
> Stefan, you just warned us of redundancy against standard 
> -Dbuild.compiler=jikes option, so why reintroduce it there ?

No comment, didn't touch this part

> - rpmmode option
> The name is badly chosen. Actually, behaviour has nothing to do with rpm, but 
> with the fact that this software depends of other ones being installed in 
> defined place, thus ant being part of a distribution. I'd have used something 
> as standalone instead.

I agree on this, if nobody objects will change rpmmode to standalone in
next version

> Moreover, i still it is an error to have ant developpers taking care of this. 
> The day when another packaging project will use yet another java repository 
> and jar naming scheme, will them add another test case ?

I *do* hope if someone else ever takes upon itslef this thankless task
he will try to use the same name as us.

> As we, the packager, as the ones who control what is installed where, have to 
> maitain it anyway, so why make official script always more complex ? I'd 
> prefer more collaborative work on functions used.
> 
> - java_function inclusion
> I 100% agree this project becomes used elsewhere, and so takes cares of other 
> *nixes environement. However, i think default ant script strategy to test for 
> its presence in one place (once again, ant developpers doesn't control it), 
> and duplicate code instead, is suboptimal. Why not include it in ant 
> distribution, and source it directly ? This way, it would be always 
> available, and both script (ant default, and jpackage one) would easily share 
> behaviour.

Note that this is more or less the behaviour of my last script versions
: if rpmmode, use our java-functions, else source the one that we'll try
to bundle with ant, in the case none are found revert to minimalist
behaviour with no complex JAVA_HOME or JAVACMD at all.

This seems to go well with ant-dev, the remaining points being :
* audit of our java-functions so they'll work on exotic shells
* agree on some file layout for java-functions to bundle with ant.

Right now I don't use every parts of java-functions, I think we can
start safely bundling the whole thing and using the non-controversial
parts. And then decide if other parts of java-functions should be
splitted in jpackage-only scripts, be used by everyone including
ant-dev, or be dropped altogether.

I hope we'll find more extensive merger is possible. In fact, I've sold
set_jvm and set_javacmd to ant-dev, as the main author of the rest you
might want to convince them of the usefulness of everything alse.

Regards,

-- 
Nicolas Mailhot

Mime
View raw message