ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck ...@adolos.com>
Subject RE: [suggestion] re: Bootstrapping Ant
Date Tue, 08 Aug 2000 16:39:16 GMT
> >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.

Mime
View raw message