Source code task

[Walker Joe <Jo...@barclaycard.co.uk>]

I'm wanting to write a Perforce task.
Perforce is a source code control thing like CVS, and VSS. I don't think it
will be too hard, but I have an implementation question.

The javac task is nice, IMHO, because I can swap between 1.2, 1.3, and jikes
with the flip of a switch - this has been very useful on a number of
occasions. It would also be useful to be able to switch between source
control providers with similar ease.

The alternative is that as more support is written for different source
control systems we end up with tens of different tasks all of which work
differently. (Quick mental tally - CVS, SCCS, RCS, P4, VSS, PVCS, Team
Connection, Clearcase, JavaSafe, ...)
This could make for ant's task list being very complex, when the "Java Way"
seems to be a simpler lowest common denominator approach.

Does this sound sensible?

In the short term I'm going to start on a P4 task.

Joe.



Legal Disclaimer:-

Please be aware that messages sent over
the Internet may not be secure and should
not be seen as forming a legally binding
contract unless otherwise stated.

Re: Source code task

[Stefan Bodewig <bo...@bost.de>]

>>>>> "WJ" == Walker Joe <Jo...@barclaycard.co.uk> writes:

 WJ> The javac task is nice, IMHO, because I can swap between 1.2,
 WJ> 1.3, and jikes with the flip of a switch

I think the situation is different for source control systems. How
often are you going to change the system - and given the work you have
to put into transferring the sources from say CVS to Clearcase,
changing a single line in your build file won't hurt that much.

What works out nicely for javac/jikes is that they share a lot of
attributes people typically want to set, I'm not sure if this holds
true for source control systems. Lets take a look at the task we have
right now:

<!ATTLIST cvs
          date CDATA #IMPLIED
          quiet %boolean; #IMPLIED
          command CDATA #IMPLIED
          noexec %boolean; #IMPLIED
          cvsroot CDATA #IMPLIED
          dest CDATA #IMPLIED
          package CDATA #IMPLIED
          tag CDATA #IMPLIED>

<!ATTLIST vssget
          recursive %boolean; #IMPLIED
          ssdir CDATA #IMPLIED
          date CDATA #IMPLIED
          vsspath CDATA #IMPLIED
          version CDATA #IMPLIED
          writable %boolean; #IMPLIED
          login CDATA #IMPLIED
          label CDATA #IMPLIED
          localpath CDATA #IMPLIED>

dest => localpath, tag => label or version, cvsroot => vsspath+login
but that's all. The rest is either only useful for cvs or for vssget,
at least this is what the authors thought.

You'd either end up with an additional-attributes entry or a bunch of
magic properties (like build.compiler.emacs) for the things not
covered by the common denominator.

I'd say, keep them as separate task - and give the user a chance to
only include the task she actually needs once we have the extension
system in place (Ant 2.0).

 WJ> In the short term I'm going to start on a P4 task.

It could be included as an optional task if you want.

Stefan