Re: Fixing MRELEASE-128: PluginDescriptor was not found
Thanks, Benjamin. Got it working ... Regards, - Torben Benjamin Bentmann wrote: [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. org.apache.maven.release maven-release-manager 1.0-alpha-5-TSG true org.apache.maven.release maven-release-plugin 2.0-beta-8-TSG true The maven-release-manager is not a plugin and as such has no plugin descriptor. It's merely a dependency (with packaging "jar") of the maven-release-plugin. You shouldn't have to specify this directly in the POMs for your test projects, it should be picked up automatically by Maven when resolving the dependencies for maven-release-plugin:2.0-beta-8-TSG, which you updated as you stated. Also note that you specified a wrong groupId for maven-release-plugin, it's actually org.apache.maven.plugins. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
On 5-Apr-08, at 3:13 PM, Benjamin Bentmann wrote: Jason van Zyl wrote: You don't need a 72 hour vote, I would try it in a branch first and then get people to look at it. Just wondering: If I would fill in JIRAs for each affected plugin to request a) adding an encoding parameter if not already existent b) making this parameter default to Latin-1 would we start branches on the plugins for each of these issues? I mean this proposal is not about a revolutionary new feature, it's merely the attempt to create a guideline for consistent encoding handling in the various source processing plugins. More precisely, we're seeking consensus that a) the core team will eventually introduce a new POM element for this in Maven 2.1, named project.build.sourceEncoding or whatever we agree upon I specifically meant the core changes, but I would still recommending what Milos did which was to create branches for a few of the affected plugins to try it all together. Most certainly to test new elements in the POM you need to use a branch because we still don't have a strategy for dealing with model changes. If plugins can be changed, used with the existing versions of Maven with no disruption then do it in-situ. b) in the meantime, Maven 2.0.x will define an equally name property for this in its super POM c) it's OK to have Latin-1 as default encoding rather than the platform encoding Also, this is not going to be a code change that plops out one day as a huge merge back into trunk. Rather, it's an incremental process where the required improvements to plugin X can be made independently of the development on plugin Y. For example, MPLUGIN-101 and MINVOKER-30 already have patches for this topic pending. Is it really expected to open a branch, apply the patches to the branch and merge back (the same day) instead of applying them directly to trunk? Do I underestimate this? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
Jason van Zyl wrote: You don't need a 72 hour vote, I would try it in a branch first and then get people to look at it. Just wondering: If I would fill in JIRAs for each affected plugin to request a) adding an encoding parameter if not already existent b) making this parameter default to Latin-1 would we start branches on the plugins for each of these issues? I mean this proposal is not about a revolutionary new feature, it's merely the attempt to create a guideline for consistent encoding handling in the various source processing plugins. More precisely, we're seeking consensus that a) the core team will eventually introduce a new POM element for this in Maven 2.1, named project.build.sourceEncoding or whatever we agree upon b) in the meantime, Maven 2.0.x will define an equally name property for this in its super POM c) it's OK to have Latin-1 as default encoding rather than the platform encoding Also, this is not going to be a code change that plops out one day as a huge merge back into trunk. Rather, it's an incremental process where the required improvements to plugin X can be made independently of the development on plugin Y. For example, MPLUGIN-101 and MINVOKER-30 already have patches for this topic pending. Is it really expected to open a branch, apply the patches to the branch and merge back (the same day) instead of applying them directly to trunk? Do I underestimate this? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-scm-providers-git initial version
Everything seems to pass, and I'll huck the whole lot under hudson and commit the git provider. On 5-Apr-08, at 2:44 PM, Eugene Kuleshov wrote: struberg wrote: For the really 'edgy' guys out there: I've fixed the maven-scm-provider-git to also work with git-1.5.4. $> git-clone http://ns1.backwork.net/git/maven-scm-providers-git.git as usual... Please provide feedback, so we can move this to codehaus if it's mature enough. Great stuff. I've played with some functionality and it worked with cygwin git after I fixed some minor things on Windows. Left comment on SCM-182. It would be great to bring code under Maven SCM, so we could start using snapshots. regards, Eugene -- View this message in context: http://www.nabble.com/-Vote--Release-Maven-Shared-File-Management-1.2-tp13935505s177p16518358.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-scm-providers-git initial version
struberg wrote: > > For the really 'edgy' guys out there: I've fixed the > maven-scm-provider-git to also work with > git-1.5.4. > > $> git-clone http://ns1.backwork.net/git/maven-scm-providers-git.git > as usual... > > Please provide feedback, so we can move this to codehaus if it's mature > enough. > Great stuff. I've played with some functionality and it worked with cygwin git after I fixed some minor things on Windows. Left comment on SCM-182. It would be great to bring code under Maven SCM, so we could start using snapshots. regards, Eugene -- View this message in context: http://www.nabble.com/-Vote--Release-Maven-Shared-File-Management-1.2-tp13935505s177p16518358.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] AbstractMojo enhancement
On 5-Apr-08, at 12:21 PM, Benjamin Bentmann wrote: Could we make the AbstractMojo class more usefull by providing some commonly-used support methods ? +1 on the general idea to avoid copy&paste, -1 on the proposal to share code via AbstractMojo. For some reason, AbstractMojo is part of the uber JAR and as such updates to it would be bound to the current Maven version. Last but not least, prefering composition over inheritance is usually a better approach to share code among otherwise unrelated components. Having Plexus hanging around, it's seems natural to start up a component for this just like Vincent did with the maven-doxia-tools. Exactly. Composition with component. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kirosawa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] AbstractMojo enhancement
I would use composition instead of inheritance and create helper components for those things. Pushing all the helper methods, when in most cases hardly any of them will be used, is not a good design. We definitely need helps for making classloaders (take the one from jetty run), working with include/excludes, operating on resources, working with dependencies, and so on. This should not all go into the AbstractMojo as it will also expose these things as APIs. A set of components for helping with common tasks where people can pick and choose what they like would be better. On 5-Apr-08, at 12:01 PM, nicolas de loof wrote: Hello, Plugin developer only require to implement the Mojo interface, but in most (all ?) the case they extend AbstractMojo. Having myself created or contributed multiple plugins, I had to solve the same issues many time, using an copy/paste. Could we make the AbstractMojo class more usefull by providing some commonly-used support methods ? I myslef had many time to build a Classloader for the executed project to be able to load project classes from a class processing tool. I've not created a feature lits (yet) but just looking at Maven + Mojo plugins, we could find many common requirements. Nicolas. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] AbstractMojo enhancement
Could we make the AbstractMojo class more usefull by providing some commonly-used support methods ? +1 on the general idea to avoid copy&paste, -1 on the proposal to share code via AbstractMojo. For some reason, AbstractMojo is part of the uber JAR and as such updates to it would be bound to the current Maven version. Last but not least, prefering composition over inheritance is usually a better approach to share code among otherwise unrelated components. Having Plexus hanging around, it's seems natural to start up a component for this just like Vincent did with the maven-doxia-tools. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] AbstractMojo enhancement
Hello, Plugin developer only require to implement the Mojo interface, but in most (all ?) the case they extend AbstractMojo. Having myself created or contributed multiple plugins, I had to solve the same issues many time, using an copy/paste. Could we make the AbstractMojo class more usefull by providing some commonly-used support methods ? I myslef had many time to build a Classloader for the executed project to be able to load project classes from a class processing tool. I've not created a feature lits (yet) but just looking at Maven + Mojo plugins, we could find many common requirements. Nicolas.
Re: [VOTE] POM Element for Source File Encoding
Le samedi 05 avril 2008, nicolas de loof a écrit : > +1 > > Is there any overlap with the tool chain proposal ? as I understand the tool chain proposal, no overlap at all the tool chain is here to let a central place to configure tools on every developer environment (like where is javac 1.5) source file encoding is not tied to a developer's environment: it's precisely the contrary, it has to be configured in the project and the project only (hence the problem with default value being platform encoding, which is implicitely dependent on developer's environment) > > Nico > > 2008/4/5, Hervé BOUTEMY <[EMAIL PROTECTED]>: > > Hi, > > > > Since the discussion on the list about Maven and encoding 2 weeks ago, > > Benjamin and I worked on a proposal to have: > > 1. a central point of configuration of sources encoding, to be used by > > each > > and every plugin, > > 2. a default value set to ISO-8859-1 (instead of platform encoding) to > > have > > build reproducibility by default > > > > The full proposal is here: > > > > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+En > >coding > > > > As you'll see, we've already found 8 Apache plugins to change, and 4 > > Codehaus > > ones. Before starting the code modifications, we need everybody to agree > > on > > the proposal (and complete it if you know other places to change). > > > > The vote will be open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > Here is my +1 > > > > Regards, > > > > Hervé > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
You don't need a 72 hour vote, I would try it in a branch first and then get people to look at it. It's a good idea, just don't do it on trunk directly so that we have the before and after to compare. On 5-Apr-08, at 10:20 AM, Hervé BOUTEMY wrote: Hi, Since the discussion on the list about Maven and encoding 2 weeks ago, Benjamin and I worked on a proposal to have: 1. a central point of configuration of sources encoding, to be used by each and every plugin, 2. a default value set to ISO-8859-1 (instead of platform encoding) to have build reproducibility by default The full proposal is here: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding As you'll see, we've already found 8 Apache plugins to change, and 4 Codehaus ones. Before starting the code modifications, we need everybody to agree on the proposal (and complete it if you know other places to change). The vote will be open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
On Sat, Apr 5, 2008 at 7:20 PM, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: [...] > The full proposal is here: > > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding Non-binding +1 Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
+1 Benjamin Hervé BOUTEMY wrote: Hi, Since the discussion on the list about Maven and encoding 2 weeks ago, Benjamin and I worked on a proposal to have: 1. a central point of configuration of sources encoding, to be used by each and every plugin, 2. a default value set to ISO-8859-1 (instead of platform encoding) to have build reproducibility by default The full proposal is here: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding As you'll see, we've already found 8 Apache plugins to change, and 4 Codehaus ones. Before starting the code modifications, we need everybody to agree on the proposal (and complete it if you know other places to change). The vote will be open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] POM Element for Source File Encoding
+1 Is there any overlap with the tool chain proposal ? Nico 2008/4/5, Hervé BOUTEMY <[EMAIL PROTECTED]>: > > Hi, > > Since the discussion on the list about Maven and encoding 2 weeks ago, > Benjamin and I worked on a proposal to have: > 1. a central point of configuration of sources encoding, to be used by > each > and every plugin, > 2. a default value set to ISO-8859-1 (instead of platform encoding) to > have > build reproducibility by default > > The full proposal is here: > > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding > > As you'll see, we've already found 8 Apache plugins to change, and 4 > Codehaus > ones. Before starting the code modifications, we need everybody to agree > on > the proposal (and complete it if you know other places to change). > > The vote will be open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Here is my +1 > > Regards, > > Hervé > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[VOTE] POM Element for Source File Encoding
Hi, Since the discussion on the list about Maven and encoding 2 weeks ago, Benjamin and I worked on a proposal to have: 1. a central point of configuration of sources encoding, to be used by each and every plugin, 2. a default value set to ISO-8859-1 (instead of platform encoding) to have build reproducibility by default The full proposal is here: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding As you'll see, we've already found 8 Apache plugins to change, and 4 Codehaus ones. Before starting the code modifications, we need everybody to agree on the proposal (and complete it if you know other places to change). The vote will be open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fixing MRELEASE-128: PluginDescriptor was not found
Hi there, I'm trying to fix the bug MRELEASE-128. In order to test my modifications I'd like to run my modified version of the maven-release-manager of course. However, there seems to be a problem with the dependency resolution. While running "mvn release:prepare" on a test project I get the following error: [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. [INFO] [DEBUG] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. -- Here's what I did: (1) I downloaded the following projects from the trunk: maven-release maven-release-manager maven-release-plugin (2) Made some changes in RewritePomsForReleasePhase.java. (3) Assigned new versions to the artifacts: maven-release: 5-SNAPSHOT --> 5-TSG maven-release-manager: 1.0-alpha-5-SNAPSHOT --> 1.0-alpha-5-TSG maven-release-plugin: 2.0-beta-8-SNAPSHOT --> 2.0-beta-8-TSG (4) Updated the versions of the dependencies in the POMs accordingly. (5) Performed "mvn clean install" in maven-release. All goes well and the new versions are successfully installed in my local repository. (6) In my test project, I force the use of the new plugins: org.apache.maven.release maven-release-manager 1.0-alpha-5-TSG true org.apache.maven.release maven-release-plugin 2.0-beta-8-TSG true (7) Now I run "mvn -X -B clean release:clean release:prepare -DdryRun=true -DautoVersionSubmodules=true" in my test project ... and this is the result: + Error stacktraces are turned on. Maven version: 2.0.6 [DEBUG] Building Maven user-level plugin registry from: '/Users/torbengee/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/usr/share/maven/conf/plugin-registry.xml' [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] mvn-test-parent [INFO] mvn-test-subproject-bar [INFO] mvn-test-subproject-foo [INFO] Searching repository for plugin with prefix: 'release'. [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] maven-release-plugin: resolved to version 2.0-beta-8-TSG from local repository [DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release::5-TSG for project: org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.release:maven-release:pom:5-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [INFO] [INFO] Building mvn-test-parent [INFO]task-segment: [clean] [INFO] [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] maven-clean-plugin: resolved to version 2.2 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::10 for project: null:maven-clean-plugin:maven-plugin:2.2 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release::5-TSG for project: null:maven-release-manager:jar:1.0-alpha-5-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.release:maven-release:pom:5-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [DEBUG] Adding managed depedendencies for unknown:maven-release-manager [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.8 [INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. [INFO] -
Re: Fixing MRELEASE-128: PluginDescriptor was not found
[INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. org.apache.maven.release maven-release-manager 1.0-alpha-5-TSG true org.apache.maven.release maven-release-plugin 2.0-beta-8-TSG true The maven-release-manager is not a plugin and as such has no plugin descriptor. It's merely a dependency (with packaging "jar") of the maven-release-plugin. You shouldn't have to specify this directly in the POMs for your test projects, it should be picked up automatically by Maven when resolving the dependencies for maven-release-plugin:2.0-beta-8-TSG, which you updated as you stated. Also note that you specified a wrong groupId for maven-release-plugin, it's actually org.apache.maven.plugins. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fixing MRELEASE-128: PluginDescriptor was not found
Hi there, I'm trying to fix the bug MRELEASE-128. In order to test my modifications I'd like to run my modified version of the maven-release-manager of course. However, there seems to be a problem with the dependency resolution. While running "mvn release:prepare" on a test project I get the following error: [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. [INFO] [DEBUG] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. -- Here's what I did: (1) I downloaded the following projects from the trunk: maven-release maven-release-manager maven-release-plugin (2) Made some changes in RewritePomsForReleasePhase.java. (3) Assigned new versions to the artifacts: maven-release: 5-SNAPSHOT --> 5-TSG maven-release-manager: 1.0-alpha-5-SNAPSHOT --> 1.0-alpha-5-TSG maven-release-plugin: 2.0-beta-8-SNAPSHOT --> 2.0-beta-8-TSG (4) Updated the versions of the dependencies in the POMs accordingly. (5) Performed "mvn clean install" in maven-release. All goes well and the new versions are successfully installed in my local repository. (6) In my test project, I force the use of the new plugins: org.apache.maven.release maven-release-manager 1.0-alpha-5-TSG true org.apache.maven.release maven-release-plugin 2.0-beta-8-TSG true (7) Now I run "mvn -X -B clean release:clean release:prepare -DdryRun=true -DautoVersionSubmodules=true" in my test project ... and this is the result: + Error stacktraces are turned on. Maven version: 2.0.6 [DEBUG] Building Maven user-level plugin registry from: '/Users/torbengee/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/usr/share/maven/conf/plugin-registry.xml' [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] mvn-test-parent [INFO] mvn-test-subproject-bar [INFO] mvn-test-subproject-foo [INFO] Searching repository for plugin with prefix: 'release'. [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] maven-release-plugin: resolved to version 2.0-beta-8-TSG from local repository [DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release::5-TSG for project: org.apache.maven.plugins:maven-release-plugin:maven-plugin:2.0-beta-8-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.release:maven-release:pom:5-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [INFO] [INFO] Building mvn-test-parent [INFO]task-segment: [clean] [INFO] [DEBUG] Skipping disabled repository apache.snapshots [DEBUG] maven-clean-plugin: resolved to version 2.2 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::10 for project: null:maven-clean-plugin:maven-plugin:2.2 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven.release:maven-release::5-TSG for project: null:maven-release-manager:jar:1.0-alpha-5-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.release:maven-release:pom:5-TSG from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [DEBUG] Adding managed depedendencies for unknown:maven-release-manager [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.8 [INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-release-manager] was not found. [INFO] [DEBUG] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.release:maven-
[ANN] Maven Eclipse Plugin 2.5.1 Released
The Maven team is pleased to announce the release of the Maven Eclipse Plugin, version 2.5.1 This plugin is used to generate Eclipse IDE files (*.classpath, *.wtpmodules and the .settings folder) for use with a project. http://maven.apache.org/plugins/maven-eclipse-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: org.apache.maven.plugins maven-eclipse-plugin 2.5.1 This release fixes several bugs. Release Notes - Maven 2.x Eclipse Plugin - Version 2.5.1 ** Bug * [MECLIPSE-266] - plugin applies java facet to ear project * [MECLIPSE-411] - manifest property usage is only for ogsi maifests * [MECLIPSE-412] - Generation of jst.java Facet for EAR packaging kills my RAD workspace * [MECLIPSE-413] - EclipseOSGiManifestWriter uses the artifact id and not the EclipseProjectName ** New Feature * [MECLIPSE-405] - to-maven target should allow to strip qualifier when creating artifacts from osgi bundles Enjoy, -The Maven team .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
