you can use them (after to rename them to AbstractEditCommand and
AbstractUndeitCommand).
Those classes are only the prototype of commands, so providers can implements them (not used
actually by providers)
Emmanuel
Wim Deblauwe a écrit :
I see that there is already a class called
org.apache.maven.scm.command.lock.AbstractLockCommand and also
org.apache.maven.scm.command.unlock.AbstractUnlockCommand. What was the
idea of those classes? Should I use those and their methods in the
ScmProvider interface?
regards,
Wim
2005/11/18, Emmanuel Venisse <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Wim Deblauwe a écrit :
>
>
> 2005/11/18, Emmanuel Venisse <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>:
>
>
>
> Wim Deblauwe a écrit :
> > So, summarizing:
> >
> > 1) we need a lock/edit command in the ScmProvider interface,
> since the
> > release plugin knows that interface. We then have 2
options: define a
> > special property or let the release plugin call lock/edit
always and
> > provide an empty implementation in AbstractScmProvider for
the
> > non-clearcase SCM's. For me option 2, seems nicest.
>
> We need these 2 options. Default implementation will do
nothing for
> providers that don't have a
> specific implementation. The special property will be useful for
> some provider like cvs. In cvs, we
> can have 2 modes (with or without lock/edit), so we'll
implement the
> lock/edit command in cvs and
> users can activate or not it with the special property. Release
> plugin can't always call lock/edit
> command, it will depend on users configuration.
>
>
> ok, so I'll go ahead and add 2 methods (edit and unedit) to the
> ScmProvider interface. But how should I implement them in
> AbstractScmProvider currently? Leave them empty or throw exception?
I'd prefer toleave them empty because it isn't a required command
but an optional.
>
>
> >
> > 2) checkout is currently incorrectly implemented. It
currently calls
> > 'cleartool co', but it should not do that. It should
create a view
> > dynamically (not impossible), but then? Should it copy the
> contents to
> > some file location? But then you won't be able to do any
clearcase
> > operations on that.
>
> You're our clearcase specialist (With Dan), so implement it
like you
> think it's better. Personnaly,
> i think it isn't a good idea to copy contents to an other
location
> if we can't do other operations
> of them
>
>
> Is this needed by continuum only? Or what tools/plugins might
need this
> also? Isn't it possible to just point to a local file in
continuum and
> tell continuum to build that on the location it is. Because for
> clearcase, a lot of parameters are needed and it will not be that
easy.
> The most important for me right now is getting the release plugin to
> work, so I would like to change the current checkout
implementation to
> throw an exception for clearcase (in stead of doing the wrong
thing as
> it does currently).
checkout command is use by continuum and release plugin.
release plugin checkout files by default in target/checkout
(workingDirectory parameter)
continuum checkout files in working_directory/PROJECT_ID, it isn't
possible actaully to use an other
location. But when a checkout is done, continuum do an update for
next builds.
