Issues for 1.1.1
Hi folks, I reduced the number of issues for 1.1.1 (scheduled in September). If someone wants specific issues, please ask! Here is the actual release note: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14522styleName=TextprojectId=10527Create=Create BTW SCM-406 seems to be a none issue. Cheers, Vincent
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
I also would prefer allowSnapshots to be set to false by default, to match the release plugin allowSnapshots parameter and the enforcer plugin default rules Nicolas 2008/9/3 Stephen Connolly [EMAIL PROTECTED] On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: Stephen Connolly wrote: On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Stephen Great work on this plugin! This is a plugin that I plan to use extensively. I've read through the docs, which there are plenty of. Always a good sign :-) There were however a couple of typos and broken links in there, which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. Thanks, I forgot I had to switch back to mojo-parent 18 After playing around with the plugin a bit I found the results somewhat confusing, so I started to read the goal parameter docs. There I found the source of my confusion: the allowSnapshots parameter has true as default value. In my opinion this should be set to false as default. Using snapshots is something that should be avoided, if possible. Showing snapshot versions by default therefor works against best practices and might lure users to the dark side. I'm 50:50 on this. I use it to switch all the suit of projects onto SNAPSHOT versions while I'm working on them. When doing a release the release will be the newest version in the repo so puching back to SCM is fine in that case. However I can see the other side. There are apparently different use cases for this goal. Here's my use case. One step in our release process is to check to see if there are any dependencies that should be updated. When doing that I don't want any snapshots, because the release is near. just add -DallowSnapshots=false I'd like to move the includeProperties, excludeProperties and linkItems parameters from the Abstract Mojo to UpdatePropertiesMojo, because they are only used there. Also the parentVersion parameter should be moved to UpdateParentMojo. Having them in the Abstract Mojo makes them show up as parameters in the auto generated docs for every Mojo, see [1]. Fire ahead, when I moved them there I did not have the display goals. I will. The comparisonMethod parameter is currently only used in DisplayDependencyUpdatesMojo. Shouldn't it be used in DisplayPluginUpdatesMojo as well? OK, here is my logic: Maven plugins _should_ be versioned using the Maven version rules, i.e. Major.Minor.Update-Build Dependencies will be versioned using company rules (in our case 5 digits) So you don't need the comparison method for plugins. What do you think? What about plugins developed internally by companies, that are versioned using the company rules? If not, it can be moved from the Abstract Mojo to DisplayDependencyUpdatesMojo. Go ahead Finally the auto generated docs would benefit from using default-value in the @parameter annotations. This automatically inserts the default values into the docs. If you don't mind doing that please OK If you want me to, I can have a go at making these changes. Please do [1] http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html Stephen Connolly wrote: Folks, I've been working on the versions-maven-plugin and I think it's ready to cut the first alpha release. The major changes in this release are - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) Known issues - MOJO-1210 display-plugin-updates does not include lifecycle plugins that are not defined in the pom - MOJO-1211 display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Both of these issues will require a bit of work and I'd rather get an alpha release out before trying to fix them. The new site has just been deployed here: http://mojo.codehaus.org/versions-maven-plugin Snapshot have been published on http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin [+1] release it [0] don't care [-1] don't release ! Vote will be open for 72 hours and will conclude via lazy consensus. Please vote :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] -- Dennis Lundberg - To
Re: [VOTE] release versions-maven-plugin 1.0-alpha-1
OK, that (other plugins using it as the default) is a valid case, I have changed the default to false On Wed, Sep 3, 2008 at 8:31 AM, nicolas de loof [EMAIL PROTECTED] wrote: I also would prefer allowSnapshots to be set to false by default, to match the release plugin allowSnapshots parameter and the enforcer plugin default rules Nicolas 2008/9/3 Stephen Connolly [EMAIL PROTECTED] On Tue, Sep 2, 2008 at 11:08 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: Stephen Connolly wrote: On Tue, Sep 2, 2008 at 9:40 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: Hi Stephen Great work on this plugin! This is a plugin that I plan to use extensively. I've read through the docs, which there are plenty of. Always a good sign :-) There were however a couple of typos and broken links in there, which I took the liberty of fixing in SVN. I also updated to mojo-parent 18. Thanks, I forgot I had to switch back to mojo-parent 18 After playing around with the plugin a bit I found the results somewhat confusing, so I started to read the goal parameter docs. There I found the source of my confusion: the allowSnapshots parameter has true as default value. In my opinion this should be set to false as default. Using snapshots is something that should be avoided, if possible. Showing snapshot versions by default therefor works against best practices and might lure users to the dark side. I'm 50:50 on this. I use it to switch all the suit of projects onto SNAPSHOT versions while I'm working on them. When doing a release the release will be the newest version in the repo so puching back to SCM is fine in that case. However I can see the other side. There are apparently different use cases for this goal. Here's my use case. One step in our release process is to check to see if there are any dependencies that should be updated. When doing that I don't want any snapshots, because the release is near. just add -DallowSnapshots=false I'd like to move the includeProperties, excludeProperties and linkItems parameters from the Abstract Mojo to UpdatePropertiesMojo, because they are only used there. Also the parentVersion parameter should be moved to UpdateParentMojo. Having them in the Abstract Mojo makes them show up as parameters in the auto generated docs for every Mojo, see [1]. Fire ahead, when I moved them there I did not have the display goals. I will. The comparisonMethod parameter is currently only used in DisplayDependencyUpdatesMojo. Shouldn't it be used in DisplayPluginUpdatesMojo as well? OK, here is my logic: Maven plugins _should_ be versioned using the Maven version rules, i.e. Major.Minor.Update-Build Dependencies will be versioned using company rules (in our case 5 digits) So you don't need the comparison method for plugins. What do you think? What about plugins developed internally by companies, that are versioned using the company rules? If not, it can be moved from the Abstract Mojo to DisplayDependencyUpdatesMojo. Go ahead Finally the auto generated docs would benefit from using default-value in the @parameter annotations. This automatically inserts the default values into the docs. If you don't mind doing that please OK If you want me to, I can have a go at making these changes. Please do [1] http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html Stephen Connolly wrote: Folks, I've been working on the versions-maven-plugin and I think it's ready to cut the first alpha release. The major changes in this release are - Fixed MOJO-1209 (required a rewrite of the display-plugin-updates goal) Known issues - MOJO-1210 display-plugin-updates does not include lifecycle plugins that are not defined in the pom - MOJO-1211 display-plugin-updates does not identify the plugin version as not being provided when derived from the super-pom Both of these issues will require a bit of work and I'd rather get an alpha release out before trying to fix them. The new site has just been deployed here: http://mojo.codehaus.org/versions-maven-plugin Snapshot have been published on http://snapshots.repository.codehaus.org/org/codehaus/mojo/versions-maven-plugin [+1] release it [0] don't care [-1] don't release ! Vote will be open for 72 hours and will conclude via lazy consensus. Please vote :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL
Question: How to get the original model before the super-pom's pluginManagement is injected?
If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlugins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-jar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-javadoc-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-plugin-plugin/artifactId version2.4.1/version /plugin plugin artifactIdmaven-rar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version /plugin plugin artifactIdmaven-resources-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-site-plugin/artifactId version2.0-beta-6/version /plugin plugin artifactIdmaven-source-plugin/artifactId version2.0.4/version /plugin plugin artifactIdmaven-surefire-plugin/artifactId version2.4.2/version /plugin plugin artifactIdmaven-war-plugin/artifactId version2.1-alpha-1/version /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project *oh look the super pom has been injected in before I can see it* I have not checked, but I suspect that maven-enforcer-plugin will have the same issue with Maven 2.0.9+ (given that I've pilfered a lot of the logic for missing versions from there) I really don't want to have to write my own ModelXpp3Reader, or have to bury in plugin code logic to find the pom.xml and read it in
Marking 2.0.10 issues also 2.1.x and 3.0
Are there any objections to marking the 2.0.10 issues also for 2.1 and 3.0? I can do a batch update with no email notice. Let me know. I am in no hurry to make the change. If I see no objections by the weekend, I'll do it to keep good issue tracking. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question: How to get the original model before the super-pom's pluginManagement is injected?
You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-jar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-javadoc-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-plugin-plugin/artifactId version2.4.1/version /plugin plugin artifactIdmaven-rar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version /plugin plugin artifactIdmaven-resources-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-site-plugin/artifactId version2.0-beta-6/version /plugin plugin artifactIdmaven-source-plugin/artifactId version2.0.4/version /plugin plugin artifactIdmaven-surefire-plugin/artifactId version2.4.2/version /plugin plugin artifactIdmaven-war-plugin/artifactId version2.1-alpha-1/version /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin artifactIdmaven-clean-plugin/artifactId version2.1/version
Re: Marking 2.0.10 issues also 2.1.x and 3.0
On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict [EMAIL PROTECTED] wrote: Are there any objections to marking the 2.0.10 issues also for 2.1 and 3.0? I can do a batch update with no email notice. Let me know. I am in no hurry to make the change. If I see no objections by the weekend, I'll do it to keep good issue tracking. Isn't it implied that anything fixed in a prior version _stays_ fixed in a later one? I don't think I want to see everything from 2.0.10 show up again in the release notes for 2.1 and 3.0, I only want to see what's new. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
I've read MNG-624, and quite a bit of the code, and I feel like I understand the algorithm relatively well. What I'm having trouble understanding is why it needs to be so complex and look for versions in so many places (like resolving system properties in the parent section, etc.). IMO we need to be very careful with things like cli arguments here, since it could have a huge impact on build reproducibility. Ralph Goers wrote: John, that's not a problem. I'll be happy to put something up on the wiki in the next day or two. The code was actually much simpler in the beginning, but as usual when I started testing things got a little more complicated. For reference, if you haven't read MNG-624 and its many cousins you should take a look at them. Ralph John Casey wrote: Hi Ralph, As with all of the feature branch work we've done recently (in the last year or two), it would be extremely helpful if we could get a write-up in the form of a proposal out on the wiki. Most importantly, to try and address the specific use cases this design is intended to address, and how. Also, within what assumptions the code is designed to work, so we might talk about how it could/should fall apart when the user violates one of those assumptions. I'm looking through the code right now, but from my own experience with Maven, it's simply not enough going forward to keep throwing test cases at the code and hope we haven't missed anything. I'd like to have a basis for writing up the new feature on the public website, to explain it to users...this will help me understand it better, too. I know we're somewhat in the early stages of development for this stuff - assuming we're going to enter a stabilizing mode in the next few weeks for what should become a GA release if everything follows its current trajectory - but personally I'm not comfortable marking this feature for inclusion in that release until I know more about it. I'm in the middle of reading the code, but IMO we really need some design documentation laying out clearly the need for the feature, and the reasoning behind the apparent complexity of your implementation, etc. IMO we need to have these sorts of discussions before we decide to include any new feature in a release. I'm working on reviewing the full list I've suggested in the original email on this thread, so I'm sure this won't be the last request like this to the list... Thanks, -john Ralph Goers wrote: I am OK with this. You may or may not have noticed but I created branch maven-2.1.x-MNG-624 last night. It contains the fix for MNG-624. I have created integration tests but haven't committed them yet. I will soon. Before committing these to the 2.1.x branch I'd really like folks to try it out. This change will have a minor impact on existing projects. If you don't specify the artifact's groupId or versionId (i.e. it is inherited from the parent) then a new pom.xml should get created in the target directory that has those fields filled in. That file will be the one that is installed or deployed. I'm only trying to resolve the parent version. I could try to resolve the parent groupId and artifactId and some of the problem reports mention those but I just couldn't think of a reason why they shouldn't be specified or why someone would want them in a variable. The version is obtained by 1. Resolving any variables provided via system properties (variables from parents won't be found since the parent isn't known. 2. Looking in the file cache for the resolved parent project using the relative location as the key. 3. Looking for the parent at the relative path on disk. a. The target directory at the relative path is inspected for a modified pom. b. The project at the relative path is used. If at the end of this a resolved parent version is not located throw an Exception. Do not try to recurse to further parents. You'll notice the comment about looking for the modified pom in the target directory. As part of this fix the parent version, and the project's artifactId, groupId and version are all interpolated. If any of those fields were missing or had variables in them in the original pom then the pom is modified and written to the target directory. Thus, any pom that is installed or deployed will always have these fields resolved. In looking through the plugins it looked to me that the Eclipse and Invoker plugins are trying to locate the base directory by calling project.getFile().getParentFile(). These will need to be changed to project.getBasedir() since the location of the pom might now be in a different place and project.getFile().getParentFile() might return the target directory instead of the base directory. As we agreed Maven 2.1 will require Java 5. The pom has been changed to reflect that and quite a bit of the new code uses it. Please test and provide feedback. Ralph John Casey wrote: Hi everyone, So, it seems that we're all
Re: Marking 2.0.10 issues also 2.1.x and 3.0
+1 Wendy Smoak wrote: On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict [EMAIL PROTECTED] wrote: Are there any objections to marking the 2.0.10 issues also for 2.1 and 3.0? I can do a batch update with no email notice. Let me know. I am in no hurry to make the change. If I see no objections by the weekend, I'll do it to keep good issue tracking. Isn't it implied that anything fixed in a prior version _stays_ fixed in a later one? I don't think I want to see everything from 2.0.10 show up again in the release notes for 2.1 and 3.0, I only want to see what's new. -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
IMO, the change in version scheme could be a very positive thing, as it emphasizes introducing a feature at a time instead of pushing them all in and claiming that everything is mostly working with some bugs. I think this may help us manage the chaos that comes from introducing these sorts of things. Also, IMO it's going to be a hard sell getting people to go 2.0.9 - 2.1.0 when there is no compelling reason for the change in minor version number. Sure, there are stability and performance improvements, but it's all guts to users, and I'm guessing more than one will wonder at what cost the performance improvements come. Remember, this isn't the first time we've done a release on the basis of stability improvement; IMO we have a little bit of a credibility deficit there. :-) -john Dennis Lundberg wrote: My personal preference is #2 The reasoning behind this is that we'd be introducing yet another versioning scheme into the mix that we already have. This might be confusing to our users and as John hinted at might not attract as many users. John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
So, I've started tracking the features I proposed for 2.1.0 GA here: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan I don't know if this is the final list; IMO we'll need to agree on that once we have design documentation for everything. I'm going to contact Don Brown today and ask whether he can do a little write-up for parallel resolution soonish, and I need to track down the build dynamism write-up I put on Confluence (not to mention the relevant JIRAs for these implementation changes). Ralph, once you have some design docs for the automatic parent versioning, we'll add that in as well. Please have a look, and give feedback! Thanks. -john John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: How to get the original model before the super-pom's pluginManagement is injected?
Grrr argh! Ok, hmm I'll have a closer look at your code as you did not seem to be parsing the XML from my initial reading of the code On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED]wrote: You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-jar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-javadoc-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-plugin-plugin/artifactId version2.4.1/version /plugin plugin artifactIdmaven-rar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version /plugin plugin artifactIdmaven-resources-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-site-plugin/artifactId version2.0-beta-6/version /plugin plugin artifactIdmaven-source-plugin/artifactId version2.0.4/version /plugin plugin artifactIdmaven-surefire-plugin/artifactId version2.4.2/version /plugin plugin artifactIdmaven-war-plugin/artifactId version2.1-alpha-1/version /plugin
Re: Question: How to get the original model before the super-pom's pluginManagement is injected?
FWIW, the reimplemented cloneModel(..) method (which in part causes this problem, because it clones too shallowly) should keep the originalModel instance from being polluted with resolved plugin information. I *think* the integration test for MNG-3710 should cover this case, but I can't remember for sure. If not, we need a test case that we can use to fix it. Stephen Connolly wrote: Grrr argh! Ok, hmm I'll have a closer look at your code as you did not seem to be parsing the XML from my initial reading of the code On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED]wrote: You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-jar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-javadoc-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-plugin-plugin/artifactId version2.4.1/version /plugin plugin artifactIdmaven-rar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version /plugin plugin artifactIdmaven-resources-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-site-plugin/artifactId version2.0-beta-6/version /plugin plugin artifactIdmaven-source-plugin/artifactId version2.0.4/version
Re: Question: How to get the original model before the super-pom's pluginManagement is injected?
That's in the stuff I've been putting out in RCs, to be clear... John Casey wrote: FWIW, the reimplemented cloneModel(..) method (which in part causes this problem, because it clones too shallowly) should keep the originalModel instance from being polluted with resolved plugin information. I *think* the integration test for MNG-3710 should cover this case, but I can't remember for sure. If not, we need a test case that we can use to fix it. Stephen Connolly wrote: Grrr argh! Ok, hmm I'll have a closer look at your code as you did not seem to be parsing the XML from my initial reading of the code On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED]wrote: You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-jar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-javadoc-plugin/artifactId version2.4/version /plugin plugin artifactIdmaven-plugin-plugin/artifactId version2.4.1/version /plugin plugin artifactIdmaven-rar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-release-plugin/artifactId version2.0-beta-7/version /plugin plugin artifactIdmaven-resources-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-site-plugin/artifactId version2.0-beta-6/version /plugin
RE: Question: How to get the original model before the super-pom's pluginManagement is injected?
I thought it needed a full deep copy to preserve the model and we decided to back away from that in this release? I remember discussing it, but not the exact outcome. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 1:20 PM To: Maven Developers List Subject: Re: Question: How to get the original model before the super-pom's pluginManagement is injected? That's in the stuff I've been putting out in RCs, to be clear... John Casey wrote: FWIW, the reimplemented cloneModel(..) method (which in part causes this problem, because it clones too shallowly) should keep the originalModel instance from being polluted with resolved plugin information. I *think* the integration test for MNG-3710 should cover this case, but I can't remember for sure. If not, we need a test case that we can use to fix it. Stephen Connolly wrote: Grrr argh! Ok, hmm I'll have a closer look at your code as you did not seem to be parsing the XML from my initial reading of the code On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED]wrote: You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-jar-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-javadoc-plugin/artifactId version2.4/version
Re: [vote] Version for pending release
As others have said before, since you John are the one doing most of the work on this I trust your judgement in choosing the best option. John Casey wrote: IMO, the change in version scheme could be a very positive thing, as it emphasizes introducing a feature at a time instead of pushing them all in and claiming that everything is mostly working with some bugs. I think this may help us manage the chaos that comes from introducing these sorts of things. Also, IMO it's going to be a hard sell getting people to go 2.0.9 - 2.1.0 when there is no compelling reason for the change in minor version number. Sure, there are stability and performance improvements, but it's all guts to users, and I'm guessing more than one will wonder at what cost the performance improvements come. Remember, this isn't the first time we've done a release on the basis of stability improvement; IMO we have a little bit of a credibility deficit there. :-) -john Dennis Lundberg wrote: My personal preference is #2 The reasoning behind this is that we'd be introducing yet another versioning scheme into the mix that we already have. This might be confusing to our users and as John hinted at might not attract as many users. John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -john -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question: How to get the original model before the super-pom's pluginManagement is injected?
I wound up putting it in since the clone methods were a performance problem, and the solution was to do direct object construction and avoid all the tangled logic inside the inheritance assembler. Now that we're [potentially] transitioning from concrete to dynamic and back in the build section of the POM, these clone methods have become quite a bit more prominent (they're called a lot more often). Brian E. Fox wrote: I thought it needed a full deep copy to preserve the model and we decided to back away from that in this release? I remember discussing it, but not the exact outcome. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 1:20 PM To: Maven Developers List Subject: Re: Question: How to get the original model before the super-pom's pluginManagement is injected? That's in the stuff I've been putting out in RCs, to be clear... John Casey wrote: FWIW, the reimplemented cloneModel(..) method (which in part causes this problem, because it clones too shallowly) should keep the originalModel instance from being polluted with resolved plugin information. I *think* the integration test for MNG-3710 should cover this case, but I can't remember for sure. If not, we need a test case that we can use to fix it. Stephen Connolly wrote: Grrr argh! Ok, hmm I'll have a closer look at your code as you did not seem to be parsing the XML from my initial reading of the code On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED]wrote: You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject.getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject.getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version /plugin plugin artifactIdmaven-ejb-plugin/artifactId version2.1/version /plugin plugin artifactIdmaven-install-plugin/artifactId
[RESULT] [vote] Version for pending release
The result was: #1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K. 2 non-binding: Ralph, Raphael #2: 2 binding: Brian, Dennis 2 non-binding: Mauro, Stephen If you're following the other thread (Maven 2.1.0 GA Plan) you'll see that I've started to formalize the suggestions I made for features to be included in 2.1.0 in Confluence. This is by no means set in stone; in fact, for two of the features, we're still waiting on design documentation before I'm comfortable committing to them. I'd like to know if anyone would like to put a different issue on the plan, and/or maybe talk about bumping one or more of these features to 2.2...in short, I was hoping to solicit some discussion about what we're going to be building for 2.1.0. Thanks, -john John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] 2.1.0-M1-RC12 of Maven (was: Maven 2.0.10-RC*)
Okay, I'm able to reproduce it here, and hopefully I'll have it debugged and fixed (with test case) tonight. -john Arnaud HERITIER wrote: John, I tried to use RC12 to build all our plugins (on win XP). E:\Dev\oss\maven-plugins-trunkmvn -version Maven version: 2.1.0-M1-RC12 Java version: 1.5.0_14 Default locale: en_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 family: windows It fails with : E:\Dev\oss\maven-plugins-trunkmvn clean install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Maven Plugins [INFO] Maven Remote Resources Plugin [INFO] Maven Ant Plugin [INFO] Maven AntRun Plugin [INFO] Maven Assembly Plugin [INFO] Maven Changelog Plugin [INFO] Maven Changes Report Plugin [INFO] Maven Checkstyle Plugin [INFO] Maven Clean Plugin [INFO] Maven Compiler Plugin [INFO] Maven Dependency Plugin [INFO] Maven Deploy Plugin [INFO] Maven DOAP Plugin [INFO] Maven Documentation Checker Plugin [INFO] Maven EAR Plugin [INFO] Maven Eclipse Plugin [INFO] Maven EJB Plugin [INFO] Maven GPG Plugin [INFO] Maven Help Plugin [INFO] Maven IDEA Plugin [INFO] Maven Install Plugin [INFO] Maven Invoker Plugin [INFO] Maven Javadoc Plugin [INFO] Maven JAR Plugin [INFO] Maven Linkcheck Plugin [INFO] Maven One Plugin [INFO] Maven Patch Plugin [INFO] Maven PMD Plugin [INFO] Maven RAR Plugin [INFO] Maven Repository Plugin [INFO] Maven Resources Plugin [INFO] Maven Shade Plugin [INFO] Maven Site Plugin [INFO] Maven Source Plugin [INFO] Maven Stage Plugin [INFO] Maven Toolchains Plugin [INFO] Maven Verifier Plugin [INFO] Maven WAR Plugin [INFO] [INFO] Building Maven Plugins [INFO]task-segment: [clean, install] [INFO] [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.StackOverflowError at org.apache.maven.project.DefaultMavenProjectBuilder.projectWasChanged(DefaultMavenProjectBuilder.java:2033) at org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicStateInternal(DefaultMavenProjectBuilder.java:2006) at org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicState(DefaultMavenProjectBuilder.java:1994) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1836) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918) ... at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918) [INFO] [INFO] Total time: 22 seconds [INFO] Finished at: Tue Sep 02 13:53:56 CEST 2008 [INFO] Final Memory: 6M/254M [INFO] Can you reproduce it ? Arnaud On Fri, Aug 29, 2008 at 8:03 PM, John Casey [EMAIL PROTECTED] wrote: Hi everyone, Sorry if the subject of this message is a little confusing, but we're in the process of relabeling the code in this release candidate to be part of a new version, a departure from the 2.0.x codebase. This release candidate contains some large modifications, even though it's meant to be backward compatible, and the risk that entails makes the relabeling appropriate. In any case, I'm anticipating one of a set of possible results from this
Re: Maven 2.1.0 GA Plan
I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
That sounds fine to me. John Casey wrote: I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] 2.1.0-M1-RC12 of Maven (was: Maven 2.0.10-RC*)
ok thanks a lot for your work !!! cheers arnaud On Wed, Sep 3, 2008 at 8:26 PM, John Casey [EMAIL PROTECTED] wrote: Okay, I'm able to reproduce it here, and hopefully I'll have it debugged and fixed (with test case) tonight. -john Arnaud HERITIER wrote: John, I tried to use RC12 to build all our plugins (on win XP). E:\Dev\oss\maven-plugins-trunkmvn -version Maven version: 2.1.0-M1-RC12 Java version: 1.5.0_14 Default locale: en_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 family: windows It fails with : E:\Dev\oss\maven-plugins-trunkmvn clean install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Maven Plugins [INFO] Maven Remote Resources Plugin [INFO] Maven Ant Plugin [INFO] Maven AntRun Plugin [INFO] Maven Assembly Plugin [INFO] Maven Changelog Plugin [INFO] Maven Changes Report Plugin [INFO] Maven Checkstyle Plugin [INFO] Maven Clean Plugin [INFO] Maven Compiler Plugin [INFO] Maven Dependency Plugin [INFO] Maven Deploy Plugin [INFO] Maven DOAP Plugin [INFO] Maven Documentation Checker Plugin [INFO] Maven EAR Plugin [INFO] Maven Eclipse Plugin [INFO] Maven EJB Plugin [INFO] Maven GPG Plugin [INFO] Maven Help Plugin [INFO] Maven IDEA Plugin [INFO] Maven Install Plugin [INFO] Maven Invoker Plugin [INFO] Maven Javadoc Plugin [INFO] Maven JAR Plugin [INFO] Maven Linkcheck Plugin [INFO] Maven One Plugin [INFO] Maven Patch Plugin [INFO] Maven PMD Plugin [INFO] Maven RAR Plugin [INFO] Maven Repository Plugin [INFO] Maven Resources Plugin [INFO] Maven Shade Plugin [INFO] Maven Site Plugin [INFO] Maven Source Plugin [INFO] Maven Stage Plugin [INFO] Maven Toolchains Plugin [INFO] Maven Verifier Plugin [INFO] Maven WAR Plugin [INFO] [INFO] Building Maven Plugins [INFO]task-segment: [clean, install] [INFO] [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.StackOverflowError at org.apache.maven.project.DefaultMavenProjectBuilder.projectWasChanged(DefaultMavenProjectBuilder.java:2033) at org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicStateInternal(DefaultMavenProjectBuilder.java:2006) at org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicState(DefaultMavenProjectBuilder.java:1994) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1836) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918) ... at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918) [INFO] [INFO] Total time: 22 seconds [INFO] Finished at: Tue Sep 02 13:53:56 CEST 2008 [INFO] Final Memory: 6M/254M [INFO] Can you reproduce it ? Arnaud On Fri, Aug 29, 2008 at 8:03 PM, John Casey [EMAIL PROTECTED] wrote: Hi everyone, Sorry if the subject of this message is a little confusing, but we're in the process of relabeling the code in this release candidate to be part of a new version, a departure from the 2.0.x codebase. This
Re: Question: How to get the original model before the super-pom's pluginManagement is injected?
ok, so the end result is that if I want my plugin to work with 2.0.6+ I need to parse the pom by hand in order to determine what is in the pluginManagement section and which bits are missing a version specification? Sent from my iPod On 3 Sep 2008, at 19:18, John Casey [EMAIL PROTECTED] wrote: I wound up putting it in since the clone methods were a performance problem, and the solution was to do direct object construction and avoid all the tangled logic inside the inheritance assembler. Now that we're [potentially] transitioning from concrete to dynamic and back in the build section of the POM, these clone methods have become quite a bit more prominent (they're called a lot more often). Brian E. Fox wrote: I thought it needed a full deep copy to preserve the model and we decided to back away from that in this release? I remember discussing it, but not the exact outcome. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 1:20 PM To: Maven Developers List Subject: Re: Question: How to get the original model before the super-pom's pluginManagement is injected? That's in the stuff I've been putting out in RCs, to be clear... John Casey wrote: FWIW, the reimplemented cloneModel(..) method (which in part causes this problem, because it clones too shallowly) should keep the originalModel instance from being polluted with resolved plugin information. I *think* the integration test for MNG-3710 should cover this case, but I can't remember for sure. If not, we need a test case that we can use to fix it. Stephen Connolly wrote: Grrr argh! Ok, hmm I'll have a closer look at your code as you did not seem to be parsing the XML from my initial reading of the code On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED] wrote: You can't, this is why in the enforcer rule, I have to walk and interpolate the entire tree. If I could get the model from maven unmolested, I could cut out 99% of that code. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 6:31 AM To: Maven Developers List Subject: Question: How to get the original model before the super-pom's pluginManagement is injected? If I have the floowing pom.xml: project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId version2.0/version packagingpom/packaging build pluginManagement plugins plugin artifactIdmaven-checkstyle-plugin/artifactId version2.1/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.4/source target1.4/target /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId /plugin /plugins /pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version2.1/version /plugin /plugins /build /project How do I detect in a mojo that the pluginManagement section has a entry for maven-compiler-plugin that *does not have the version specified*... If I look at mavenProject.getPluginManagement().getPlugins() I'll see maven-compiler-plugin but with version set to 2.0.2 (from the super pom) If I look at mavenProject. getModel().getBuild().getPluginManagement().getPlugins(), same thing (*But this should be ok as it's the interpolated model anyway*) If I look at mavenProject. getOriginalModel().getBuild().getPluginManagement().getPlug ins(), same thing *isn't this supposed to be the original model... before interpolation* Just to check I'm not going mad I logged the output of mavenProject.writeOriginalModel which gives: ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdorg.codehaus.mojo.versions-maven-plugin.it/groupId artifactIdparent/artifactId packagingpom/packaging version2.0/version build pluginManagement plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.1/version /plugin plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-2/version /plugin plugin artifactIdmaven-clean-plugin/artifactId version2.2/version /plugin plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.4/source target1.4/target /configuration /plugin plugin artifactIdmaven-dependency-plugin/artifactId version2.0/version /plugin plugin artifactIdmaven-deploy-plugin/artifactId version2.3/version /plugin plugin
Re: [RESULT] [vote] Version for pending release
afaik, I did not vote for any option (just a time bounded vote) ;-) Sent from my iPod On 3 Sep 2008, at 19:22, John Casey [EMAIL PROTECTED] wrote: The result was: #1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K. 2 non-binding: Ralph, Raphael #2: 2 binding: Brian, Dennis 2 non-binding: Mauro, Stephen If you're following the other thread (Maven 2.1.0 GA Plan) you'll see that I've started to formalize the suggestions I made for features to be included in 2.1.0 in Confluence. This is by no means set in stone; in fact, for two of the features, we're still waiting on design documentation before I'm comfortable committing to them. I'd like to know if anyone would like to put a different issue on the plan, and/or maybe talk about bumping one or more of these features to 2.2...in short, I was hoping to solicit some discussion about what we're going to be building for 2.1.0. Thanks, -john John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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: Maven 2.1.0 GA Plan
The only thing I feel we need to start looking at soon is an xml parser that can deal with newer models and not freak. This is probably related in some way to the refactoring happening in 3.0... but I know that 2.0.x can't handle newer models and the sooner we start moving to a more flexible parser, the easier the eventual migration to 3.0 will be. I'm not sure this needs to be in 2.1, but maybe on the list for 2.2. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 2:31 PM To: Maven Developers List Subject: Re: Maven 2.1.0 GA Plan I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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: Maven 2.1.0 GA Plan
Let's start another page for 2.2 features, since this one is in the pre-planning stages still. Until we have a concrete strategy for implementation including a design doc, I don't feel comfortable putting it on such a near time horizon. WDYT? Brian E. Fox wrote: The only thing I feel we need to start looking at soon is an xml parser that can deal with newer models and not freak. This is probably related in some way to the refactoring happening in 3.0... but I know that 2.0.x can't handle newer models and the sooner we start moving to a more flexible parser, the easier the eventual migration to 3.0 will be. I'm not sure this needs to be in 2.1, but maybe on the list for 2.2. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 2:31 PM To: Maven Developers List Subject: Re: Maven 2.1.0 GA Plan I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [vote] Version for pending release
Fair enough, I misunderstood. :) Stephen Connolly wrote: afaik, I did not vote for any option (just a time bounded vote) ;-) Sent from my iPod On 3 Sep 2008, at 19:22, John Casey [EMAIL PROTECTED] wrote: The result was: #1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K. 2 non-binding: Ralph, Raphael #2: 2 binding: Brian, Dennis 2 non-binding: Mauro, Stephen If you're following the other thread (Maven 2.1.0 GA Plan) you'll see that I've started to formalize the suggestions I made for features to be included in 2.1.0 in Confluence. This is by no means set in stone; in fact, for two of the features, we're still waiting on design documentation before I'm comfortable committing to them. I'd like to know if anyone would like to put a different issue on the plan, and/or maybe talk about bumping one or more of these features to 2.2...in short, I was hoping to solicit some discussion about what we're going to be building for 2.1.0. Thanks, -john John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] 2.1.0-M1-RC12 of Maven (was: Maven 2.0.10-RC*)
np. The issue is: MNG-3740. I have a fix and test case here, but I need to clean up some IT issues related to RC12's fixes before I spin a new RC. Arnaud HERITIER wrote: ok thanks a lot for your work !!! cheers arnaud On Wed, Sep 3, 2008 at 8:26 PM, John Casey [EMAIL PROTECTED] wrote: Okay, I'm able to reproduce it here, and hopefully I'll have it debugged and fixed (with test case) tonight. -john Arnaud HERITIER wrote: John, I tried to use RC12 to build all our plugins (on win XP). E:\Dev\oss\maven-plugins-trunkmvn -version Maven version: 2.1.0-M1-RC12 Java version: 1.5.0_14 Default locale: en_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 family: windows It fails with : E:\Dev\oss\maven-plugins-trunkmvn clean install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Maven Plugins [INFO] Maven Remote Resources Plugin [INFO] Maven Ant Plugin [INFO] Maven AntRun Plugin [INFO] Maven Assembly Plugin [INFO] Maven Changelog Plugin [INFO] Maven Changes Report Plugin [INFO] Maven Checkstyle Plugin [INFO] Maven Clean Plugin [INFO] Maven Compiler Plugin [INFO] Maven Dependency Plugin [INFO] Maven Deploy Plugin [INFO] Maven DOAP Plugin [INFO] Maven Documentation Checker Plugin [INFO] Maven EAR Plugin [INFO] Maven Eclipse Plugin [INFO] Maven EJB Plugin [INFO] Maven GPG Plugin [INFO] Maven Help Plugin [INFO] Maven IDEA Plugin [INFO] Maven Install Plugin [INFO] Maven Invoker Plugin [INFO] Maven Javadoc Plugin [INFO] Maven JAR Plugin [INFO] Maven Linkcheck Plugin [INFO] Maven One Plugin [INFO] Maven Patch Plugin [INFO] Maven PMD Plugin [INFO] Maven RAR Plugin [INFO] Maven Repository Plugin [INFO] Maven Resources Plugin [INFO] Maven Shade Plugin [INFO] Maven Site Plugin [INFO] Maven Source Plugin [INFO] Maven Stage Plugin [INFO] Maven Toolchains Plugin [INFO] Maven Verifier Plugin [INFO] Maven WAR Plugin [INFO] [INFO] Building Maven Plugins [INFO]task-segment: [clean, install] [INFO] [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.plugins:maven-enforcer-plugin:1.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from snapshots [INFO] snapshot org.apache.maven.enforcer:enforcer:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.StackOverflowError at org.apache.maven.project.DefaultMavenProjectBuilder.projectWasChanged(DefaultMavenProjectBuilder.java:2033) at org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicStateInternal(DefaultMavenProjectBuilder.java:2006) at org.apache.maven.project.DefaultMavenProjectBuilder.restoreDynamicState(DefaultMavenProjectBuilder.java:1994) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1836) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918) ... at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1842) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteProjectReferences(DefaultMavenProjectBuilder.java:1949) at org.apache.maven.project.DefaultMavenProjectBuilder.calculateConcreteStateInternal(DefaultMavenProjectBuilder.java:1918) [INFO] [INFO] Total time: 22 seconds [INFO] Finished at: Tue Sep 02 13:53:56 CEST 2008 [INFO] Final Memory: 6M/254M [INFO] Can you reproduce it ? Arnaud On Fri, Aug 29, 2008 at 8:03 PM, John Casey [EMAIL PROTECTED] wrote: Hi everyone, Sorry if the subject of this message is a little confusing, but we're in the process of relabeling the code in this release candidate to be part of a new
Re: Maven 2.1.0 GA Plan
Sounds good to me Sent from my iPhone On Sep 3, 2008, at 5:35 PM, John Casey [EMAIL PROTECTED] wrote: Let's start another page for 2.2 features, since this one is in the pre-planning stages still. Until we have a concrete strategy for implementation including a design doc, I don't feel comfortable putting it on such a near time horizon. WDYT? Brian E. Fox wrote: The only thing I feel we need to start looking at soon is an xml parser that can deal with newer models and not freak. This is probably related in some way to the refactoring happening in 3.0... but I know that 2.0.x can't handle newer models and the sooner we start moving to a more flexible parser, the easier the eventual migration to 3.0 will be. I'm not sure this needs to be in 2.1, but maybe on the list for 2.2. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 2:31 PM To: Maven Developers List Subject: Re: Maven 2.1.0 GA Plan I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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: Maven 2.1.0 GA Plan
http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan Brian Fox wrote: Sounds good to me Sent from my iPhone On Sep 3, 2008, at 5:35 PM, John Casey [EMAIL PROTECTED] wrote: Let's start another page for 2.2 features, since this one is in the pre-planning stages still. Until we have a concrete strategy for implementation including a design doc, I don't feel comfortable putting it on such a near time horizon. WDYT? Brian E. Fox wrote: The only thing I feel we need to start looking at soon is an xml parser that can deal with newer models and not freak. This is probably related in some way to the refactoring happening in 3.0... but I know that 2.0.x can't handle newer models and the sooner we start moving to a more flexible parser, the easier the eventual migration to 3.0 will be. I'm not sure this needs to be in 2.1, but maybe on the list for 2.2. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 2:31 PM To: Maven Developers List Subject: Re: Maven 2.1.0 GA Plan I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
I added a reference to the prototype I did earlier in the year for the attribute based POMs that did this using modello and stax. I also added simplified POM syntax to the milestones for this as a placeholder. - Brett On 04/09/2008, at 8:14 AM, John Casey wrote: http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan Brian Fox wrote: Sounds good to me Sent from my iPhone On Sep 3, 2008, at 5:35 PM, John Casey [EMAIL PROTECTED] wrote: Let's start another page for 2.2 features, since this one is in the pre-planning stages still. Until we have a concrete strategy for implementation including a design doc, I don't feel comfortable putting it on such a near time horizon. WDYT? Brian E. Fox wrote: The only thing I feel we need to start looking at soon is an xml parser that can deal with newer models and not freak. This is probably related in some way to the refactoring happening in 3.0... but I know that 2.0.x can't handle newer models and the sooner we start moving to a more flexible parser, the easier the eventual migration to 3.0 will be. I'm not sure this needs to be in 2.1, but maybe on the list for 2.2. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2008 2:31 PM To: Maven Developers List Subject: Re: Maven 2.1.0 GA Plan I've included this as M2 to give us a clean base in M1: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan Let me know what you think. Dennis Lundberg wrote: John Casey wrote: Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of nearly there features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. With a timeframe of 2 months I would like to see Doxia beta-1 included in the core. This is tracked in JIRA as http://jira.codehaus.org/browse/MNG-3602 In the discussions surrounding that issue it was determined there would not be enough exposure of Doxia beta-1 until the next release (at that time). But with the new timeframe for the 2.1 release we should be able to get good testing of Doxia beta-1. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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:
Re: Maven 2.1.0 GA Plan
On 04/09/2008, at 1:34 AM, John Casey wrote: So, I've started tracking the features I proposed for 2.1.0 GA here: http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan I don't know if this is the final list; IMO we'll need to agree on that once we have design documentation for everything. I'm going to contact Don Brown today and ask whether he can do a little write-up for parallel resolution soonish, and I need to track down the build dynamism write-up I put on Confluence (not to mention the relevant JIRAs for these implementation changes). Ralph, once you have some design docs for the automatic parent versioning, we'll add that in as well. Please have a look, and give feedback! Thanks. Looks good to me. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Marking 2.0.10 issues also 2.1.x and 3.0
Is the +1 to Paul or to Wendy? :) What I understand the current situation to be: * things fixed in both 2.0.10 and 2.1.0 are marked in both * these do not automatically apply to 3.0 since it's now to hard to merge a lot of them so it'll be brought to backwards compat via ITs * in the event something can be merged to 3.0 it will be marked with both. That seems fine to me. The release notes issue Wendy raised annoys me too, but we can workaround that, or strip them off later. If 2.1.0 is out before 2.0.10 it makes a lot of sense to include them in both release notes. John, as far as your concerned, JIRA is up to date in this regard now, right? Cheers, Brett On 04/09/2008, at 12:48 AM, John Casey wrote: +1 Wendy Smoak wrote: On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict [EMAIL PROTECTED] wrote: Are there any objections to marking the 2.0.10 issues also for 2.1 and 3.0? I can do a batch update with no email notice. Let me know. I am in no hurry to make the change. If I see no objections by the weekend, I'll do it to keep good issue tracking. Isn't it implied that anything fixed in a prior version _stays_ fixed in a later one? I don't think I want to see everything from 2.0.10 show up again in the release notes for 2.1 and 3.0, I only want to see what's new. -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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: Marking 2.0.10 issues also 2.1.x and 3.0
I think it's proper issue management to label all issues for their respective fixes. Otherwise, what are you going to do when you have issues just for one branch? Some issues are also just for trunk and not backported. I think we should have a rule: if you commit to multiple places, the issue should show the Fix Version for those places. I thought there was general agreement on this issue -- admittedly worded differently -- for 2.0.9? If I can find the thread, I'll send the link. Paul On Wed, Sep 3, 2008 at 5:58 PM, Brett Porter [EMAIL PROTECTED] wrote: Is the +1 to Paul or to Wendy? :) What I understand the current situation to be: * things fixed in both 2.0.10 and 2.1.0 are marked in both * these do not automatically apply to 3.0 since it's now to hard to merge a lot of them so it'll be brought to backwards compat via ITs * in the event something can be merged to 3.0 it will be marked with both. That seems fine to me. The release notes issue Wendy raised annoys me too, but we can workaround that, or strip them off later. If 2.1.0 is out before 2.0.10 it makes a lot of sense to include them in both release notes. John, as far as your concerned, JIRA is up to date in this regard now, right? Cheers, Brett On 04/09/2008, at 12:48 AM, John Casey wrote: +1 Wendy Smoak wrote: On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict [EMAIL PROTECTED] wrote: Are there any objections to marking the 2.0.10 issues also for 2.1 and 3.0? I can do a batch update with no email notice. Let me know. I am in no hurry to make the change. If I see no objections by the weekend, I'll do it to keep good issue tracking. Isn't it implied that anything fixed in a prior version _stays_ fixed in a later one? I don't think I want to see everything from 2.0.10 show up again in the release notes for 2.1 and 3.0, I only want to see what's new. -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Marking 2.0.10 issues also 2.1.x and 3.0
I updated the 2.0.10 issues today, so I *think* it's all up to date. Brett Porter wrote: Is the +1 to Paul or to Wendy? :) What I understand the current situation to be: * things fixed in both 2.0.10 and 2.1.0 are marked in both * these do not automatically apply to 3.0 since it's now to hard to merge a lot of them so it'll be brought to backwards compat via ITs * in the event something can be merged to 3.0 it will be marked with both. That seems fine to me. The release notes issue Wendy raised annoys me too, but we can workaround that, or strip them off later. If 2.1.0 is out before 2.0.10 it makes a lot of sense to include them in both release notes. John, as far as your concerned, JIRA is up to date in this regard now, right? Cheers, Brett On 04/09/2008, at 12:48 AM, John Casey wrote: +1 Wendy Smoak wrote: On Wed, Sep 3, 2008 at 5:34 AM, Paul Benedict [EMAIL PROTECTED] wrote: Are there any objections to marking the 2.0.10 issues also for 2.1 and 3.0? I can do a batch update with no email notice. Let me know. I am in no hurry to make the change. If I see no objections by the weekend, I'll do it to keep good issue tracking. Isn't it implied that anything fixed in a prior version _stays_ fixed in a later one? I don't think I want to see everything from 2.0.10 show up again in the release notes for 2.1 and 3.0, I only want to see what's new. -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - 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] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] Maven 2.1.0-M1-RC13
Hi again everyone, On the last go around, we had one issue pop up with maven plugin builds (though it might also apply to build extensions in the reactor as well). I've fixed it, and now here's the lucky 13th release candidate: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1-RC13/org/apache/maven/apache-maven/2.1.0-M1-RC13/ Please give it a spin (especially you, Arnaud! :) ), and let me know if you have any trouble. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Marking 2.0.10 issues also 2.1.x and 3.0
Awesome. Thanks John! Paul On Wed, Sep 3, 2008 at 7:47 PM, John Casey [EMAIL PROTECTED] wrote: I updated the 2.0.10 issues today, so I *think* it's all up to date. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
m-eclipse-p: ITs failing
mvn 2.0.9 Latest version from head 691563 on a Windows XP box. All the testProject* in the ITs are failing with the same error: Failed to execute build. POM: D:\ide\maven\maven-eclipse-plugin\target\test-classes\projects\project-01\pom.xml Goals: org.apache.maven.plugins:maven-eclipse-plugin:test:clean, org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse Exit Code: 1 Error: null Build Log: file:/D:/ide/maven/maven-eclipse-plugin/target/surefire-reports/build-output/org.apache.maven.plugin.eclipse.it.EclipsePluginIT_testProject01.build.log (Resulting exit code: 1) or if I re-run mvn -Prun-its install without doing a clean I get this error. [INFO] Surefire report directory: D:\ide\maven\maven-eclipse-plugin\target\surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: projects/j2ee-simple/primary-source/target/classes/TestServlet (wrong name: TestServlet); nested exception is java.lang.NoClassDefFoundError: projects/j2ee-simple/primary-source/t arget/classes/TestServlet (wrong name: TestServlet) java.lang.NoClassDefFoundError: projects/j2ee-simple/primary-source/target/classes/TestServlet (wrong name: TestServlet) doing a clean first gets me the first error. Anyone with any clues? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
