Re: [VOTE] Release Maven archetype plugin version 2.0-alpha-3 [take 3]
+1 Milos On Fri, Apr 25, 2008 at 6:17 AM, Jason Dillon <[EMAIL PROTECTED]> wrote: > +1 > > --jason > > > > > On Apr 25, 2008, at 5:10 AM, Raphaël Piéroni wrote: > > > > Hi, > > > > We solved 22 issues: > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 > > > > Staging repo: > > http://people.apache.org/~rafale/archetype-stage-repository/ > > > > Staging site: > > http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > Raphaël > > > > > - > 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] Release Maven archetype plugin version 2.0-alpha-3 [take 3]
+1 --jason On Apr 25, 2008, at 5:10 AM, Raphaël Piéroni wrote: Hi, We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (29 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-3313NetBeans projects, more than ant project, more than free form project. http://jira.codehaus.org/browse/MNG-3313 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-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 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-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 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-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-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-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where should release plugin copy from?
I think we've talked a bit about a more flexible workflow to the release, and doing some alternatives like creating a branch at the release point and switching to it. I think it would be best for us to lock down a 2.0 "final" release first before taking something like that on, but if you wanted to try something in the sandbox it'd be interesting to see :) On 25/04/2008, at 1:07 AM, David Jencks wrote: In my experience the release plugin currently works like this: 1. modifies working copy poms to release version 2. commits poms 3. does a repo-repo copy to the new tag 4. updates working copy poms to the new version 5. commits new-version poms. Some projects (activemq) have a versioning scheme whereby branches, say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The current release plugin process thus results in 2 commits to all the poms in the branch that modify the versions, then modify them back to their original values. This creates a fair amount of noise in the scm lists. Would it be possible for the release plugin to do the following? 1. modify working copy poms to release version 2. do a working copy to repo copy for the new tag 3. adjust the working copy poms to the new version, or revert if the new version is the same as the old version 4. commit the working copy poms if there is a new version. Is this process svn specific? If so could it be provided as an option? thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] New Jira project for shared?
On 24/04/2008, at 8:58 PM, Brian E. Fox wrote: I thought we already had this, but I guess it was for the sandbox. Sounds logical to add it for shared. That's what I thought too. Go for it. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Maven archetype plugin version 2.0-alpha-3 [take 3]
+1 looks good. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raphaël Piéroni Sent: Thursday, April 24, 2008 6:10 PM To: Maven Developers List Subject: [VOTE] Release Maven archetype plugin version 2.0-alpha-3 [take 3] Hi, We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Raphaël
[VOTE] Release Maven archetype plugin version 2.0-alpha-3 [take 3]
Hi, We solved 22 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Raphaël
Re: [Discuss] New Jira project for shared?
For me too, I created MPA-113 Cheers, Vincent 2008/4/24 Mark Hobson <[EMAIL PROTECTED]>: > Sounds good to me, MSHARED? > > Mark > > > > On 24/04/2008, Vincent Siveton <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I am preparing the release of maven-doxia-tools (MSITE-301) which is > > the first step for several plugins releases. > > > > Background: > > - maven-doxia-tools is in shared svn space and the Jira project for > > shared is a MNG component. > > - we have also an component called "doxia integration" in MSITE > > - DOXIATOOLS is a Jira project for Doxia tools [1] which is NOT for > > the Maven integration Doxia tools ie (maven-doxia-tools) > > > > Proposal: > > I propose to create a new Jira Shared project and create several > > components, one for each shared projects. > > > > Thoughts? > > > > Cheers, > > > > Vincent > > > > [1] https://svn.apache.org/repos/asf/maven/doxia/doxia-tools/trunk > > > > > > - > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][Result] Release Maven Archetype plugin version 2.0-alpha-3 [take 2]
Hi It is now time to count the votes. +1 non binding: Raphaël, Jason, Milos +1 binding: Lukas, Arnaud -1 binding: Brian (in the wrong thread but still counted ;-)) The vote failed. I fix the issue Brian saw with version and i rewrap for a new vote. Regards, Raphaël 2008/4/23 Milos Kleint <[EMAIL PROTECTED]>: > yup. changing to +1. > Still investigating the issue with embedded use, most probably issue > with the 2.1-SNAPSHOT core maven. > > Milos > > On Wed, Apr 23, 2008 at 5:26 PM, Raphaël Piéroni > > > <[EMAIL PROTECTED]> wrote: > > IIRC the > > mvn archetype:generate -Darchetype.interactive=false > > can be safely replaced with > > mvn archetype:generate -B > > > > > > In your correction email, you didn't changed your -1, is it intentional? > > or did you just forget changing to +1 ;-) > > > > Regards, > > > > Raphaël > > > > 2008/4/23 Milos Kleint <[EMAIL PROTECTED]>: > > > > > > > correction. I seems to be connected to 2.1-SNAPSHOT embedded maven. > > > with command-line 2.0.9 it works fine. I use > > > -Darchetype.interactive=false in both cases.. > > > > > > Milos > > > > > > > > > > > > On Wed, Apr 23, 2008 at 3:42 PM, Milos Kleint <[EMAIL PROTECTED]> > wrote: > > > > -1 the generate goal in non-interactive mode asks for confirmation > of values.. > > > > > > > > Milos > > > > > > > > > > > > > > > > On Wed, Apr 23, 2008 at 2:38 PM, Brian E. Fox <[EMAIL PROTECTED]> > wrote: > > > > > Thanks for the reminder. I will look this morning. > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, April 23, 2008 6:18 AM > > > > > To: Maven Developers List > > > > > Subject: Re: [VOTE] Release Maven Archetype plugin version > 2.0-alpha-3 [take 2] > > > > > > > > > > anyone else (I really need this release ;-) ) > > > > > > > > > > Arnaud > > > > > > > > > > On Tue, Apr 22, 2008 at 9:14 AM, Raphaël Piéroni > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > According To the committer list in > > > > > > http://svn.apache.org/repos/asf/maven/pom/trunk/maven/pom.xml > > > > > > We have currently: > > > > > > 2 non binding vote (Jason, Raphaël) > > > > > > 1 binding vote (Arnaud) > > > > > > > > > > > > IIRC the voting process, we need 3 binding vote (PMC), for a > > > > > > plugin release. > > > > > > > > > > > > Please dear PMC members, give a try to the plugin. > > > > > > > > > > > > I keep the vote open for 2 more days (48 hours) > > > > > > > > > > > > Regards, > > > > > > > > > > > > Raphaël > > > > > > > > > > > > 2008/4/20 Arnaud HERITIER <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > Arnaud > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Apr 19, 2008 at 11:02 AM, Jason Dillon <[EMAIL > PROTECTED]> wrote: > > > > > > > > +1 > > > > > > > > > > > > > > > > --jason > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Apr 19, 2008, at 1:39 AM, Raphaël Piéroni wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > We solved 22 issues: > > > > > > > > > > > > > > > > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 > > > > > > > > > > > > > > > > > > Staging repo: > > > > > > > > > > http://people.apache.org/~rafale/archetype-stage-repository/ > > > > > > > > > > > > > > > > > > Staging site: > > > > > > > > > > http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/ > > > > > > > > > > > > > > > > > > Guide to testing staged releases: > > > > > > > > > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > > > > > > > > > > > > > Vote open for 72 hours. > > > > > > > > > > > > > > > > > > [ ] +1 > > > > > > > > > [ ] +0 > > > > > > > > > [ ] -1 > > > > > > > > > > > > > > > > > > Raphaël > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > .. > > > > > > > Arnaud HERITIER > > >
RE: [VOTE] Release Maven Archetype plugin version 2.0-alpha-3
Taking back the -1 since I found this to be a local configuration issue. I found that the default behavior no longer prompts you for the version you are creating, just the group,artifact,version,package. You have to say N to the prompt and re-enter all the values to change the version. This is a little confusing, especially if you're used to the old way. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 11:42 AM To: Maven Developers List Subject: RE: [VOTE] Release Maven Archetype plugin version 2.0-alpha-3 -1 for now since I'm getting an error: Choose a number: (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/3 4/35/36/37/38/39/40/41/42/43/44) 15: : 15 [INFO] artifact org.apache.maven.archetypes:maven-archetype-quickstart: checking for updates from maven-archet ype-quickstart-repo [INFO] artifact org.apache.maven.archetypes:maven-archetype-quickstart: checking for updates from central [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] : org.apache.maven.archetype.exception.UnknownArchetype: The desired archetype does not exist (org.apac he.maven.archetypes:maven-archetype-quickstart:RELEASE) The desired archetype does not exist (org.apache.maven.archetypes:maven-archetype-quickstart:RELEASE) The desired archetype does not exist (org.apache.maven.archetypes:maven-archetype-quickstart:RELEASE) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 26 seconds [INFO] Finished at: Wed Apr 23 11:39:45 EDT 2008 [INFO] Final Memory: 8M/14M [INFO] This is with 2.0.9 and a mirrorOf external:* pointed to my public Nexus group. -Original Message- From: Raphaël Piéroni [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 6:22 PM To: Maven Developers List Subject: [VOTE] Release Maven Archetype plugin version 2.0-alpha-3 Hi, We solved 20 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088 Staging repo: http://people.apache.org/~rafale/archetype-stage-repository/ Staging site: http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Regards, Raphaël
Re: Where should release plugin copy from?
On Apr 24, 2008, at 10:18 AM, Brian E. Fox wrote: I was pretty sure it does tag from the working copy? well from a release I did on march 12 New Revision: 636232 URL: http://svn.apache.org/viewvc?rev=636232&view=rev Log: [maven-release-plugin] prepare release directory-parent-1.0 Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory-server/ pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory/pom.xml geronimo/plugins/directory/branches/1.0/pom.xml Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml URL: http://svn.apache.org/viewvc/geronimo/plugins/directory/branches/1.0/directory/pom.xml?rev=636232&r1=636231&r2=636232&view=diff = = = = = = --- geronimo/plugins/directory/branches/1.0/directory/pom.xml (original) +++ geronimo/plugins/directory/branches/1.0/directory/pom.xml Wed Mar 12 00:23:14 2008 @@ -25,7 +25,7 @@ org.apache.geronimo.plugins directory-parent -1.0-SNAPSHOT +1.0 ../pom.xml .. New Revision: 636234 URL: http://svn.apache.org/viewvc?rev=636234&view=rev Log: [maven-release-plugin] copy for tag directory-parent-1.0 Added: geronimo/plugins/directory/tags/directory-parent-1.0/ - copied from r635397, geronimo/plugins/directory/branches/1.0/ New Revision: 636235 URL: http://svn.apache.org/viewvc?rev=636235&view=rev Log: [maven-release-plugin] prepare for next development iteration Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory-server/ pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory/pom.xml geronimo/plugins/directory/branches/1.0/pom.xml Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml URL: http://svn.apache.org/viewvc/geronimo/plugins/directory/branches/1.0/directory/pom.xml?rev=636235&r1=636234&r2=636235&view=diff = = = = = = --- geronimo/plugins/directory/branches/1.0/directory/pom.xml (original) +++ geronimo/plugins/directory/branches/1.0/directory/pom.xml Wed Mar 12 00:26:14 2008 @@ -25,7 +25,7 @@ org.apache.geronimo.plugins directory-parent -1.0 +1.0.1-SNAPSHOT ../pom.xml . which looks to me like the release plugin is following the process I outlined. thanks david jencks ... -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 1:07 PM To: Maven Developers List Subject: Where should release plugin copy from? In my experience the release plugin currently works like this: 1. modifies working copy poms to release version 2. commits poms 3. does a repo-repo copy to the new tag 4. updates working copy poms to the new version 5. commits new-version poms. Some projects (activemq) have a versioning scheme whereby branches, say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The current release plugin process thus results in 2 commits to all the poms in the branch that modify the versions, then modify them back to their original values. This creates a fair amount of noise in the scm lists. Would it be possible for the release plugin to do the following? 1. modify working copy poms to release version 2. do a working copy to repo copy for the new tag 3. adjust the working copy poms to the new version, or revert if the new version is the same as the old version 4. commit the working copy poms if there is a new version. Is this process svn specific? If so could it be provided as an option? thanks david jencks - 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: [proposal] eclipse plugin extensibility
Flex / Flex builder I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin If this goes on, I can create flexbuilder extension. VELO On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni <[EMAIL PROTECTED]> wrote: > Hi Nicolas, > yes, many Maven plugins have an Eclipse counterpart, and having the > eclipse plugin discover this plugins and delegate to them the generation > of eclipse specific configurations is a great idea. I don't know the > internals of the Eclipse plugin well enough to understand the details of > your proposal, but it sounds very interesting. Any comment from the > Maven community? > > Just to name a few, these are the technologies that i use extensively > and have both maven and eclipse support that could be harmonized: > - Obviously the java compiler itself :) > - The Maven eclipse plugin > - AspectJ > - Hibernate > - Spring > - Jetty (would it be possible to make some generation of configurations > for Eclipse WST?) > - Emma, Clover > - FindBugs > > Which else? > > Simone > > > nicolas de loof wrote: > > Hello, > > > > I'd like to propose an extension mecanism for the Eclipse plugin (and > > potentially for other plugins). > > > > The sysdeo-tomcat-maven-plugin (mojo project) for example has > copie/pasted > > the dependency resolution code from eclipse plugin. This was required to > > create the .tomcatPlugin configuration file. > > If this plugin code could execute *inside* the eclipse plugin as an > > EclipseWriter it could benefict from the original code, and also from > plugin > > updates. > > > > I propose to add a new extensibility feature in the eclipse plugin. Using > a > > new parameter, or maybe by searching some "extension" file in the plugin > > classpath, the eclipse plugin could setup a list of external > EclipseWriters > > to run. > > > > sample configuration : > > > > > > maven-eclipse-plugin > > > > ... > > > > > > sysdeo-tomcat > > > > > > > > > > > > > > > > > > > > org.codehaus.mojo > > sysdeo-tomcat-maven-plugin > > x > > > > > > > > > > > > > > Beeing added to the plugin classpath, the "plugin-extension" could add > it's > > EclipseWriters, and maybe other optional components (to setup > ProjectNatures > > ?). > > > > Many other extensions could be added this way to the eclipse plugin : > > generate SpringIDE configuration, setup Checkstyle in sync with the > > maven-checkstyle configuration, etc. > > > > Another benefict is that the "extension" could benefict from the forked > > generate-source execution that the eclipse-plugin runs, to access the > list > > of multi-project modules. > > > > > > Any suggestion is welcome. > > > > Nicolas. > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: Where should release plugin copy from?
I was pretty sure it does tag from the working copy? -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 1:07 PM To: Maven Developers List Subject: Where should release plugin copy from? In my experience the release plugin currently works like this: 1. modifies working copy poms to release version 2. commits poms 3. does a repo-repo copy to the new tag 4. updates working copy poms to the new version 5. commits new-version poms. Some projects (activemq) have a versioning scheme whereby branches, say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The current release plugin process thus results in 2 commits to all the poms in the branch that modify the versions, then modify them back to their original values. This creates a fair amount of noise in the scm lists. Would it be possible for the release plugin to do the following? 1. modify working copy poms to release version 2. do a working copy to repo copy for the new tag 3. adjust the working copy poms to the new version, or revert if the new version is the same as the old version 4. commit the working copy poms if there is a new version. Is this process svn specific? If so could it be provided as an option? thanks david jencks - 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]
Where should release plugin copy from?
In my experience the release plugin currently works like this: 1. modifies working copy poms to release version 2. commits poms 3. does a repo-repo copy to the new tag 4. updates working copy poms to the new version 5. commits new-version poms. Some projects (activemq) have a versioning scheme whereby branches, say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The current release plugin process thus results in 2 commits to all the poms in the branch that modify the versions, then modify them back to their original values. This creates a fair amount of noise in the scm lists. Would it be possible for the release plugin to do the following? 1. modify working copy poms to release version 2. do a working copy to repo copy for the new tag 3. adjust the working copy poms to the new version, or revert if the new version is the same as the old version 4. commit the working copy poms if there is a new version. Is this process svn specific? If so could it be provided as an option? thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] New Jira project for shared?
Sounds good to me, MSHARED? Mark On 24/04/2008, Vincent Siveton <[EMAIL PROTECTED]> wrote: > Hi, > > I am preparing the release of maven-doxia-tools (MSITE-301) which is > the first step for several plugins releases. > > Background: > - maven-doxia-tools is in shared svn space and the Jira project for > shared is a MNG component. > - we have also an component called "doxia integration" in MSITE > - DOXIATOOLS is a Jira project for Doxia tools [1] which is NOT for > the Maven integration Doxia tools ie (maven-doxia-tools) > > Proposal: > I propose to create a new Jira Shared project and create several > components, one for each shared projects. > > Thoughts? > > Cheers, > > Vincent > > [1] https://svn.apache.org/repos/asf/maven/doxia/doxia-tools/trunk > > - > 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: a way to extend the dependencies at build time
I did this with Maven 1 and I'm sure it would work with Maven 2, but it may not be what your want. The way I handled it was to dynamically construct the pom in a target directory along with the project files and then invoke the goal (plugin) calls Maven again just for that project. Richard van Nieuwenhoven wrote: Hi, That is why i ask for an "official" solution, a plugin will probably not work. But is there an other? like a custom "dependence resolution component" for this project. Or a global custom "dependence resolution component". Or a way to dynamically create a global or local profile. Or .. any ideas? thanks for the help, Ritchie Gilles Scokart wrote: On 24/04/2008, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote: Hi, the reason i need it is that a plugin generates code that depends on a framework in a specific configuration. And the knowledge witch combination of frameworks is needed, is provided by the generator (the plugin). I do not like to duplicate this knowledge in evey module that uses the plugin, this is why i would like the plugin (or some other mean) to include the dependencies in the ProjectModel. The IDE integration should be no problem because the included dependencies would (and must) be included in the ProjectModel and therefore are propagated to all running plugins as if they were in the pom directly. mfg Ritchie Only if the plugin is executed. IDE (or other tools like Ivy for instance) don't run the plugins to use the dependency informations. Also think to what you will publish to a repository. The projects that depends on the project using the plugin will not execute your plugin neither. - 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: [Discuss] New Jira project for shared?
I thought we already had this, but I guess it was for the sandbox. Sounds logical to add it for shared. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Siveton Sent: Thursday, April 24, 2008 8:51 AM To: Maven Developers List Subject: [Discuss] New Jira project for shared? Hi, I am preparing the release of maven-doxia-tools (MSITE-301) which is the first step for several plugins releases. Background: - maven-doxia-tools is in shared svn space and the Jira project for shared is a MNG component. - we have also an component called "doxia integration" in MSITE - DOXIATOOLS is a Jira project for Doxia tools [1] which is NOT for the Maven integration Doxia tools ie (maven-doxia-tools) Proposal: I propose to create a new Jira Shared project and create several components, one for each shared projects. Thoughts? Cheers, Vincent [1] https://svn.apache.org/repos/asf/maven/doxia/doxia-tools/trunk - 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: a way to extend the dependencies at build time
Have you looked at the new import scope feature? -Original Message- From: Richard van Nieuwenhoven [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 6:47 AM To: Maven Developers List Subject: Re: a way to extend the dependencies at build time Hi, That is why i ask for an "official" solution, a plugin will probably not work. But is there an other? like a custom "dependence resolution component" for this project. Or a global custom "dependence resolution component". Or a way to dynamically create a global or local profile. Or .. any ideas? thanks for the help, Ritchie Gilles Scokart wrote: > On 24/04/2008, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote: >> Hi, >> >> the reason i need it is that a plugin generates code that depends on a >> framework in a specific configuration. And the knowledge witch >> combination of frameworks is needed, is provided by the generator (the >> plugin). I do not like to duplicate this knowledge in evey module that >> uses the plugin, this is why i would like the plugin (or some other >> mean) to include the dependencies in the ProjectModel. >> >> The IDE integration should be no problem because the included >> dependencies would (and must) be included in the ProjectModel and >> therefore are propagated to all running plugins as if they were in the >> pom directly. >> >> mfg >> Ritchie >> > Only if the plugin is executed. IDE (or other tools like Ivy for > instance) don't run the plugins to use the dependency informations. > > Also think to what you will publish to a repository. The projects > that depends on the project using the plugin will not execute your > plugin neither. > - 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]
[Discuss] New Jira project for shared?
Hi, I am preparing the release of maven-doxia-tools (MSITE-301) which is the first step for several plugins releases. Background: - maven-doxia-tools is in shared svn space and the Jira project for shared is a MNG component. - we have also an component called "doxia integration" in MSITE - DOXIATOOLS is a Jira project for Doxia tools [1] which is NOT for the Maven integration Doxia tools ie (maven-doxia-tools) Proposal: I propose to create a new Jira Shared project and create several components, one for each shared projects. Thoughts? Cheers, Vincent [1] https://svn.apache.org/repos/asf/maven/doxia/doxia-tools/trunk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a way to extend the dependencies at build time
Hi, That is why i ask for an "official" solution, a plugin will probably not work. But is there an other? like a custom "dependence resolution component" for this project. Or a global custom "dependence resolution component". Or a way to dynamically create a global or local profile. Or .. any ideas? thanks for the help, Ritchie Gilles Scokart wrote: > On 24/04/2008, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote: >> Hi, >> >> the reason i need it is that a plugin generates code that depends on a >> framework in a specific configuration. And the knowledge witch >> combination of frameworks is needed, is provided by the generator (the >> plugin). I do not like to duplicate this knowledge in evey module that >> uses the plugin, this is why i would like the plugin (or some other >> mean) to include the dependencies in the ProjectModel. >> >> The IDE integration should be no problem because the included >> dependencies would (and must) be included in the ProjectModel and >> therefore are propagated to all running plugins as if they were in the >> pom directly. >> >> mfg >> Ritchie >> > Only if the plugin is executed. IDE (or other tools like Ivy for > instance) don't run the plugins to use the dependency informations. > > Also think to what you will publish to a repository. The projects > that depends on the project using the plugin will not execute your > plugin neither. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a way to extend the dependencies at build time
On 24/04/2008, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote: > Hi, > > the reason i need it is that a plugin generates code that depends on a > framework in a specific configuration. And the knowledge witch > combination of frameworks is needed, is provided by the generator (the > plugin). I do not like to duplicate this knowledge in evey module that > uses the plugin, this is why i would like the plugin (or some other > mean) to include the dependencies in the ProjectModel. > > The IDE integration should be no problem because the included > dependencies would (and must) be included in the ProjectModel and > therefore are propagated to all running plugins as if they were in the > pom directly. > > mfg > Ritchie > Only if the plugin is executed. IDE (or other tools like Ivy for instance) don't run the plugins to use the dependency informations. Also think to what you will publish to a repository. The projects that depends on the project using the plugin will not execute your plugin neither. -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a way to extend the dependencies at build time
oh well. you assume the IDE integration is and shall be running the build. I try to avoid that for performance reasons in netbeans integration. Milos On Thu, Apr 24, 2008 at 12:24 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote: > Hi, > > the reason i need it is that a plugin generates code that depends on a > framework in a specific configuration. And the knowledge witch > combination of frameworks is needed, is provided by the generator (the > plugin). I do not like to duplicate this knowledge in evey module that > uses the plugin, this is why i would like the plugin (or some other > mean) to include the dependencies in the ProjectModel. > > The IDE integration should be no problem because the included > dependencies would (and must) be included in the ProjectModel and > therefore are propagated to all running plugins as if they were in the > pom directly. > > mfg > Ritchie > > > > Milos Kleint wrote: > > I discourage any dynamic tweaking of the project. Among other things > > is breaks IDE integration. appfuse' warpath plugin does this sort of > > thing somehow. I would say it's a hack however and might not work in > > future versions.. > > > > Milos > > > > On Thu, Apr 24, 2008 at 9:33 AM, Richard van Nieuwenhoven <[EMAIL > PROTECTED]> wrote: > >> Hi, > >> > >> i have a strange requirement, i need a possibility to extend the > >> dependencies of a MavenProject in a plugin or component during build > >> time. I tried adding dependencies in a validation phase plugin, with no > >> success. > >> > >> Is there a "official" way to do this? Maybe a dynamic profile? Defaults > >> injector? > >> > >> (The built stability is guarantied because the plugin or component will > >> produce alway the same dependencies for a project configuration). > >> > >> thanks for any ideas! > >> Ritchie > >> > >> - > >> 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] > > > > > > > - > 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: a way to extend the dependencies at build time
Hi, the reason i need it is that a plugin generates code that depends on a framework in a specific configuration. And the knowledge witch combination of frameworks is needed, is provided by the generator (the plugin). I do not like to duplicate this knowledge in evey module that uses the plugin, this is why i would like the plugin (or some other mean) to include the dependencies in the ProjectModel. The IDE integration should be no problem because the included dependencies would (and must) be included in the ProjectModel and therefore are propagated to all running plugins as if they were in the pom directly. mfg Ritchie Milos Kleint wrote: > I discourage any dynamic tweaking of the project. Among other things > is breaks IDE integration. appfuse' warpath plugin does this sort of > thing somehow. I would say it's a hack however and might not work in > future versions.. > > Milos > > On Thu, Apr 24, 2008 at 9:33 AM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> > wrote: >> Hi, >> >> i have a strange requirement, i need a possibility to extend the >> dependencies of a MavenProject in a plugin or component during build >> time. I tried adding dependencies in a validation phase plugin, with no >> success. >> >> Is there a "official" way to do this? Maybe a dynamic profile? Defaults >> injector? >> >> (The built stability is guarantied because the plugin or component will >> produce alway the same dependencies for a project configuration). >> >> thanks for any ideas! >> Ritchie >> >> - >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: a way to extend the dependencies at build time
I discourage any dynamic tweaking of the project. Among other things is breaks IDE integration. appfuse' warpath plugin does this sort of thing somehow. I would say it's a hack however and might not work in future versions.. Milos On Thu, Apr 24, 2008 at 9:33 AM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote: > Hi, > > i have a strange requirement, i need a possibility to extend the > dependencies of a MavenProject in a plugin or component during build > time. I tried adding dependencies in a validation phase plugin, with no > success. > > Is there a "official" way to do this? Maybe a dynamic profile? Defaults > injector? > > (The built stability is guarantied because the plugin or component will > produce alway the same dependencies for a project configuration). > > thanks for any ideas! > Ritchie > > - > 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]
a way to extend the dependencies at build time
Hi, i have a strange requirement, i need a possibility to extend the dependencies of a MavenProject in a plugin or component during build time. I tried adding dependencies in a validation phase plugin, with no success. Is there a "official" way to do this? Maybe a dynamic profile? Defaults injector? (The built stability is guarantied because the plugin or component will produce alway the same dependencies for a project configuration). thanks for any ideas! Ritchie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
