ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dona...@mad.scientist.com
Subject RE: [suggestion] re: Bootstrapping Ant
Date Wed, 09 Aug 2000 04:07:06 GMT
On Tue, 8 Aug 2000, Stuart Roebuck wrote:
> I understand.  But I'm also concerned that sometimes people assume that  
> the rest of the world works on Windows/DOS or Unix.

they aren't ?
/me ducks

The problem is while there is a plethora of other platforms
out there BeOS, Amiga, OS2 (Still!!) the majority don't have
vms. Likely enough if they have vms then they are *nix or a
win32. Again this excludes Macs ...

>  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.

Iw will try to be x-platfrom but in many cses it is not
possible - or worse it ends up doing copious number of
platfrom dependant things in specific environments and as
far as I am concerned this should be discouraged.

We will end up placing things like if( win32 ) doX else if (
nix ) doY ...

This just moves dependancies from scripts (the usual place
for them) to java which is bad...

> No, it is like asking, "why make Java development projects dependent on  
> Unix or DOS?". What happens on a Mac for instance?

Who said they are dependant. You can download a daily binary
drop if you really want to keep up to date. If someone from
mac really wants to they can create their own scripts to do
compiling. 

> 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?

nope - not that I can see ... 

> 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.

manifests won't wolve any problem. Scripts are still needed
for other reasons. It just changes the last few lines of
script to launch java app differently.

> 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.

there is a lot more parameters that need to be fidlled with
in a system and VM dependant manner before .jar is even
loaded.

> 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.  

nope I ain't a developer - just a user who advocates it's
use everywhere :P

>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.

well it can't ...........

> 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.

most projects (actually all that I know of) bundle ant with
their distribution. Ant while a great tool has not yet
matured completely to a stable tool. It will eventually it
will but until people will continue bundling ant with their
projects. This problem you point out is the reason. It will
change - just not in the immediate future.

> But seriously, if you think I'm adding complexity and limiting factors  
> then I'm not explaining myself very well.

No it's you who don't understand issues at the moment. How
do we provide the facilities you want ? we do things that
are either JVM specific or that brake tools. Many tools are
broken by adding classloaders because they use
Class.forName("blah") rather than
getClass().loadClass("blah"). 

So you could either provide this really conceptually clean
ant that broke all tools and only ran on certain platforms
... or you could do what it does now - (which coincidently
is the same way a few OSes handle java invocation)

Cheers,

Pete

*--------------------------------------------------*
| Latrobe University,     |                        |
| Bundoora, Australia     | Does the name 'Pavlov' |
| Office: PW220           |    ring a bell ?       |
| Ex: 2503                |                        |
*--------------------------------------------------*



Mime
View raw message