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: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
Dennis Lundberg wrote: On 2012-03-29 09:13, Lukas Theussl wrote: I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. This was my thought also. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. If agree that they should be moved, let's start with that. If the target is doxia-tools then let's move them there, prior to the 1.3 release of Doxia and Doxia Sitetools. My feeling about Doxia Tools is that their sub projects shouldn't be released all at the same time. They are individual projects and should have their own release cycles, much like our shared components or plugins. I agree for doxia-tools. Doxia and doxia-sitetools are closer coupled though, I think they should be released together. Maybe the doxia-maven-plugin should go into sitetools, and the book into tools? Also I'd like to move maven-doxia-tools from shared over to Doxia. Given its description Assists in using Doxia for site generation and report creation. Don't know where you got that from, the current pom [1] says A collection of tools to help the integration of Doxia in Maven plugins. I think we also talked about renaming it to 'doxia-integration-tools' which sounds more descriptive. [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/pom.xml?revision=1214494view=markup I think that Sitetools would be a good home for it. Sounds reasonable. Also the doxia-test-docs should move somewhere else. What are those? They look like they could be the basis of an IT suite. Perhaps it should be a completely separate project under the Doxia umbrella? It's not a project actually, just a collection of test resources. They were originally added to check the correctness of the XSDs, see this mail thread: http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200812.mbox/%3C493D50DF.3040705%40udo.edu%3E It's currently used by xdoc and fml modules, however, I'm not sure of the usefulness, see eg my comment in XdocValidatorTest#testValidateFiles. IMO the validation test would be useful if it tested either a new xsd against the old test files, or some new test files (created by a new doxia module) against the existing xsd. But currently the test takes the old test files (from test-docs) and validates it with the established xsds (fml-1.0-1, xdoc-2.2), so I don't see the point. Just some thoughts, unfortunately I don't have time right now to help with any 'real' work... -Lukas -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html - 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 - 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
instalation maven 3
hi, i want to install maven3 and when i execute this Command mvn archetype:create -DgroupId=testapp -DartifactId=testapp i receive this error: Code: Select all[ERROR] No plugin found for prefix 'archetype' in the current project and in the plugin groups [org.mortbay.jetty, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (C:\Users\RachidaES\.m2\repository), plan etmirror.com (http://downloads.planetmirror.com/pub/maven2)] - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please rea d the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundF orPrefixException please answer me . thank you -- View this message in context: http://maven.40175.n5.nabble.com/instalation-maven-3-tp5607984p5607984.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
configuration maven 3
hi, i want to install maven3 and when i execute this Command mvn archetype:create -DgroupId=testapp -DartifactId=testapp i receive this error: Code: Select all[ERROR] No plugin found for prefix 'archetype' in the current project and in the plugin groups [org.mortbay.jetty, org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (C:\Users\RachidaES\.m2\repository), plan etmirror.com (http://downloads.planetmirror.com/pub/maven2)] - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please rea d the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/NoPluginFoundF orPrefixException please answer me . thank you -- View this message in context: http://maven.40175.n5.nabble.com/configuration-maven-3-tp5607997p5607997.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] move doxia-book and doxia-maven-plugin from Doxia base to Doxia Sitetools
ok so: 1. doxia-book from Doxia to Doxia Sitetools, same artifact coordinates: org.apache.maven.doxia:doxia-book, 1.2 is from Doxia tree, 1.3-SNAPSHOT will be from Doxia Sitetools 2. doxia-maven-plugin from Doxia to Doxia Tools, same artifact coordinates: org.apache.maven.doxia:doxia-maven-plugin 1.2 is from Doxia tree, 1.3-SNAPSHOT will be from Doxia Tools 3. maven-doxia-tools from Maven Shared to Doxia Sitetools, changing artifact coordinates from org.apache.maven.shared:maven-doxia-tools to org.apache.maven.doxia:maven-doxia-tools Notice: the actual name in pom [1] is Maven Doxia Integration Tools, changing the artifactId to maven-doxia-integration-tools would be more complete but IMHO somewhat verbose doxia-test-docs is another story I still don't fully understand, it stays for the moment in Doxia: we can have another look at it after previous changes Regards, Hervé [1] http://maven.apache.org/shared/maven-doxia-tools/project-summary.html Le vendredi 30 mars 2012 10:07:16 Lukas Theussl a écrit : Dennis Lundberg wrote: On 2012-03-29 09:13, Lukas Theussl wrote: I agree that they don't belong into core, but I rather thought of moving them into doxia-tools instead. Not sure what is better. This was my thought also. OTOH, neither book nor maven-plugin have been maintained (AFAIK) since they were moved out of the sandbox, and IMO they don't work too well. In particular there are problems reported with Maven 3 (DOXIA-438) which I haven't tested, but I wanted to suggest a long time ago to deprecate and ultimately remove them. If agree that they should be moved, let's start with that. If the target is doxia-tools then let's move them there, prior to the 1.3 release of Doxia and Doxia Sitetools. My feeling about Doxia Tools is that their sub projects shouldn't be released all at the same time. They are individual projects and should have their own release cycles, much like our shared components or plugins. I agree for doxia-tools. Doxia and doxia-sitetools are closer coupled though, I think they should be released together. Maybe the doxia-maven-plugin should go into sitetools, and the book into tools? Also I'd like to move maven-doxia-tools from shared over to Doxia. Given its description Assists in using Doxia for site generation and report creation. Don't know where you got that from, the current pom [1] says A collection of tools to help the integration of Doxia in Maven plugins. I think we also talked about renaming it to 'doxia-integration-tools' which sounds more descriptive. [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/pom.xml?re vision=1214494view=markup I think that Sitetools would be a good home for it. Sounds reasonable. Also the doxia-test-docs should move somewhere else. What are those? They look like they could be the basis of an IT suite. Perhaps it should be a completely separate project under the Doxia umbrella? It's not a project actually, just a collection of test resources. They were originally added to check the correctness of the XSDs, see this mail thread: http://mail-archives.apache.org/mod_mbox/maven-doxia-dev/200812.mbox/%3C493D 50DF.3040705%40udo.edu%3E It's currently used by xdoc and fml modules, however, I'm not sure of the usefulness, see eg my comment in XdocValidatorTest#testValidateFiles. IMO the validation test would be useful if it tested either a new xsd against the old test files, or some new test files (created by a new doxia module) against the existing xsd. But currently the test takes the old test files (from test-docs) and validates it with the established xsds (fml-1.0-1, xdoc-2.2), so I don't see the point. Just some thoughts, unfortunately I don't have time right now to help with any 'real' work... -Lukas -Lukas Hervé BOUTEMY wrote: while working on the relations between components, I finally found why there was something I didn't understand for a long time about Doxia suite structure: Doxia base contains book support through a plugin, but Doxia base doesn't contain documents support -- it's Doxia Sitetools. So we have a circular dependency: doxia-maven-plugin (from Doxia base) - maven-doxia-tools - Doxia-decoration- model (from Doxia SiteTools) - Doxia base (xhtml, fo and itext) IMHO, doxia-book and doxia-maven-plugin should move to Doxia Sitetools [1]. This won't change the artifacts coordinate, so won't change anything for users. But this should help when explaining Doxia suite structure, which has been difficult for a long time, and having a consequence on versioning decision: should we keep base and Sitetools version at the same level or not? Any objection? Did I miss something? Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html
