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
signature.asc
Description: PGP signature
