Extending Maven SCM Interfaces

[Alexey Kakunin <ak...@emdev.ru>]

Hello dear maven-scm development team.

Additionally to email from Sergey Zakusov, he sent 2 days ago.
Our company developing open-source workflow based task-management system
EmForge (http://www.emforge.org)

One of important part of this project - is integration with version control
(you can check current implementation at http://www.emforge.org/browser)

Our target for next milestone (
http://www.emforge.org/project/EmForge/milestone/EmForge0.24) was add
support for CVS additionally to currently supported SVN.
After small investigation, we decided to use maven-scm - since, seems it is
really a great library provided common interface to many version control
systems.

With using maven-scm we hope to support browse for many other version
controls, not only SVN and CVS (and for maven-scm we hope it will be good
example of usage this library).

Unfortunately, during deveopment we found, that current version of maven-scm
is mostly designed to work on top of working directory and perform
operations like update, commit and so on...

In our case - we do not have any working directly.
Plus, some functionality just missed and it is hard to implement version
control browser with using maven-scm.

As basic version we got svn-java provider. Unfortunately it is not a part of
maven-scm - due to license problems with svnkit... anyway.

And to implement fully functional repository browser we extended some basic
maven-scm interfaces like:
* ChangeFileEx (
http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/ChangeFileEx.java
)
* AbstractCatCommand (
http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/provider/svn/svnjava/command/cat/AbstractCatCommand.java)
to be able get file contents for specified revision
* ChangeSetEx (
http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/ChangeSetEx.java)
to display additional information in changeset

Plus, as Sergey wrote - many problems produced the fact, that all basic
classes has validation for "working directory" - and it is not possible to
implement logic, not used it (but many scm command do not required working
directory to be specified) - so, we had to implement many tricks to avoid
this validation.

We will be happy if our changes will not be like a branch - but will be
contributed into maven-scm core and from our side ready to invest time to
support this functionality in some other providers.
Major idea - this extensions should be like "extensions" - so, old providers
should keep working - but some new provider may return, for example not
basic ChangeSet - but extended ChangeSet, and programs, required it - will
able to use them.

So, is it possible somehow contribute our changes into maven core and that
we should do from our side for it?


-- 
With best regards,
Alexey Kakunin

Re: Extending Maven SCM Interfaces

[Brett Porter <br...@apache.org>]

Hi Alexey,

Thanks for the mail. I think your suggestions make sense and it'd be  
great to have help implementing them.

Right now, we're focusing on pulling together a 1.1 release, but after  
that I'm sure we can evaluate some API changes as appropriate.

I would suggest the best way is to proceed is to take one issue at a  
time (like the original mail), get feedback on a proposal, and then  
submit a patch. It will be much easier to review if they are tackled  
one at a time and the impact of the change can be looked at.

Cheers,
Brett

On 14/05/2008, at 3:49 AM, Alexey Kakunin wrote:

> Hello dear maven-scm development team.
>
> Additionally to email from Sergey Zakusov, he sent 2 days ago.
> Our company developing open-source workflow based task-management  
> system EmForge (http://www.emforge.org)
>
> One of important part of this project - is integration with version  
> control (you can check current implementation at http://www.emforge.org/browser)
>
> Our target for next milestone (http://www.emforge.org/project/EmForge/milestone/EmForge0.24 
> ) was add support for CVS additionally to currently supported SVN.
> After small investigation, we decided to use maven-scm - since,  
> seems it is really a great library provided common interface to many  
> version control systems.
>
> With using maven-scm we hope to support browse for many other  
> version controls, not only SVN and CVS (and for maven-scm we hope it  
> will be good example of usage this library).
>
> Unfortunately, during deveopment we found, that current version of  
> maven-scm is mostly designed to work on top of working directory and  
> perform operations like update, commit and so on...
>
> In our case - we do not have any working directly.
> Plus, some functionality just missed and it is hard to implement  
> version control browser with using maven-scm.
>
> As basic version we got svn-java provider. Unfortunately it is not a  
> part of maven-scm - due to license problems with svnkit... anyway.
>
> And to implement fully functional repository browser we extended  
> some basic maven-scm interfaces like:
> * ChangeFileEx (http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/ChangeFileEx.java 
> )
> * AbstractCatCommand (http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/provider/svn/svnjava/command/cat/AbstractCatCommand.java 
> ) to be able get file contents for specified revision
> * ChangeSetEx (http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/ChangeSetEx.java 
> ) to display additional information in changeset
>
> Plus, as Sergey wrote - many problems produced the fact, that all  
> basic classes has validation for "working directory" - and it is not  
> possible to implement logic, not used it (but many scm command do  
> not required working directory to be specified) - so, we had to  
> implement many tricks to avoid this validation.
>
> We will be happy if our changes will not be like a branch - but will  
> be contributed into maven-scm core and from our side ready to invest  
> time to support this functionality in some other providers.
> Major idea - this extensions should be like "extensions" - so, old  
> providers should keep working - but some new provider may return,  
> for example not basic ChangeSet - but extended ChangeSet, and  
> programs, required it - will able to use them.
>
> So, is it possible somehow contribute our changes into maven core  
> and that we should do from our side for it?
>
>
> -- 
> With best regards,
> Alexey Kakunin

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/