Attribute naming

[Kieran <ki...@esperi.demon.co.uk>]

Hi,

I've been looking at taking the cvs task, and writing a task to
support the subversion source control project based on it.

I'm looking at the advice for attribute names at:
http://jakarta.apache.org/ant/ant_task_guidelines.html

There is no mention of a preference between "error" and "errorlog".
Is it ok to have the two as synonyms?  What about 'dest" and "destdir"?

Finally, I saw mention that tasks may disappear in 2.0.  Are there
guidelines for future-proofing my work anywhere?

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)

[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)

[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)

[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)

[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)

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

Subversion in Ant (was Re: Attribute naming)

[Bruce Atherton <br...@callenish.com>]

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: Attribute naming

[Stefan Bodewig <bo...@apache.org>]

On Thu, 1 Aug 2002, <ki...@esperi.demon.co.uk> wrote:

> There is no mention of a preference between "error" and "errorlog".
> Is it ok to have the two as synonyms?

I'd chose one and stick to it.  Neither of both is used by many tasks,
so I don't think there is a strong precedent.

> What about 'dest" and "destdir"?

We seem to prefer destdir and destfile over dest nowadays, but fashion
may change 8-).

> Finally, I saw mention that tasks may disappear in 2.0.  Are there
> guidelines for future-proofing my work anywhere?

In general we may want to move tasks out of Ant's distribution and
into libraries that have their own release cycles.

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.

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>