You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ro...@aciworldwide.com on 2008/03/05 15:59:24 UTC

scm reference works?

I have written my own scm provider for the scm plugin and I am now trying 
to use it. Unfortunately, the scm provider plugin seems to be very 
exacting in what it expects for configuration parameters (i.e. their 
content, not what type of data they are).

Normally, I would google "SCM Tutorial" and not bother the list. But 
unfortunately, SCM is also an acronym for "Supply Chain Management", a 
very hot topic in google these days it would seem, since it produces 
almost 400K hits, almost none of which relate to "Source Control 
Management".

So, thanks in advance for any links to scm manuals/tutorials.


Robert Egan

This email message and any attachments may contain confidential, 
proprietary or non-public information.  The information is intended solely 
for the designated recipient(s).  If an addressing or transmission error 
has misdirected this email, please notify the sender immediately and 
destroy this email.  Any review, dissemination, use or reliance upon this 
information by unintended recipients is prohibited.  Any opinions 
expressed in this email are those of the author personally.

Re: scm reference works?

Posted by ro...@aciworldwide.com.
In order to clarify things, here's some examples of the issues I've faced 
and am facing.

The first one was the use of scm:update instead of scm:checkout. The 
source control product I use has no concept of "update". You simply 
checkout your files, optionally locking them. If they already exist and 
are out of date, they are updated. If they do not exist they are checked 
out.

So you can image my dismay when the first thing the scm:checkout operation 
did was delete my existing source tree! It turns out the scm 
differentiates between "checkout" and "update", and that really isn't 
documented anywhere that I can see. It just seems to be assumed by those 
used to scm.

Next up is the <scmVersionType> tag. If I omit it, the framework tells me 
it is required. If It is not "tag", "branch", or "revision" the framework 
tells me it is the wrong type. But if I specify one of those, it does not 
like my <scmVersion> tag, giving me a message that it is expecting a 
java.lang.String but got an org.apache.maven.scm.scmTag, scmBranch or 
scmRevision.

Again, I'm sure the required syntax is obvious to developers who use scm, 
because they are so used to it they don't give it a second thought. Just 
like they would "know" the difference between checkout and update. But 
quite frankly, it's got me stumped, so ANY documentation in this are would 
be greatly appreciated. It took me a long time to "stumble" onto the 
difference between checkout and update, and I'd like to shorten it this 
time around.


Thanks again,
Robert Egan


Previously, I wrote on 03/05/2008 09:59:24 AM:

> I have written my own scm provider for the scm plugin and I am now 
trying 
> to use it. Unfortunately, the scm provider plugin seems to be very 
> exacting in what it expects for configuration parameters (i.e. their 
> content, not what type of data they are).
> 
> Normally, I would google "SCM Tutorial" and not bother the list. But 
> unfortunately, SCM is also an acronym for "Supply Chain Management", a 
> very hot topic in google these days it would seem, since it produces 
> almost 400K hits, almost none of which relate to "Source Control 
> Management".
> 
> So, thanks in advance for any links to scm manuals/tutorials.
> 
> 
> Robert Egan
> 
--
This email message and any attachments may contain confidential, 
proprietary or non-public information.  The information is intended solely 
for the designated recipient(s).  If an addressing or transmission error 
has misdirected this email, please notify the sender immediately and 
destroy this email.  Any review, dissemination, use or reliance upon this 
information by unintended recipients is prohibited.  Any opinions 
expressed in this email are those of the author personally.