Ainsi parlait Lundi 6 Mai 2002 15:58, Nicolas Mailhot : > > - 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. I know of at least two other similar project currently: Debian Java, and Real Time Enterprises (http://sourceforge.net/projects/rte). I dunno how they particular ant package works, but i think they are better qualified than anyone else for ensuring it.
Which was my main point, btw: default ant script should only cares about standalone installation, and let additional complexity to additional providers. > > 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. I think it should comes into ANT_HOME/bin, so ant script would just have to source it, and it would always be present. > 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. I don't intend to convince other they needs the additional functionalities we use, but i think we have to provide all original functionalities. -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
