You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Bevan Arps <be...@actfs.co.nz> on 2001/11/07 00:27:56 UTC
Re: [PROPOSAL] No need for CLASSPATH in ANT1
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.
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.
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.
Cheers,
Bevan.
--
"Programming is an Art Form that Fights Back"
Bevan Arps (<ma...@actfs.co.nz>bevan.arps@actfs.co.nz)
Senior OO Analyst, ACT Financial Systems
This communication is confidential to ACT Financial Systems (Asia
Pacific) and is intended for use only by the addressee. The views and
opinions expressed in this email are the senders own and do not
represent the views and opinions of ACT Financial Systems (Asia
Pacific).
Re: [PROPOSAL] No need for CLASSPATH in ANT1
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Steve Loughran" <st...@iseran.com>
>
> Is there anything to stop us running the new classloader side by side with
> the old loader? So it is only if you call
> "antx" that the new loader kicks in; 'ant' sticks with the existing and
> functional, albeit unelegant approach?
>
No, the code can work both ways. The whole point of the changes to
tasks like JIKES that will be require is for it not to assume one way
or another.
Jose Alberto
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] No need for CLASSPATH in ANT1
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Bevan Arps" <be...@actfs.co.nz>
To: "Ant Developers List" <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Tuesday, November 06, 2001 15:27
Subject: Re: [PROPOSAL] No need for CLASSPATH in ANT1
> 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.
Is there anything to stop us running the new classloader side by side with
the old loader? So it is only if you call
"antx" that the new loader kicks in; 'ant' sticks with the existing and
functional, albeit unelegant approach?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] No need for CLASSPATH in ANT1
Posted by Bevan Arps <be...@actfs.co.nz>.
At 01:08 7/11/2001 +0000, Jose Alberto Fernandez wrote:
>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.
Please go back and read what I wrote again. Then read it again. With a
dictionary.
I did not in any way say "we cannot change anything because the whole of
the world economy would colapse" and I strongly resent your statement that
I did.
You asked why it was the Ant community couldn't make the changes you're
suggesting and I gave one answer - that there are a lot of tasks that would
break, particularly tasks that the core Ant team cannot know about.
Now, please read this very carefully: Provided it is done in a way that
won't surprise Ant users, I have no problem at all with breaking backward
compatibility.
The key is not surprising them - the worst thing you can do with customers
is to foist upon them a mandatory change that causes them hassle and
inconvenience with no apparent benefit to them. In fact, this is the best
way to lose them.
This is why, IMHO, the changes you have been campaigning so vigorously for
should NOT be found in any 1.x version but only in 2.x.
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.
No it won't - because it has always been advertised that Ant2 will break
existing things.
If Ant 1.6 turns up and suddenly breaks my build, I know I would be
monumentally pissed off.
If Ant 2.0 breaks my build, well, I knew it was coming so it's no big deal.
Bevan.
--
"Programming is an Art Form that Fights Back"
Bevan Arps (<ma...@actfs.co.nz>bevan.arps@actfs.co.nz)
Senior OO Analyst, ACT Financial Systems
This communication is confidential to ACT Financial Systems (Asia
Pacific) and is intended for use only by the addressee. The views and
opinions expressed in this email are the senders own and do not
represent the views and opinions of ACT Financial Systems (Asia
Pacific).
Re: [PROPOSAL] No need for CLASSPATH in ANT1
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: "Bevan Arps" <be...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>