Re: [VOTE] Release Maven Clean Plugin 2.4

2010-01-14 Thread Benjamin Bentmann

Vote open for 72 hours.


Ping.


Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [VOTE] Release Maven Clean Plugin 2.4

2010-01-14 Thread Vincent Siveton
+1

Vincent

2010/1/10 Benjamin Bentmann benjamin.bentm...@udo.edu:
 Hi,

 We solved 2 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=14882

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11128status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-022/

 Staging site:
 http://maven.apache.org/plugins/maven-clean-plugin-2.4/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 +1 from me.


 Benjamin

 -
 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: [VOTE] Release Maven Clean Plugin 2.4

2010-01-14 Thread nicolas de loof
+1

Nicolas

2010/1/14 Vincent Siveton vsive...@apache.org

 +1

 Vincent

 2010/1/10 Benjamin Bentmann benjamin.bentm...@udo.edu:
  Hi,
 
  We solved 2 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=14882
 
  There are still a couple of issues left in JIRA:
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11128status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-022/
 
  Staging site:
  http://maven.apache.org/plugins/maven-clean-plugin-2.4/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  +1 from me.
 
 
  Benjamin
 
  -
  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: [VOTE] Release Maven SCM 1.3 (Take 2)

2010-01-14 Thread Olivier Lamy
Ping.

Thanks,
--
Olivier

2010/1/11 Olivier Lamy ol...@apache.org:
 Hi,

 In preparation of the Release Plugin release, I'd like to release Maven Scm 
 1.3.

 We solved 33 issues :
 http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14523styleName=TextprojectId=10527Create=Create.

 Staging repo:
 https://repository.apache.org/content/repositories/maven-024/

 Staging site:
 Scm : http://maven.apache.org/scm-1.3
 Scm Plugin : http://maven.apache.org/scm-1.3/maven-scm-plugin

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Here my +1.

 Thanks,
 --
 Olivier




-- 
Olivier

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [VOTE] Release Maven Clean Plugin 2.4

2010-01-14 Thread Kristian Rosenvold
+1 

Kristian

On Thu, 2010-01-14 at 05:43 -0500, Vincent Siveton wrote:
 +1
 
 Vincent
 
 2010/1/10 Benjamin Bentmann benjamin.bentm...@udo.edu:
  Hi,
 
  We solved 2 issues:
  http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=14882
 
  There are still a couple of issues left in JIRA:
  http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11128status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-022/
 
  Staging site:
  http://maven.apache.org/plugins/maven-clean-plugin-2.4/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  +1 from me.
 
 
  Benjamin
 
  -
  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



[Help] How to use component in maven?

2010-01-14 Thread 旁清
Hi,

I'm trying to write a maven plugin(mojo). I know there are some shared
plexus components in maven. Besides them,I also found there are some other
components in maven, such as MavenFileFilter in
maven-filtering, MavenProjectHelper in maven-project, etc. I hope to know
how to use these components in maven, but only found API docs just
containing method signature. Is there anyone can provide any information on
the usage of these components? Or is the source code the only way to know
how to use them?

Thanks in advance!


Releasing maven-eclipse-plugin

2010-01-14 Thread Jason van Zyl
Hi,

There are some issues left in the 2.8 for the maven-eclipse-plugin but if no 
one is going work on it then I'll just release it.

I specifically want to release the addition I've made to the 
maven-eclipse-plugin which will stop the confusion among users where they think 
stuff generated by maven-eclipse-plugin is supported in M2Eclipse.

There are projects like CXF that specifically tell users not to use M2Eclipse, 
which is fine, but I want support issues to fall back to those projects who 
want to support the maven-eclipse-plugin. More often then not they become the 
problem of the M2Eclipse developers. So this is really to partition the support 
where it belongs. It's a simple change, I just added a comment which we will 
detect in M2Eclipse and tell users what they are attempting are not supported.

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: svn commit: r899247 - /maven/plugins/trunk/maven-eclipse-plugin/pom.xml

2010-01-14 Thread Jason van Zyl
Thanks.

On 2010-01-14, at 10:42 AM, br...@apache.org wrote:

 Author: brett
 Date: Thu Jan 14 15:42:24 2010
 New Revision: 899247
 
 URL: http://svn.apache.org/viewvc?rev=899247view=rev
 Log:
 restore snapshot version that was in use
 
 Modified:
maven/plugins/trunk/maven-eclipse-plugin/pom.xml
 
 Modified: maven/plugins/trunk/maven-eclipse-plugin/pom.xml
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-eclipse-plugin/pom.xml?rev=899247r1=899246r2=899247view=diff
 ==
 --- maven/plugins/trunk/maven-eclipse-plugin/pom.xml (original)
 +++ maven/plugins/trunk/maven-eclipse-plugin/pom.xml Thu Jan 14 15:42:24 2010
 @@ -27,7 +27,7 @@
 version14/version
   /parent
   artifactIdmaven-eclipse-plugin/artifactId
 -  version2.7/version
 +  version2.8-SNAPSHOT/version
   packagingmaven-plugin/packaging
   nameMaven Eclipse Plugin/name
   descriptionThe Eclipse Plugin is used to generate Eclipse IDE files 
 (.project, .classpath and the .settings folder) from a POM./description
 
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing maven-eclipse-plugin

2010-01-14 Thread Daniel Kulp


Can we at least get a snapshot staged with your changes so I can double check 
that it doesn't break the CXF instructions?

Specifically, we tell people not to use m2eclipse as it generally takes a 
couple HOURS to import CXF into m2eclipse and then the normal edit/save/run 
unit test cycle in m2eclipse takes minutes, not seconds.With the normal 
maven-eclipse-plugin setup and such, it's all MUCH MUCH faster.If the 
m2eclipse experience could match, I'd have no problems recommending it.   But 
it's too painful right now.

Dan


On Thu January 14 2010 10:43:45 am Jason van Zyl wrote:
 Hi,
 
 There are some issues left in the 2.8 for the maven-eclipse-plugin but if
  no one is going work on it then I'll just release it.
 
 I specifically want to release the addition I've made to the
  maven-eclipse-plugin which will stop the confusion among users where they
  think stuff generated by maven-eclipse-plugin is supported in M2Eclipse.
 
 There are projects like CXF that specifically tell users not to use
  M2Eclipse, which is fine, but I want support issues to fall back to those
  projects who want to support the maven-eclipse-plugin. More often then not
  they become the problem of the M2Eclipse developers. So this is really to
  partition the support where it belongs. It's a simple change, I just added
  a comment which we will detect in M2Eclipse and tell users what they are
  attempting are not supported.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 --
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing maven-eclipse-plugin

2010-01-14 Thread Jason van Zyl

On 2010-01-14, at 11:04 AM, Daniel Kulp wrote:

 
 
 Can we at least get a snapshot staged with your changes so I can double check 
 that it doesn't break the CXF instructions?

It's always staged. But my change in sum total is this:

commentNO_M2ECLIPSE_SUPPORT: Project files created with the 
maven-eclipse-plugin are not supported in M2Eclipse./comment

That's enough for us to do the detection we need.

 
 Specifically, we tell people not to use m2eclipse as it generally takes a 
 couple HOURS to import CXF into m2eclipse and then the normal edit/save/run 
 unit test cycle in m2eclipse takes minutes, not seconds.With the normal 
 maven-eclipse-plugin setup and such, it's all MUCH MUCH faster.If the 
 m2eclipse experience could match, I'd have no problems recommending it.   But 
 it's too painful right now.
 
 Dan
 
 
 On Thu January 14 2010 10:43:45 am Jason van Zyl wrote:
 Hi,
 
 There are some issues left in the 2.8 for the maven-eclipse-plugin but if
 no one is going work on it then I'll just release it.
 
 I specifically want to release the addition I've made to the
 maven-eclipse-plugin which will stop the confusion among users where they
 think stuff generated by maven-eclipse-plugin is supported in M2Eclipse.
 
 There are projects like CXF that specifically tell users not to use
 M2Eclipse, which is fine, but I want support issues to fall back to those
 projects who want to support the maven-eclipse-plugin. More often then not
 they become the problem of the M2Eclipse developers. So this is really to
 partition the support where it belongs. It's a simple change, I just added
 a comment which we will detect in M2Eclipse and tell users what they are
 attempting are not supported.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 --
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -- 
 Daniel Kulp
 dk...@apache.org
 http://www.dankulp.com/blog

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing maven-eclipse-plugin

2010-01-14 Thread nicolas de loof
Same issue on my project using m2eclipse = 0.9.8

0.9.9 introduce many improvements that makes m2eclipse compliant with large
multi-modules projets

Nicolas

2010/1/14 Daniel Kulp dk...@apache.org



 Can we at least get a snapshot staged with your changes so I can double
 check
 that it doesn't break the CXF instructions?

 Specifically, we tell people not to use m2eclipse as it generally takes a
 couple HOURS to import CXF into m2eclipse and then the normal edit/save/run
 unit test cycle in m2eclipse takes minutes, not seconds.With the normal
 maven-eclipse-plugin setup and such, it's all MUCH MUCH faster.If the
 m2eclipse experience could match, I'd have no problems recommending it.
 But
 it's too painful right now.

 Dan


 On Thu January 14 2010 10:43:45 am Jason van Zyl wrote:
  Hi,
 
  There are some issues left in the 2.8 for the maven-eclipse-plugin but if
   no one is going work on it then I'll just release it.
 
  I specifically want to release the addition I've made to the
   maven-eclipse-plugin which will stop the confusion among users where
 they
   think stuff generated by maven-eclipse-plugin is supported in M2Eclipse.
 
  There are projects like CXF that specifically tell users not to use
   M2Eclipse, which is fine, but I want support issues to fall back to
 those
   projects who want to support the maven-eclipse-plugin. More often then
 not
   they become the problem of the M2Eclipse developers. So this is really
 to
   partition the support where it belongs. It's a simple change, I just
 added
   a comment which we will detect in M2Eclipse and tell users what they are
   attempting are not supported.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  --
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 --
 Daniel Kulp
 dk...@apache.org
 http://www.dankulp.com/blog

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




Re: Releasing maven-eclipse-plugin

2010-01-14 Thread Jason van Zyl
On 2010-01-14, at 11:09 AM, nicolas de loof wrote:

 Same issue on my project using m2eclipse = 0.9.8
 
 0.9.9 introduce many improvements that makes m2eclipse compliant with large 
 multi-modules projets
 

Folks can do whatever they want for their projects. I just want to stop the 
confusion. Use one method or the other and then users understand clearly where 
to go for support.

 Nicolas
 
 2010/1/14 Daniel Kulp dk...@apache.org
 
 
 Can we at least get a snapshot staged with your changes so I can double check
 that it doesn't break the CXF instructions?
 
 Specifically, we tell people not to use m2eclipse as it generally takes a
 couple HOURS to import CXF into m2eclipse and then the normal edit/save/run
 unit test cycle in m2eclipse takes minutes, not seconds.With the normal
 maven-eclipse-plugin setup and such, it's all MUCH MUCH faster.If the
 m2eclipse experience could match, I'd have no problems recommending it.   But
 it's too painful right now.
 
 Dan
 
 
 On Thu January 14 2010 10:43:45 am Jason van Zyl wrote:
  Hi,
 
  There are some issues left in the 2.8 for the maven-eclipse-plugin but if
   no one is going work on it then I'll just release it.
 
  I specifically want to release the addition I've made to the
   maven-eclipse-plugin which will stop the confusion among users where they
   think stuff generated by maven-eclipse-plugin is supported in M2Eclipse.
 
  There are projects like CXF that specifically tell users not to use
   M2Eclipse, which is fine, but I want support issues to fall back to those
   projects who want to support the maven-eclipse-plugin. More often then not
   they become the problem of the M2Eclipse developers. So this is really to
   partition the support where it belongs. It's a simple change, I just added
   a comment which we will detect in M2Eclipse and tell users what they are
   attempting are not supported.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  --
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 --
 Daniel Kulp
 dk...@apache.org
 http://www.dankulp.com/blog
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--



How to get dependency artifacts for another artifact ?

2010-01-14 Thread maciejmad

Hello. 
Here is a part of simple mojo class:

public class PlatformProviderConfigurer
extends AbstractMojo {

/** @parameter default-value=${project} */
private MavenProject mavenProject;

public void execute() throws MojoExecutionException {
   
SetDefaultArtifact dependencyArtifacts =
mavenProject.getDependencyArtifacts();
SetDefaultArtifact artifacts = mavenProject.getArtifacts();

for (DefaultArtifact defaultArtifact : dependencyArtifacts) {
   //how get dependency artifacts for defaultArtifact 
}
}
}

In this class I can get dependency artifacts for project and all  artifacts
for project. But how I can get  a dependency artifacts for each dependency
artifacts of project (for defaultArtifact  in foreach) ?

Best regards.


-- 
View this message in context: 
http://old.nabble.com/How-to-get-dependency-artifacts-for-another-artifact---tp27167882p27167882.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: How to get dependency artifacts for another artifact ?

2010-01-14 Thread Karl Heinz Marbaise

Hi there,



public class PlatformProviderConfigurer
extends AbstractMojo {

/** @parameter default-value=${project} */
private MavenProject mavenProject;

public void execute() throws MojoExecutionException {
   
SetDefaultArtifact dependencyArtifacts =

mavenProject.getDependencyArtifacts();




SetDefaultArtifact artifacts = mavenProject.getArtifacts();

This will give you the needed information

Set depArtifacts = project.getArtifacts();

for (Iterator depArtIter = depArtifacts.iterator();depArtIter.hasNext(); ) {
 Artifact depArt = (Artifact) depArtIter.next();

 MavenProject depProject = null;
 try
 {
depProject = projectBuilder.buildFromRepository(depArt, 
remoteRepositories, localRepository);

 }
 catch (ProjectBuildingException e)
 {
 throw new MojoExecutionException( Unable to build project:  
+ depArt.getDependencyConflictId(), e );

 }

}


What you need in your Mojo:

/**
 * Used to build a maven projects from artifacts in the remote 
repository.

 *
 * @parameter 
expression=${component.org.apache.maven.project.MavenProjectBuilder}

 * @required
 * @readonly
 */
protected DefaultMavenProjectBuilder projectBuilder;
//* @component 
roleorg.apache.maven.project.DefaultMavenProjectBuilder roleHint=default


/**
 * Location of the local repository.
 *
 * @parameter expression=${localRepository}
 * @readonly
 * @required
 */
protected org.apache.maven.artifact.repository.ArtifactRepository 
localRepository;


/**
 * List of Remote Repositories used by the resolver
 *
 * @parameter expression=${project.remoteArtifactRepositories}
 * @readonly
 * @required
 */
protected java.util.List remoteRepositories;


With the above construct you will get all dependencies incl. the 
transitive dependencies.


Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: How to get dependency artifacts for another artifact ?

2010-01-14 Thread maciejmad

Thanks a lot





Karl Heinz Marbaise-2 wrote:
 
 Hi there,
 
 
 public class PlatformProviderConfigurer
 extends AbstractMojo {
 
 /** @parameter default-value=${project} */
 private MavenProject mavenProject;
 
 public void execute() throws MojoExecutionException {

 SetDefaultArtifact dependencyArtifacts =
 mavenProject.getDependencyArtifacts();
 
 
 SetDefaultArtifact artifacts = mavenProject.getArtifacts();
 This will give you the needed information
 
   Set depArtifacts = project.getArtifacts();
 
 for (Iterator depArtIter = depArtifacts.iterator();depArtIter.hasNext(); )
 {
   Artifact depArt = (Artifact) depArtIter.next();
 
   MavenProject depProject = null;
   try
   {
  depProject = projectBuilder.buildFromRepository(depArt, 
 remoteRepositories, localRepository);
   }
   catch (ProjectBuildingException e)
   {
   throw new MojoExecutionException( Unable to build project:  
 + depArt.getDependencyConflictId(), e );
   }
 
 }
 
 
 What you need in your Mojo:
 
  /**
   * Used to build a maven projects from artifacts in the remote 
 repository.
   *
   * @parameter 
 expression=${component.org.apache.maven.project.MavenProjectBuilder}
   * @required
   * @readonly
   */
  protected DefaultMavenProjectBuilder projectBuilder;
 //* @component 
 roleorg.apache.maven.project.DefaultMavenProjectBuilder
 roleHint=default
 
  /**
   * Location of the local repository.
   *
   * @parameter expression=${localRepository}
   * @readonly
   * @required
   */
  protected org.apache.maven.artifact.repository.ArtifactRepository 
 localRepository;
 
  /**
   * List of Remote Repositories used by the resolver
   *
   * @parameter expression=${project.remoteArtifactRepositories}
   * @readonly
   * @required
   */
  protected java.util.List remoteRepositories;
 
 
 With the above construct you will get all dependencies incl. the 
 transitive dependencies.
 
 Kind regards
 Karl Heinz Marbaise
 -- 
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
 Hauptstrasse 177 USt.IdNr: DE191347579
 52146 Würselen   http://www.soebes.de
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 

-- 
View this message in context: 
http://old.nabble.com/How-to-get-dependency-artifacts-for-another-artifact---tp27167882p27168440.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: [VOTE] Release Maven SCM 1.3 (Take 2)

2010-01-14 Thread Hervé BOUTEMY
+1

Hervé

Le lundi 11 janvier 2010, Olivier Lamy a écrit :
 Hi,
 
 In preparation of the Release Plugin release, I'd like to release Maven Scm
  1.3.
 
 We solved 33 issues :
 http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14523styleName=Te
 xtprojectId=10527Create=Create.
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-024/
 
 Staging site:
 Scm : http://maven.apache.org/scm-1.3
 Scm Plugin : http://maven.apache.org/scm-1.3/maven-scm-plugin
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Here my +1.
 
 Thanks,
 --
 Olivier
 
 -
 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: [VOTE] Release Maven Clean Plugin 2.4

2010-01-14 Thread Hervé BOUTEMY
+1

Hervé

Le dimanche 10 janvier 2010, Benjamin Bentmann a écrit :
 Hi,
 
 We solved 2 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128version=14
 882
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11128st
 atus=1
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-022/
 
 Staging site:
 http://maven.apache.org/plugins/maven-clean-plugin-2.4/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 +1 from me.
 
 
 Benjamin
 
 -
 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: Releasing maven-eclipse-plugin

2010-01-14 Thread Barrie Treloar
On Fri, Jan 15, 2010 at 2:38 AM, Jason van Zyl ja...@sonatype.com wrote:
 commentNO_M2ECLIPSE_SUPPORT: Project files created with the 
 maven-eclipse-plugin are not supported in M2Eclipse./comment

 That's enough for us to do the detection we need.

Are you saying that M2Eclipse will search for this comment and provide
a warning as well?

Can we also update the front page to indicate the M2Eclipse is no
longer supported (and duplicate that in the FAQ) please?

Arnaud is the one with all the outstanding issues - he should comment
if they can get bumped to the next version.
All those unassigned look suitable for bumping.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing maven-eclipse-plugin

2010-01-14 Thread Jason van Zyl

On 2010-01-14, at 6:41 PM, Barrie Treloar wrote:

 On Fri, Jan 15, 2010 at 2:38 AM, Jason van Zyl ja...@sonatype.com wrote:
 commentNO_M2ECLIPSE_SUPPORT: Project files created with the 
 maven-eclipse-plugin are not supported in M2Eclipse./comment
 
 That's enough for us to do the detection we need.
 
 Are you saying that M2Eclipse will search for this comment and provide
 a warning as well?
 

Yes, we'll tell the user we're not importing the project and why. Provide a 
pointer back to the maven-eclipse-plugin and where to get help.

 Can we also update the front page to indicate the M2Eclipse is no
 longer supported (and duplicate that in the FAQ) please?
 

Sure you can.

 Arnaud is the one with all the outstanding issues - he should comment
 if they can get bumped to the next version.
 All those unassigned look suitable for bumping.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
--


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Putting the archetype plugin version in the super POM

2010-01-14 Thread Brett Porter
I think this has come up before and we wanted to avoid doing it for things on 
the command line, where it is hard to override. In general that would be true, 
but for the archetype plugin being the first experience people have with Maven, 
a bit more reliability would probably be useful.

I thought we could apply the patch below in 2.2.2. This would by default lock 
it down, but allow the comparatively simple cmd line to get a different version:

$ mvn archetype:generate -Dmaven.archetype.version=2.0-alpha-6-SNAPSHOT

Or the corresponding change permanently in settings.xml:

profile
  idproperties/id
  properties
maven.archetype.version2.0-alpha-6-SNAPSHOT/maven.archetype.version
  /properties
/profile
...
activeProfiles
  activeProfileproperties/activeProfile
/activeProfiles

The downside is that at the moment this works for settings the version 
correctly when a pom.xml exists, but not when one doesn't (which I think might 
be a bug in 2.2.2 that would also need fixing). I haven't checked trunk but it 
might work there already. Perhaps we might only do it for 3.0 if that's the 
case (esp. since this has a very minor chance of incompatibility if the 
property is in use).

I wouldn't want to do this for every plugin - having magic properties is 
something to be wary of - but this one might be worthwhile as a special case?

Thoughts?

- Brett


Index: maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml
===
--- maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml 
(revision 899508)
+++ maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml 
(working copy)
@@ -68,9 +68,13 @@
 directory${project.basedir}/src/test/resources/directory
   /testResource
 /testResources
-   pluginManagement
-   plugins
+pluginManagement
+  plugins
  plugin
+   artifactIdmaven-archetype-plugin/artifactId
+   version${maven.archetype.version}/version
+ /plugin   
+ plugin
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
  /plugin   
@@ -204,6 +208,8 @@
   /build
 /profile
   /profiles
-
+  properties
+maven.archetype.version2.0-alpha-4/maven.archetype.version
+  /properties
 /project

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Putting the archetype plugin version in the super POM

2010-01-14 Thread Benjamin Bentmann

Brett Porter wrote:


Perhaps we might only do it for 3.0 if that's the case (esp. since this has a 
very minor chance of incompatibility if the property is in use).


Why has the version to be locked down in the first place? Is it to 
prevent usage of a snapshot version? If so, I don't think this applies 
to 3.0 as it prefers RELEASE over LATEST.



Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Putting the archetype plugin version in the super POM

2010-01-14 Thread Brett Porter

On 15/01/2010, at 12:42 PM, Benjamin Bentmann wrote:

 Brett Porter wrote:
 
 Perhaps we might only do it for 3.0 if that's the case (esp. since this has 
 a very minor chance of incompatibility if the property is in use).
 
 Why has the version to be locked down in the first place? Is it to prevent 
 usage of a snapshot version? If so, I don't think this applies to 3.0 as it 
 prefers RELEASE over LATEST.

Ah, I had forgotten about that. That was probably the main reason, but it is 
also valuable to protect the releases. I think these were ones we got bitten by 
before:
http://markmail.org/message/if6sbrsvr2zrvkta
http://markmail.org/message/fgopqlnnhuecfmnq

We are likely more careful with the releases, but as it's something that 
immediately affects all users on a new release, it's probably a little 
disconcerting.

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



[jira] Subscription: Design Best Practices

2010-01-14 Thread jira
Issue Subscription
Filter: Design  Best Practices (23 issues)
Subscriber: mavendevlist

Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-2584Rebuild on pom change
http://jira.codehaus.org/browse/MNG-2584
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
MNG-416 best practices:  multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-41  best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-1441Starting thinking about a proper distributed repository mechanism a 
la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for properties and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1569Make build process info read-only to mojos, and provide mechanism 
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867

You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Deploy snapshot to apache snapshot repo

2010-01-14 Thread Dan Tran
I have a need to deploy maven-scm-plugin-1.4-SNAPSHOT and
maven-dependency-plugin-2.2-SNAPSHOT.  Do they happen automatically?

Also how do have get karma to deploy manually?


Thanks

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: [DISCUSS] Effect of direct plugin invocation on model

2010-01-14 Thread Peter Lynch
On Sun, Jan 10, 2010 at 2:48 PM, Brett Porter br...@apache.org wrote:


 What is the original use case that led to the bug? I'm wondering if it is
 sane and needs the runtime info, or if it actually should have just the POM
 as fully resolved from the repo.

 Cheers,
 Brett

 The code involved is at line 1797 in 
 EclipsePlugin.javahttp://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.7/src/main/java/org/apache/maven/plugin/eclipse/EclipsePlugin.java?view=markup.
   The
issue was opened in response to http://jira.codehaus.org/browse/MECLIPSE-633 .
The plugin code is kinda suspect as I'm not quite sure why the EclipseMojo
just can't rely on the injected parameter it is looking for rather than
parsing its Xpp3Dom directly - guessing as some previous bug work around?
Still, I don't think the project model should change this drastically unless
there is a good reason and it is well documented.

Meanwhile Jason is pushing for a release of the eclipse plugin and until we
reach a consensus on what to do then maven-eclipse-plugin will remain not
passing integration tests for maven 3.

-Peter


Re: Deploy snapshot to apache snapshot repo

2010-01-14 Thread Brett Porter
Try https://repository.apache.org/content/repositories/snapshots/

On 15/01/2010, at 3:10 PM, Dan Tran wrote:

 I have a need to deploy maven-scm-plugin-1.4-SNAPSHOT and
 maven-dependency-plugin-2.2-SNAPSHOT.  Do they happen automatically?
 
 Also how do have get karma to deploy manually?
 
 
 Thanks
 
 -Dan
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing maven-eclipse-plugin

2010-01-14 Thread Peter Lynch
On Thu, Jan 14, 2010 at 10:43 AM, Jason van Zyl ja...@sonatype.com wrote:

 Hi,

 There are some issues left in the 2.8 for the maven-eclipse-plugin but if
 no one is going work on it then I'll just release it.


I have been trying to resolve issues using Maven 3 to build the plugin. I
provided a patch for MECLIPSE-631, no one has applied it and I don't have
karma. It would be nice if someone could apply that one at least before you
release. Issue MECLIPSE-633 is the other one, which seems like it will take
more time to sort out due to MNG-4523.

-Peter


Re: Deploy snapshot to apache snapshot repo

2010-01-14 Thread Dan Tran
they are not there :-) the interested artifacts are quite old.

So I guess they are not automatically deployed.

-D

On Thu, Jan 14, 2010 at 8:23 PM, Brett Porter br...@apache.org wrote:
 Try https://repository.apache.org/content/repositories/snapshots/

 On 15/01/2010, at 3:10 PM, Dan Tran wrote:

 I have a need to deploy maven-scm-plugin-1.4-SNAPSHOT and
 maven-dependency-plugin-2.2-SNAPSHOT.  Do they happen automatically?

 Also how do have get karma to deploy manually?


 Thanks

 -Dan

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/





 -
 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: Deploy snapshot to apache snapshot repo

2010-01-14 Thread Brett Porter

On 15/01/2010, at 3:38 PM, Dan Tran wrote:

 they are not there :-) the interested artifacts are quite old.
 
 So I guess they are not automatically deployed.

Ah, I saw the Jan 15 on 
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-dependency-plugin/,
 but I guess it gets touched regularly.

You might need to configure them in the grid.

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Releasing maven-eclipse-plugin

2010-01-14 Thread Barrie Treloar
On Fri, Jan 15, 2010 at 2:54 PM, Peter Lynch pe...@peterlynch.ca wrote:
 On Thu, Jan 14, 2010 at 10:43 AM, Jason van Zyl ja...@sonatype.com wrote:

 Hi,

 There are some issues left in the 2.8 for the maven-eclipse-plugin but if
 no one is going work on it then I'll just release it.


 I have been trying to resolve issues using Maven 3 to build the plugin. I
 provided a patch for MECLIPSE-631, no one has applied it and I don't have
 karma. It would be nice if someone could apply that one at least before you
 release. Issue MECLIPSE-633 is the other one, which seems like it will take
 more time to sort out due to MNG-4523.

Can these wait for the next release cycle?

I dont believe there is anyone actively watching new issues for the plugin.
Your best bet is to ping the dev list with your issue and gather
support for the bug and find someone willing to commit your patches.

I have only been watching the list for Maven 3 and am not actively
involved so I haven't attempted to use it to build m-e-p.
I may have a few spare cycles shortly - is setting up my environment
simple enough and documented somewhere?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org