ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: [PROPOSAL] No need for CLASSPATH in ANT1
Date Wed, 07 Nov 2001 01:08:02 GMT
From: "Bevan Arps" <bevan.arps@actfs.co.nz>

> At 22:34 6/11/2001 +0000, Jose Alberto Fernandez wrote:
> 
> >What kind of tasks are we talking about. Can someone explain?
> 
> My understanding is that there are a *lot* of people that have developed 
> "in-house" tasks for various purposes. (If my Java was a little better, I 
> would have done this myself instead of using antcall and exec so much.)
> 
> Since these tasks are "in-house" they aren't publicised and we *cannot* 
> find out about them. We can't be sure that the authors are subscribed to 
> any Ant mailing list or that they read the archives.
> 
> So, there are a lot of tasks out there that are absolutely vital to peoples 
> business (where Ant is a real build tool on a real commercial project) and 
> there is NO way to find and contact them all.
> 

I feel there is a lot of BCS paranoia on this. Are we talking about tasks that
are impossible to implement unless Ant classes are loaded from the ClassPath?
If that were the case, then I could understand the argument, but it seems to me
a little too much to say that we cannot change anything because the whole
of the world economy would colapse if we were to do so.

Now, I have been asking for examples of tasks with such dependencies to
see if it is true that there is no other way to solve their situation. Can someone
give me a good example.

Notice that one of the things I provided in MainClassLoader was a way to
obtain the CLASSPATH represented by the ClassLoaders being used,
so you can say something like mainCL.getClassPath() and obtain the search
order implied by that ClassLoader. That for example is all what is needed
for JIKES and Co.

If there are other issues I would like to know them.

> Also remember that most people won't read any release notes unless 
> something breaks.
> 
> Hence, any change to the Ant API that breaks preexisting tasks is going to 
> piss a lot of users off who won't know anything about the change until 
> their builds stop working - and these builds might just break at a critical 
> time on a project.
> 
> Not a good way to build customer confidence or the user base.
> 

Well we could provide the old scripts for those who are in a pickle.
The code I submitted, per se, is not incompatible with the old way 
of doing things. Users in that critical path can revert to the old style scripts.

> Please note that I'm not arguing against your suggestions - nor am I 
> arguing for them as I don't know enough to have a valid opinion. I just 
> putting the case that breakage to backward compatibility needs to occur in 
> places where the regular customer expects it - such as a shift from 1.8 to 2.0.
> 

As I said, what I am suggesting does not make the code incompatible (you can still
provide the old scripts for this special cases. I would like to introduce some of this
features sooner, so that people start becomming aware of where we are heading.
If Peter is right and there will be another year before ANT2, more people will be writing
more bad tasks and the presure for keeping things as they are will be stronger.

Jose Alberto



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message