Re: SCM initRepo method
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: SCM initRepo method
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: SCM initRepo method
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: SCM initRepo method
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.comwrote:
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.**orgdev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
SCM initRepo method
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
