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]>:


Wim Deblauwe a écrit :
>
>
> 2005/11/18, Emmanuel Venisse <[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.




Reply via email to