True. But that is for another day, as those changes need to be looked at in
the light of all of the CMS systems supported, including those in the
non-apache codebase.
Yes, I do see the need for a higher level of abstraction needed, as the
original API's were very much built around CVS, later SVN and now GIT.
I've got the Jazz provider working fine with the Release Plugin, which is
all I think that it's ever likely to be used by, but it fails some of the
Tck tests.
1. It fails the changelog test because there is always an initial baseline
of any component created. Then when I add files into it, and then check
them in, I need a second changeset. I cann't avoid this. But, the test is
looking for one revision, not two. Nor can I do them by date ranges -
unless I do them manully (even then I'm not sure).
2. I've opend a whole lot of defects for the Jazz SCM CLI (that I'm
wrappering). Time will tell to see what ones get resolved. That too would
fix up some of the Tck test failures.
And there are a few more too.
>From what I've seen, a higher level of abstraction would help, but it would
break pretty much everything... :-(
-Chris
On Sat, Mar 31, 2012 at 3:30 AM, Robert Scholte <apa...@sourcegrounds.com>wrote:
> Hi,
>
> Not every SCM is repository-based.
> I see more and more differences between SCM's.
> Should we split it into Client/Server versus Distributed model?
>
> -Robert
>
> Op Fri, 30 Mar 2012 09:46:51 +0200 schreef Chris Graham <
> chrisgw...@gmail.com>:
>
>
> Heh. Done!
>>
>> -Chris
>>
>> On Fri, Mar 30, 2012 at 6:03 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>> just do it in your coming patch :-)
>>>
>>> 2012/3/30 Chris Graham <chrisgw...@gmail.com>:
>>> > Any ideas of how to get to initialised loggers (from the plexus
>>> container)
>>> > in this method?
>>> > My only option so far, is a new DefaultLog().
>>> >
>>> > I'd perfer to use the normal ConsoleLogger etc as set up by the
>>> container,
>>> > and available to any descendants of the AbstractCommand...
>>> >
>>> > It's just a nice to have.
>>> >
>>> > Also, anyone object to me adding a removeRepo method to
>>> ScmTckTestCase.java?
>>> >
>>> > IE:
>>> >
>>> > /**
>>> > * This method is available to those SCM clients that need to
>>> perform
>>> > * a cleanup at the end of the tests. It is needed when server side
>>> > * operations are performed, or the check out dirs are outside
>>> > * of the normal target directory.
>>> > */
>>> > public void removeRepo()
>>> > throws Exception
>>> > {
>>> > }
>>> >
>>> > /**
>>> > * Provided to allow removeRepo() to be called.
>>> > * @see junit.framework.TestCase#**tearDown()
>>> > */
>>> > @Override
>>> > protected void tearDown()
>>> > throws Exception
>>> > {
>>> > super.tearDown();
>>> > removeRepo();
>>> > }
>>> >
>>> >
>>> > I'm thinking that the jazz provider (when scm provides a delete
>>> workspace
>>> > command...) and possibly the other server based SCM's may want this,
>>> > ClearCase, etc might benefit.
>>> >
>>> > It's just a nice to have. And in ScmTckTestCase is the right place for
>>> it,
>>> > as that is where initRepo() lives and is called by setUp().
>>> >
>>> > -Chris
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org>
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
