You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm-dev@maven.apache.org by ro...@aciworldwide.com on 2007/09/28 11:26:19 UTC

scm plugin providers

Greetings all

I have decided to implement my own scm provider, named custom.  My connect 
url would therefore look like scm:custom:.....

So, my question is, what next? Or more specifically, what are the 
classes/interfaces needed to make this happen? Do I "register" with the 
scm framework in some manner, or does it do some some dynamic discovery 
such as looking for org.apache.maven,scm.provider.custom.CustomScmProvider 
on the classpath?

Also, when playing with scm:starteam checkout I noticed that it deletes 
the checkout area first. I did not see any code that did this in the 
Starteam sources, so I assume it's done by the scm framework? And if it 
is, how can I override the behavior? 


Thanks again
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 plugin providers

Posted by ro...@aciworldwide.com.
"Dan Tran" <da...@gmail.com> wrote on 09/28/2007 10:20:43 AM:

> On 9/28/07, robert.egan@aciworldwide.com <ro...@aciworldwide.com> 
wrote:
> >
> >
> > Also, when playing with scm:starteam checkout I noticed that it 
deletes the
> > checkout area first. I did not see any code that did this in the 
Starteam
> > sources, so I assume it's done by the scm framework? And if it is,how 
can I
> > override the behavior?
> >
> mvn scm:checkout always remove the checkout area regardless of provider 
type.
> To override this behavior, see the scm:checkout plugin doc, there is a
> flag there.

That would undoubtedly be "skipCheckoutIfExists", which I had assumed 
meant "skip checkout altogether" but must instead mean "skip files if they 
exist".

Thanks for clearing that up!


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 plugin providers

Posted by Dan Tran <da...@gmail.com>.
On 9/28/07, robert.egan@aciworldwide.com <ro...@aciworldwide.com> wrote:
>
> Greetings all
>
> I have decided to implement my own scm provider, named custom.  My connect
> url would therefore look like scm:custom:.....
>
> So, my question is, what next? Or more specifically, what are the
> classes/interfaces needed to make this happen? Do I "register" with the scm
> framework in some manner, or does it do some some dynamic discovery such as
> looking for
> org.apache.maven,scm.provider.custom.CustomScmProvider on
> the classpath?
>
> Also, when playing with scm:starteam checkout I noticed that it deletes the
> checkout area first. I did not see any code that did this in the Starteam
> sources, so I assume it's done by the scm framework? And if it is, how can I
> override the behavior?
>
mvn scm:checkout always remove the checkout area regardless of provider type.
To override this behavior, see the scm:checkout plugin doc, there is a
flag there.

-D

>
> Thanks again
> 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 plugin providers

Posted by Emmanuel Venisse <em...@venisse.net>.
it's a dynamic discovery.

In your provider, you need a class that extends AbstractScmProvider. This class must have in javadoc this line:

  * @plexus.component role="org.apache.maven.scm.provider.ScmProvider" role-hint="custom"

And you must add this plugin in your pom:

       <plugin>
         <groupId>org.codehaus.plexus</groupId>
         <artifactId>plexus-maven-plugin</artifactId>
         <executions>
           <execution>
             <goals>
               <goal>descriptor</goal>
             </goals>
           </execution>
         </executions>
       </plugin>


With this, the scm manager will find your provider when you'll use your custon scm url

Emmanuel

robert.egan@aciworldwide.com a écrit :
> 
> Greetings all
> 
> I have decided to implement my own scm provider, named custom.  My 
> connect url would therefore look like scm:custom:.....
> 
> So, my question is, what next? Or more specifically, what are the 
> classes/interfaces needed to make this happen? Do I "register" with the 
> scm framework in some manner, or does it do some some dynamic discovery 
> such as looking for 
> org.apache.maven,scm.provider.custom.CustomScmProvider on the classpath?
> 
> Also, when playing with scm:starteam checkout I noticed that it deletes 
> the checkout area first. I did not see any code that did this in the 
> Starteam sources, so I assume it's done by the scm framework? And if it 
> is, how can I override the behavior?
> 
> 
> Thanks again
> 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.