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
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
