> >Yes, but why create a wonderful cross platform tool like Ant with > >processor non-specific binaries and then use totally processor specific > >shell scripts to bootstrap the build. It seem to me to be like saying, > >here's a new build tool to replace make, we suggest you use it for your > >projects, but we don't use it for ours. > > It is no replacement for make - not yet. Perhaps in the future but it > doesn't quite qualify for anything but java related tasks at the moment.
Sorry, I didn't make myself clear, I meant a replacement for make within the context of Java development. I appreciate that it doesn't necessarily make sense for non Java development thought it clearly has lots of useful applications. > >Yes, the bootstrapping process builds and then utilises ant, but shouldn't > >we be aiming towards being able to avoid the build script altogether so we > >can run this thing on our Palm Pilot, or MacOS or whatever we happen to > >develop on whenever and wherever we happen to do it. > > well unfortunately java 1.1 and 1.2 don't have facilities to make this > possible. While some of it could be done via java not all of it could be. > Specifically the problems are to do with execution environments via > System.exec and doing things like setting files as executable. It can not > be done in system independant way. Other things like getting correct JVM > and mudging the classpath based on VM would be extremely difficult but > possible. Other things such as setting ant home are also for all practical > purposes undoable (they are possible to do on certain VMs in certain JVM > versions but not all). I understand. But I'm also concerned that sometimes people assume that the rest of the world works on Windows/DOS or Unix. The impossible is impossible, I was hoping that we would be aiming to solve the possible to make it as cross-platform / cross-environment as possible - part of the ethos and benefits of Java in my mind. It may be that this is already what is being done, I just didn't get that impression from the person I was originally responding to. > >What I mean is, Ant assumes that we have Java in our machine - without it > >Ant is useless. So why are we also relying on the existence of particular > >shell script interpreters as well? If we use Java for the bootstrap we are > > > >cutting out a dependency that we may not need to have and making things > >more platform independent. > > well both scripts ship with machine they are coupled with. All unixes as > far as I know have sh (or some extension like bash) and every dos box > understands .bat files. The dependancy is not an issue - it is like asking > why make c programs dependant on C runtime library. No, it is like asking, "why make Java development projects dependent on Unix or DOS?". What happens on a Mac for instance? > >Yes - if at all possible. > > Not possible unless go jdk1.3+ only and screw the rest of VMs > > >I would hope that we could have ant working so that there is a binary > >distribution of ant as a jar containing all the required XML DOM/SAX/etc. > >libraries, that will launch with "java -jar ant.jar" (under Java 1.2+) or > > well again do you really want to limit ant to specifics of VMs ? and besides > > "java -jar ant.jar" is so much less conveniant than "ant" And what if "ant" does absolutely nothing on your particular platform? Isn't the concept of the Manifest file something reasonably helpful and reasonably standard in the later Java implementations? Putting in the manifest doesn't break older VMs as far as I am aware. Is there any reason for not putting it there? I have no worries about having additional - non-essential shell scripts as added bonuses - these are all well and good. If unix users use "ant" as their command line invocation then that's totally sensible. I just feel it is important that the start manifests are in place as and when possible. > >by an equivalent action under whatever GUI - Windows, X-Windows, MacOS X, > >Palm Application Menu, whatever; > > you mean use a system specific way of launching it ... like you were just > arguing against ??? Please... Different platforms are different, hopefully the differences are innovations that move technology forward and make it more useable. The whole idea of APIs is to provide a standard interface between things that are different - and can change. On Windows with Java 1.2+ you double click a ".jar" file and it launches the java application based on the information in the manifest. On PalmOS the KVM it appears to do pretty much the same thing, I've never used Java under X-Windows (maybe it's not possible - I really don't know). Under DOS and Unix you can issue your "java -jar" command or "java -cp" or "java -classpath" etc. for previous versions. In all these cases, when it's got a manifest, it can use it. The user action which makes the application run *is* platform specific, but *not* the interface that makes it work. ... I am not contradicting myself. > >Okay, but in most cases a previous Ant should be able to build itself - > >and indeed making that happen is a fairly justifiable target. However, > >even when it can't it should be possible to distribute an up-do-date binary > > > >that will. > > and how pray tell is that generated ? Somewhere someone needs to generate > ant. Please don't start telling me about the chicken and the egg. People have been self-bootstrapping C compilers for years. It is possible to try to make sure that the previous version is capable of building the next, preferably by not making use of the very latest features in the build script, and not breaking the previous ones instantly. Yes, there may be exceptional times when it is either not possible, or just too much hassle. An exceptional bootstrapping mechanism would be suitable for that. I suspect part of the conflict of opinion here reflects our different angles on Ant. I'm never going to be spending lots of time contributing to Ant - it's mainly a very helpful tool to me in other projects. But occasionally there will be features that don't work or ones I want to add to it and I hope to be able to do that and contribute to the whole thing. Having to work out what a shell script is doing and convert it into something that runs on my platform is not a good incentive. Now, I don't expect people to spend hours adding java platform specific patches to cope with the likes of me, but it stills seems crazy to be using platform specific shell scripts *if* it can be done in Java. The message appears to be that that isn't possible - which is disappointing, but if that's reality I have to accept it. > >Perhaps there is an argument here for an optional version tag > >on the build.xml file that would allow older versions of Ant to cleanly > >recognise that they're not up to the job, rather than outputing error > >messages. > > it does. It complains "blah task not found" or "blah attribute not found". > It also lists deprecation warnings. Yes, your right, but if I went into a cinema and the man at the door said, "sorry your tickets not valid you can't come in", I think, on discovering that I was actually at the wrong door, I would be frustrated that the man hadn't bothered to say that the reason it wasn't valid was because I was at the wrong door, not because there was something out of date or missing from my ticket. Therefore I thought it was a reasonable suggestion - only a suggestion mind! > >> Having the ant.jar in CVS is unnecessary, so why bother? It is not that > >> difficult to build ant purely from source. > > > >The same could be said for the existence of Ant at all given that we > >already have makefile. > > err ... no ... the reason makefiles bite can basically be summed up as > speed and readability. Many make files execute java once per .java file > which just sucks down performance (usually faster to just delete all .class > files and compile whol tree). Makefiles are also impossible to read if the > makefile writer decided to use some nifty tricks. Okay, I hadn't noticed that the make was slow - I wrongly assumed that this was about writing a very flexible and modular make facility that didn't have to be recompiled on different platforms. > >I think we should bother because tools like Ant provide the building > >blocks which enable as wide a developer community as possible to be > >involved in contributing to open source projects. Why make it necessary > >for someone who doesn't live in a DOS window or on a Unix command-line to > >start trying to fathom the idiosyncrasies of csh or batch files when it > >just takes a little more effort on Ant to make that understanding > >unnecessary. > > who saids they have to understand it ? Only developers for ant who need to > alter them need to change them and there haven't been many changes > necessary to warrant the complexity and limiting factors you would impose. > There may be a case if there was several developers who worked on different > platforms not supported (Mac is the only one I can think of...) but in > general this hasn't been a problem - no one has even brought it up till you. Well I guess Mac developers are good all-rounders! :-) But seriously, if you think I'm adding complexity and limiting factors then I'm not explaining myself very well. I had to make sense of the shell script in the last CVS version I downloaded yesterday, if only to discover that it used ant to do part of the build, and the issue was in the build.xml file. (Extra "../" path prefixes on the "build" and "dist" directories if I remember rightly.) > >Ant should, in my opinion, be no different from any other Jakarta project, > >and I think they should all rely as little as possible on shell scripts > >and as much as possible on Ant. > > They rely on as little as possible no more and no *less*. Many still use > custom scripts to wrap around ant[|.bat] for their particular purposes. > Maybe in the future ant will be mature enough to solve everything but it is > not now and not while it has to be used in jdk1.1 and jdk1.2 environments. Okay, clearly what I'm hoping for is just not possible. Best regards, Stuart.
