You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Bruce Atherton <br...@callenish.com> on 2002/08/02 19:33:44 UTC
Subversion in Ant (was Re: Attribute naming)
At 09:09 AM 8/2/2002 +0200, Stefan Bodewig wrote:
>Talking of a task for subversion, it may be better to bundle it with
>subversion than to include it with Ant's distribution. It would
>require a svn command line client (if I understand you correctly)
>anyway.
I'm sure it could be hosted with Subversion, but I don't recommend it. I
understand the motivation of keeping the task in sync with the client but I
don't think this is much of an issue because the interface of the command
line client is fairly stable. Even in places where there is talk of
changing it, the changes are minor (how much output to show when the quiet
flag is passed) or backwards compatible (file:// changes).
Compare that to the cost for Subversion users of leaving it out of Ant
proper. Retrieving code from SCM systems is core to performing builds,
which is why we support such a variety of them. If a Subversion task is not
part of Ant, everyone who wants to use it has to find the task class in
their Subversion installation and include a <taskdef> with the appropriate
classpath. We couldn't easily share build files with Subversion tasks
because the classpath would have to be stored in a separate property that
changed for each user. Not a huge hurdle, but a barrier to adoption of
Subversion that seems unnecessary.
Almost all of the SCMs we support that I can see (CVS, Perforce, VSS, SOS,
PVCS, Continuus, Clearcase) require a separate client. Starteam is the one
exception, but it requires its own dependency to be installed, a JAR file.
So I don't see the requirement of a client (or client library if I can
solve the deployment and reliability issues) as an argument against. Nor is
a client necessarily going to be required in the long term, since I could
see developing an all Java client for Subversion once the working copy
format stabilizes and Subversion becomes completely DAV/DeltaV compliant,
probably within a year.
As far as the maintenance burden goes, I've been a contributor to the
Subversion project for a year now, so I'm willing to take on all the
maintenance duties there, as well as to provide the task in the first place.
And if others are willing to do the same with arch and Stellation, these
arguments apply to tasks developed for them as well.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Subversion in Ant (was Re: Attribute naming)
Posted by Bruce Atherton <br...@callenish.com>.
>There is a reason that writing an Ant task has never even been brought up
>on the svn mailing list.
Oops, I tell a lie. Someone just posted. And while I've been blathering,
they've written their own Ant task.
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=19111
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Subversion in Ant (was Re: Attribute naming)
Posted by Bruce Atherton <br...@callenish.com>.
At 12:27 PM 8/2/2002 -0700, you wrote:
>Beeing able to do <taskdef> with an explicit classpath ( instead of
>putting all the jars in ant/lib ) is a benefit. And you don't need
>to use the classname - you can just have a resource with all the
>task ( META-INF/subversion.tasks ).
It isn't explicit classpath vs. putting jars in ant/lib. It is explicit
classpath vs. doing nothing.
I can use <cvs> with no overhead other than making sure the cvs client is
in the PATH. Same with almost all other SCM tasks. It would be nice if the
same were true of Subversion (and Stellation and arch).
>That would make your task available to existing ant1.5 (and 1.4) users and
>you'll be able to make changes independent of the long ant release
>cycle.
I take your point, but there is no reason that couldn't be done from Ant as
well. For example, we could have a page on the Ant site that detailed the
list of new tasks that people could access early (before 1.6 release) by
using <taskdef>. This would actually be beneficial in getting more testing
done on new tasks before release, too. Initially there would be the
overhead for users that I am complaining about, but eventually it would
disappear.
Besides, I think this is an argument to increase the rate of releases, if
anything.
>
>We also hope that antlib will be available in 1.6 and will automate a lot
>of this.
I don't see how antlib changes what I am saying, although perhaps I am
misunderstanding. You still have to point to where a task's JAR file is,
don't you? Isn't that what the "file" attribute does? Either that, or find
the file and copy it into antlib. Either way, it is some overhead for the
user although perhaps it is less than what they have to do now.
>The problem is that your task will only be available in the next
>ant release - which may take a while. We don't even know how it'll
>be called - it may be 1.6, 1.9 or even 2.0.
Nice try! I'm not wandering into that topic. :-)
Again, this just shows that there will be a time period during which that
overhead I am trying to avoid will have to be endured. At least if the task
is part of Ant it will eventually be integrated, as opposed to the alternative.
>If you keep it in subversion CVS - all commiters on subversion will be
>able to work on it. In ant - ant commiters will have to make the
>changes.
:-) Not CVS. Subversion committers love their dogfood.
Your argument actually favours keeping it in Ant. The Subversion committers
are all brilliant, but they are completely devoted to C. Although there are
probably a couple that write Java, most seem to be annoyed at how much Java
is trying to reinvent the world when there are perfectly workable C
solutions available. These are guys who eat, sleep, and breathe autogen,
make, and libtool. There is a reason that writing an Ant task has never
even been brought up on the svn mailing list.
Besides, the issue of changes to the program is overblown. By using the
command line client to provide the interface, there will be little in the
way of changes necessary.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Subversion in Ant (was Re: Attribute naming)
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Bruce Atherton" <br...@callenish.com>
> Compare that to the cost for Subversion users of leaving it out of Ant
> proper. Retrieving code from SCM systems is core to performing builds,
> which is why we support such a variety of them. If a Subversion task is
not
> part of Ant, everyone who wants to use it has to find the task class in
> their Subversion installation and include a <taskdef> with the appropriate
> classpath. We couldn't easily share build files with Subversion tasks
> because the classpath would have to be stored in a separate property that
> changed for each user. Not a huge hurdle, but a barrier to adoption of
> Subversion that seems unnecessary.
No. If we want to externalize tasks it's based not only on the maintenance
burden but also because we assume things like Antlib will be in.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Subversion in Ant (was Re: Attribute naming)
Posted by Kieran <ki...@esperi.demon.co.uk>.
On Fri, 2 Aug 2002 costinm@covalent.net wrote:
> On Fri, 2 Aug 2002, Bruce Atherton wrote:
>
> Beeing able to do <taskdef> with an explicit classpath ( instead of
> putting all the jars in ant/lib ) is a benefit. And you don't need
> to use the classname - you can just have a resource with all the
> task ( META-INF/subversion.tasks ).
>
> That would make your task available to existing ant1.5 (and 1.4) users and
> you'll be able to make changes independent of the long ant release
> cycle.
Hypothetically speaking, if the code were to be hosted outside of the
ant tree, would it still be OK to be in the package
"org.apache.tools.ant.taskdefs"?
The AbstractCVSTask class is a fairly nice base to adapt, but there are
accessibility issues if it's moved outside the package.
Regards
Kieran
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Subversion in Ant (was Re: Attribute naming)
Posted by co...@covalent.net.
On Fri, 2 Aug 2002, Bruce Atherton wrote:
> Compare that to the cost for Subversion users of leaving it out of Ant
> proper. Retrieving code from SCM systems is core to performing builds,
> which is why we support such a variety of them. If a Subversion task is not
> part of Ant, everyone who wants to use it has to find the task class in
> their Subversion installation and include a <taskdef> with the appropriate
> classpath. We couldn't easily share build files with Subversion tasks
Beeing able to do <taskdef> with an explicit classpath ( instead of
putting all the jars in ant/lib ) is a benefit. And you don't need
to use the classname - you can just have a resource with all the
task ( META-INF/subversion.tasks ).
That would make your task available to existing ant1.5 (and 1.4) users and
you'll be able to make changes independent of the long ant release
cycle.
We also hope that antlib will be available in 1.6 and will automate a lot
of this.
> As far as the maintenance burden goes, I've been a contributor to the
> Subversion project for a year now, so I'm willing to take on all the
> maintenance duties there, as well as to provide the task in the first place.
The problem is that your task will only be available in the next
ant release - which may take a while. We don't even know how it'll
be called - it may be 1.6, 1.9 or even 2.0.
If you keep it in subversion CVS - all commiters on subversion will be
able to work on it. In ant - ant commiters will have to make the
changes.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>