AW: [VOTE] Release Maven War plugin version 2.1-alpha-2
+1 -Ursprüngliche Nachricht- Von: Wendy Smoak [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 9. August 2008 18:19 An: Maven Developers List Betreff: [VOTE] Release Maven War plugin version 2.1-alpha-2 It's time to release the War Plugin. Thanks to Benjamin and Olivier for removing all the snapshot dependencies to make this possible! We discussed making this release beta-1 or even 2.1, but with all the recent changes around filtering I decided to stay with alpha-2. Trunk is now beta-1, and we can decide next time whether to keep that or make it 2.1. This is one of the most-requested plugin releases on the user list, so I would appreciate extra testing if you have time. We solved 27 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13804styleName=TextprojectId=11150Create=Create There are 38 issues left in JIRA: http://jira.codehaus.org/browse/MWAR Staging repo: http://people.apache.org/~wsmoak/staging-repo Staging site: http://maven.apache.org/plugins/maven-war-plugin-2.1-alpha-2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours, assuming it passes I'll probably finish it on Wednesday. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Wendy - 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: [PLEASE TEST] Maven 2.0.10-RC6
Hi John, It seems that project.getExecutionProject().getCompileSourceRoots() uses relative paths (i.e. target/generated-sources/plugin) Thanks, Vincent 2008/8/9 Wendy Smoak [EMAIL PROTECTED]: On Fri, Aug 8, 2008 at 3:52 PM, John Casey [EMAIL PROTECTED] wrote: The distro is here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC6/org/apache/maven/apache-maven/2.0.10-RC6 Please give it a spin and see what you think! I'm having trouble with RC6 and the Javadoc plugin. I see it on OS X and Linux, Benjamin confirmed it on Windows. It doesn't happen with 2.0.8 or 2.0.9. Try this: svn co https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-war-plugin cd maven-war-plugin mvn install mvn site -Preporting ... [INFO] Generating JavaDocs report. [WARNING] Source files encoding has not been set, using platform encoding MacRoman, i.e. build is platform dependent! [DEBUG] /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc @options @packages Loading source files for package org.apache.maven.plugin.war... Loading source files for package org.apache.maven.plugin.war.overlay... Loading source files for package org.apache.maven.plugin.war.packaging... Loading source files for package org.apache.maven.plugin.war.util... 1 error [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - javadoc: error - Illegal package name: maven-war-plugin.target.generated-sources.plugin.org.apache.maven.plugin.war Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc @options @packages [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during page generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:629) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:533) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:364) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:325) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:176) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:461) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:604) ... 16 more Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error rendering Maven report: Exit code: 1 - javadoc: error - Illegal package name: maven-war-plugin.target.generated-sources.plugin.org.apache.maven.plugin.war Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc @options @packages at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:149) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) ... 18 more Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 1 - javadoc: error - Illegal package name:
Rationale of maven-javadoc-plugins parameter javadocDirectory
Hi, I have attempted to use the javadocDirectory plugin of the maven-javadoc-plugin. In 2.4, this parameter is documented like this: Specifies the Javadoc ressources directory to be included in the Javadoc (i.e. package.html, images...). I read this like I could use the parameter for the typical Apache use case (add NOTICE.txt and LICENSE.txt files). However, obviously this won't work. First of all, it seems that the parameter is used only when generating a report: Within javadoc:jar the method copyJavadocResources is never invoked. Second, the implementation is based on a call FileUtils.getDirectoryNames( javadocDir, **/doc-files, StringUtils.join( FileUtils .getDefaultExcludes(), , ), false, true ) which I do not understand at all. Why should I have a directory doc-files? Are these bugs that we should fix? Otherwise: Could we add a resources parameter to the javadoc plugin? Thanks, Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY][RESULT] Which plugin would you like us to release?
Dennis, Just a follow up on the reports. The reports generated by Swizzle are here (I restored them): https://svn.apache.org/repos/asf/maven/sandbox/trunk/reports And they are checked out in the home directory of Hudson on the CI server. Also note that whatever reports we come up we can ultimately embed in Confluence as David wrote a Confluence macro for this stuff. I would just want to check if there is caching because having the actual reporting logic run every time you hit the page would be bad. On 8-Aug-08, at 12:44 PM, Jason van Zyl wrote: Dennis, If you're interested and want to use this in conjunction with your surveys: I created a panel in Hudson: http://ci.sonatype.org/view/Reports/ There is a Plugin Votes Report, and when you trigger the job it will render this: http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.txt They just use Swizzle (which is very handy) so any types of reports you think might help make the releases more user focused just let me know. On 7-Aug-08, at 1:59 PM, Dennis Lundberg wrote: The survey has been open for a week now and has now been closed. Thanks to the 47 people who took the survey! Here are the top 5 five most wanted plugin releases: Plugin Response Percent war 12.8% release 12.8% enforcer10.6% scm 10.6% assembly 8.5% Dennis Lundberg wrote: Hello everyone I'm going to try something new here. It's an experiment and we'll see how it goes. I have set up a very simple survey over at SurveyMonkey, to get a feel for what you, our users, want us to do next when it comes to plugin releases. Remember, this is *not* about fixing issues - it's about getting releases out. So please help us help you, by answering this one question survey: http://www.surveymonkey.com/s.aspx?sm=M6IB7I_2fVmpKddfv1oCM_2few_3d_3d -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
+1 We've offered our help from Eclipse IAM in the past [1], and maybe we can get the Eclipse Buckminster folks to lend a hand. Since there are many external parties interested, having a clear roadmap/project plan for what would be an stable embedder would be extremely useful. As Milos mentions, I would like to avoid researching a bugfix for something that is meant to be rewritten. [1] http://www.eclipse.org/newsportal/article.php?id=48group=eclipse.technology.m2e#48 Abel Muiño Milos Kleint wrote: oh, and one more thing. I'm willing to add a helping hand with stabilisation, however I've been burned a few times in the past when I did. There's no point fixing any issue when 2 weeks later everything gets washed away and changed completely. Milos On 8/8/08, Milos Kleint [EMAIL PROTECTED] wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Just my 2 cents. Milos On 8/8/08, Brian E. Fox [EMAIL PROTECTED] wrote: I have been saying that the trunk is too changed for 2.1 for a while also. I think having it as 3.0 is probably the logical thing to do and then we can really buckle 2.0 down as it should be and start making these bigger destabilizing fixes/small features to a 2.1 branch cut from 2.0.10. Unless 2.0.10 gets worked out real soon, perhaps we even go back to 2.0.9 and branch there (ie 2.0.10 becomes 2.1.0) -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2008 11:16 PM To: Maven Developers List Subject: Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable) On 08/08/2008, at 12:24 PM, Paul Benedict wrote: Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate to bump the first number when you make a major architecture change. It was totally appropriate between 1.x and 2.x because the code bases are absolutely incompatible. Why I should believe the same for TRUNK now? It still looks like 2.1 -- evolution -- not 3.0 -- revolution. Let's not forget this famous popular Apache email A significant advance would warrant a 3.0, incompatibility is not a requirement. If it can still be backwards compatible then all the better (though managed incompatibilities would be acceptable). Look at Jetty, Tomcat, etc. Some major releases required migration, some didn't. http://incubator.apache.org/learn/rules-for-revolutionaries.html I definitely think that's a good way to operate, and it's a good, quick, read. Most of the work being proposed is operating under these rules to some extent. It's been done in the sandbox or branches for later proposal for inclusion/replacement of trunk. It's definitely revolutionary - every subsystem is being reviewed or replaced to give us the ability to fix some of the more challenging issues. Even though I'm sure there is consensus that is the right way to go, timing is the issue. There is not consensus that it should be Maven.NEXT. Right now our evolutionary track is 2.0.x, and that seems wrong to a lot of people. It limits us to very few improvements as folks are expecting only bugfixes, with good reason. But also our evolutionary track needs to be something we can release, and that's not trunk today. Taking 2.0.10 as a baseline and applying some sensible, well managed improvements (which may well include adopting the alternate project builder, for example, as well as others already mentioned) makes a lot of sense. Cheers, Brett -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - http://www.linkedin.com/in/amuino Abel Muintilde;o Vizcaino - http://ramblingabout.wordpress.com http://ramblingabout.wordpress.com -- View this message in context: http://www.nabble.com/Versioning-Maven-%28was%3A-Re%3A-Maven-2.1-development-IRC-roundtable%29-tp18875440p18914964.html Sent from the Maven Developers mailing list archive at Nabble.com.
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi [EMAIL PROTECTED] wrote: Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? well, the version number itself is of little interest to me, but I see a lot of people cooking new stuff at branches. I suppose the intention is to get this code into trunk. The question for me is wheher it gets into trunk before the maven.next is released or after (be it 2.1 or 3.0 ). The maven.next that's interesting to me is the version that is embeddable. Also cutting an alpha or beta would enable IDE devs to work to that without having sleepless nights about stabilisation. Well, if the alphas and betas get cut from a stable branch that will ultimately become the next final release, I'm cool with it. Milos Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven War plugin version 2.1-alpha-2
+1 -- Olivier 2008/8/9 Wendy Smoak [EMAIL PROTECTED]: It's time to release the War Plugin. Thanks to Benjamin and Olivier for removing all the snapshot dependencies to make this possible! We discussed making this release beta-1 or even 2.1, but with all the recent changes around filtering I decided to stay with alpha-2. Trunk is now beta-1, and we can decide next time whether to keep that or make it 2.1. This is one of the most-requested plugin releases on the user list, so I would appreciate extra testing if you have time. We solved 27 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13804styleName=TextprojectId=11150Create=Create There are 38 issues left in JIRA: http://jira.codehaus.org/browse/MWAR Staging repo: http://people.apache.org/~wsmoak/staging-repo Staging site: http://maven.apache.org/plugins/maven-war-plugin-2.1-alpha-2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours, assuming it passes I'll probably finish it on Wednesday. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Wendy - 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: [SURVEY][RESULT] Which plugin would you like us to release?
On Aug 10, 2008, at 9:54 AM, Jason van Zyl wrote: Dennis, Just a follow up on the reports. The reports generated by Swizzle are here (I restored them): https://svn.apache.org/repos/asf/maven/sandbox/trunk/reports And they are checked out in the home directory of Hudson on the CI server. Also note that whatever reports we come up we can ultimately embed in Confluence as David wrote a Confluence macro for this stuff. I would just want to check if there is caching because having the actual reporting logic run every time you hit the page would be bad. It caches for an hour, which may not be enough. Can't remember if it's configurable. -David On 8-Aug-08, at 12:44 PM, Jason van Zyl wrote: Dennis, If you're interested and want to use this in conjunction with your surveys: I created a panel in Hudson: http://ci.sonatype.org/view/Reports/ There is a Plugin Votes Report, and when you trigger the job it will render this: http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.txt They just use Swizzle (which is very handy) so any types of reports you think might help make the releases more user focused just let me know. On 7-Aug-08, at 1:59 PM, Dennis Lundberg wrote: The survey has been open for a week now and has now been closed. Thanks to the 47 people who took the survey! Here are the top 5 five most wanted plugin releases: Plugin Response Percent war 12.8% release 12.8% enforcer10.6% scm 10.6% assembly 8.5% Dennis Lundberg wrote: Hello everyone I'm going to try something new here. It's an experiment and we'll see how it goes. I have set up a very simple survey over at SurveyMonkey, to get a feel for what you, our users, want us to do next when it comes to plugin releases. Remember, this is *not* about fixing issues - it's about getting releases out. So please help us help you, by answering this one question survey: http://www.surveymonkey.com/s.aspx?sm=M6IB7I_2fVmpKddfv1oCM_2few_3d_3d -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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]
New GMaven 1.0-rc-3-SNAPSHOT deployed; Please Test
I've just deployed a new set of snapshots for GMaven 1.0-rc-3- SNAPSHOT. This contains a bunch of stuff. See the road-map for more details: http://jira.codehaus.org/browse/MGROOVY?report=com.atlassian.jira.plugin.system.project:roadmap-panel Anyways, just wanted folks to give this new snap a test and if its all happy happy I'm going to release it shortly. So, please, please give it a try and let me know if anything breaks. Thanks, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Request for comments at http://jira.codehaus.org/browse/SUREFIRE-511
comments for this improvement is much appreciated. Thanks -D - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
I think having the intermediary bridge is a good idea, and I would be comfortable finding the last stable version of trunk that works with Mevenide and then release that and then leave that as a stable branch for you to work off. One of the problems is that your code seems not to be very testable from your own description and there's nothing we could run to validate changes in trunk haven't busted you without you manually testing. You have to do something about that because asking you to manually try things isn't tenable. We'll make the stable branch of 3.0.x, and then we can leave that pretty much static except for bug fixes you want to put in there. I need a release just as badly as you for the Eclipse IP process. So if you we can match what you're using and find that point in time where you're happy we'll roll back trunk to there, cut a 3.0.x branch and you will have something stable. I want to continue getting Mercury and Shane's new project builder in because to me that will be a massive stabilization in the artifact mechanism and Shane is just tearing out all sort of cruft that's built up in the POM builder and we're just not going to be able to create a spec'd process, mixins support, multi-format/version support, and a many other things with these two changes. Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy to rollback/patch to whatever point in time makes you comfortable. I would prefer to plough along on trunk which looks like would become 3.1.x in this scheme. You would probably stay away from Mercury and we are really going to need a harness from you we can run. The ITs will get better and be protection at the CLI level but you seem to keep getting bitten at the embedder level. Let me know what you would like to do. On 10-Aug-08, at 10:37 AM, Milos Kleint wrote: On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi [EMAIL PROTECTED] wrote: Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? well, the version number itself is of little interest to me, but I see a lot of people cooking new stuff at branches. I suppose the intention is to get this code into trunk. The question for me is wheher it gets into trunk before the maven.next is released or after (be it 2.1 or 3.0 ). The maven.next that's interesting to me is the version that is embeddable. Also cutting an alpha or beta would enable IDE devs to work to that without having sleepless nights about stabilisation. Well, if the alphas and betas get cut from a stable branch that will ultimately become the next final release, I'm cool with it. Milos Cheers - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven
That is all OK, but I'd really like to see a 2.1 that allows more to be done on the 2.0.x branch than we are currently comfortable with. Nothing as revolutionary as what is in trunk, but with some ability to fix some problems that might not be completely compatible. The bugs I am currently looking at - MNG-624, MNG-2446, MNG-2971 and MNG-3267 are examples of this. 624 is actually pretty easy and I have code that has no compatiblity problems and is actually pretty simple. But it is still an enhancement. The other issues identify a problem that is a little harder to fix only because I haven't figured out how it could be done without being incompatible, even if what is currently happening - deploying poms with a variable in the version element - is just wrong. Ralph Jason van Zyl wrote: I think having the intermediary bridge is a good idea, and I would be comfortable finding the last stable version of trunk that works with Mevenide and then release that and then leave that as a stable branch for you to work off. One of the problems is that your code seems not to be very testable from your own description and there's nothing we could run to validate changes in trunk haven't busted you without you manually testing. You have to do something about that because asking you to manually try things isn't tenable. We'll make the stable branch of 3.0.x, and then we can leave that pretty much static except for bug fixes you want to put in there. I need a release just as badly as you for the Eclipse IP process. So if you we can match what you're using and find that point in time where you're happy we'll roll back trunk to there, cut a 3.0.x branch and you will have something stable. I want to continue getting Mercury and Shane's new project builder in because to me that will be a massive stabilization in the artifact mechanism and Shane is just tearing out all sort of cruft that's built up in the POM builder and we're just not going to be able to create a spec'd process, mixins support, multi-format/version support, and a many other things with these two changes. Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy to rollback/patch to whatever point in time makes you comfortable. I would prefer to plough along on trunk which looks like would become 3.1.x in this scheme. You would probably stay away from Mercury and we are really going to need a harness from you we can run. The ITs will get better and be protection at the CLI level but you seem to keep getting bitten at the embedder level. Let me know what you would like to do. On 10-Aug-08, at 10:37 AM, Milos Kleint wrote: On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi [EMAIL PROTECTED] wrote: Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? well, the version number itself is of little interest to me, but I see a lot of people cooking new stuff at branches. I suppose the intention is to get this code into trunk. The question for me is wheher it gets into trunk before the maven.next is released or after (be it 2.1 or 3.0 ). The maven.next that's interesting to me is the version that is embeddable. Also cutting an alpha or beta would enable IDE devs to work to that without having sleepless nights about stabilisation. Well, if the alphas and betas get cut from a stable branch that will ultimately become the next final release, I'm cool with it. Milos Cheers - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven
On 10-Aug-08, at 2:25 PM, Ralph Goers wrote: That is all OK, but I'd really like to see a 2.1 that allows more to be done on the 2.0.x branch than we are currently comfortable with. That's the plan that people have been suggesting and what I refer to as the intermediary bridge i.e. the next mild step to 2.1.x from 2.0.x. Where the trunk goes to 3.0.x. Nothing as revolutionary as what is in trunk, but with some ability to fix some problems that might not be completely compatible. The bugs I am currently looking at - MNG-624, MNG-2446, MNG-2971 and MNG-3267 are examples of this. 624 is actually pretty easy and I have code that has no compatiblity problems and is actually pretty simple. But it is still an enhancement. Sure, do that on 2.1.x (as we now seem to be calling it). I don't see any problem with that. The other issues identify a problem that is a little harder to fix only because I haven't figured out how it could be done without being incompatible, even if what is currently happening - deploying poms with a variable in the version element - is just wrong. Not necessarily. A property referring to a profile activated on a particular platform where it was expected to be evaluated during the build would cause a problem. I don't think it's as straight forward as interpolating prior to deployment. This is part of the overall process we need a spec for. This is not a very concrete answer but there are probably a range of things that can safely be interpolated and probably make sense, any properties associated with profiles activate by OS, JDK, or some other ad-hoc property referring to an environment will probably cause problems. Should people do this, probably not. But we never told them not to. Then how to you categorize what's allowed and what's not. No idea. I think Brian wanted to cut from 2.0.9 instead of 2.0.10 but you guys should go for it. We just need to make sure the integration tests actually mean something so when I try to match capabilities with a potentially different implementation/solution it don't whack everyone. Ralph Jason van Zyl wrote: I think having the intermediary bridge is a good idea, and I would be comfortable finding the last stable version of trunk that works with Mevenide and then release that and then leave that as a stable branch for you to work off. One of the problems is that your code seems not to be very testable from your own description and there's nothing we could run to validate changes in trunk haven't busted you without you manually testing. You have to do something about that because asking you to manually try things isn't tenable. We'll make the stable branch of 3.0.x, and then we can leave that pretty much static except for bug fixes you want to put in there. I need a release just as badly as you for the Eclipse IP process. So if you we can match what you're using and find that point in time where you're happy we'll roll back trunk to there, cut a 3.0.x branch and you will have something stable. I want to continue getting Mercury and Shane's new project builder in because to me that will be a massive stabilization in the artifact mechanism and Shane is just tearing out all sort of cruft that's built up in the POM builder and we're just not going to be able to create a spec'd process, mixins support, multi-format/version support, and a many other things with these two changes. Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy to rollback/patch to whatever point in time makes you comfortable. I would prefer to plough along on trunk which looks like would become 3.1.x in this scheme. You would probably stay away from Mercury and we are really going to need a harness from you we can run. The ITs will get better and be protection at the CLI level but you seem to keep getting bitten at the embedder level. Let me know what you would like to do. On 10-Aug-08, at 10:37 AM, Milos Kleint wrote: On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi [EMAIL PROTECTED] wrote: Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? well, the version number itself is of little interest to me, but I see a lot of people cooking new stuff at branches. I suppose the intention is to get this code into trunk. The question for me is wheher it gets into trunk before the maven.next is released or after (be it 2.1 or 3.0 ). The maven.next that's interesting to me is the version that is embeddable. Also cutting an alpha or beta would
Re: Versioning Maven
Jason van Zyl wrote: The other issues identify a problem that is a little harder to fix only because I haven't figured out how it could be done without being incompatible, even if what is currently happening - deploying poms with a variable in the version element - is just wrong. Not necessarily. A property referring to a profile activated on a particular platform where it was expected to be evaluated during the build would cause a problem. I don't think it's as straight forward as interpolating prior to deployment. This is part of the overall process we need a spec for. This is not a very concrete answer but there are probably a range of things that can safely be interpolated and probably make sense, any properties associated with profiles activate by OS, JDK, or some other ad-hoc property referring to an environment will probably cause problems. Should people do this, probably not. But we never told them not to. Then how to you categorize what's allowed and what's not. No idea. I think Brian wanted to cut from 2.0.9 instead of 2.0.10 but you guys should go for it. We just need to make sure the integration tests actually mean something so when I try to match capabilities with a potentially different implementation/solution it don't whack everyone. This is somewhat off topic from versioning. I was specifically calling out using a property for the artifact version. To leave that in the pom when it is deployed is just wrong. I can think of all kinds of other properties that shouldn't be replaced, so full interpolation is clearly unacceptable. I'm also a little unclear on the integration tests. I see a couple of branches that appear to be for specific jira issues, but nothing else. How are different tests run against maven trunk vs 2.0.x? Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r684485 - /maven/plugins/trunk/maven-javadoc-plugin/pom.xml
Why are you locking it here instead in the parent pom ?
I think it's a better practice to do it in an higher level ASAP to check
that we don't find regressions in our builds.
WDYT ?
If you will release the javadoc plugin, I think parents will be released
soon ?
We are just waiting for a release of the enforcer ?
Arnaud
On Sun, Aug 10, 2008 at 2:25 PM, [EMAIL PROTECTED] wrote:
Author: vsiveton
Date: Sun Aug 10 05:25:30 2008
New Revision: 684485
URL: http://svn.apache.org/viewvc?rev=684485view=rev
Log:
o lock down invoker-plugin version
Modified:
maven/plugins/trunk/maven-javadoc-plugin/pom.xml
Modified: maven/plugins/trunk/maven-javadoc-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/pom.xml?rev=684485r1=684484r2=684485view=diff
==
--- maven/plugins/trunk/maven-javadoc-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-javadoc-plugin/pom.xml Sun Aug 10 05:25:30
2008
@@ -212,6 +212,7 @@
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-invoker-plugin/artifactId
+version1.2.1/version
configuration
projectsDirectorysrc/it/projectsDirectory
cloneProjectsTo${project.build.directory}/it/cloneProjectsTo
--
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...
Re: Versioning Maven
On 10-Aug-08, at 5:26 PM, Ralph Goers wrote: Jason van Zyl wrote: The other issues identify a problem that is a little harder to fix only because I haven't figured out how it could be done without being incompatible, even if what is currently happening - deploying poms with a variable in the version element - is just wrong. Not necessarily. A property referring to a profile activated on a particular platform where it was expected to be evaluated during the build would cause a problem. I don't think it's as straight forward as interpolating prior to deployment. This is part of the overall process we need a spec for. This is not a very concrete answer but there are probably a range of things that can safely be interpolated and probably make sense, any properties associated with profiles activate by OS, JDK, or some other ad-hoc property referring to an environment will probably cause problems. Should people do this, probably not. But we never told them not to. Then how to you categorize what's allowed and what's not. No idea. I think Brian wanted to cut from 2.0.9 instead of 2.0.10 but you guys should go for it. We just need to make sure the integration tests actually mean something so when I try to match capabilities with a potentially different implementation/solution it don't whack everyone. This is somewhat off topic from versioning. I was specifically calling out using a property for the artifact version. To leave that in the pom when it is deployed is just wrong. I can think of all kinds of other properties that shouldn't be replaced, so full interpolation is clearly unacceptable. Sure, like I said above there are things I would agree with you on. But I know of places that I've seen (ClearCase setups) which use the properties left to be interpreted by the system. Think of the versions specified in the depMan section being retrieved from an external source. You can deploy with the variables in there provided the external system (like a set of envars) or a custom version resolver (something I hacked into 2.1 for a client). Just telling you what I've seen. If we want to cut off this behavior then 2.1 would be a good place to define that. I'm also a little unclear on the integration tests. I see a couple of branches that appear to be for specific jira issues, but nothing else. How are different tests run against maven trunk vs 2.0.x? There is only one body of integration tests, and when a feature is added an integration test should be added. If it's version specific you can say so in the constructor of the test and harness will know whether to run it, or not, based on the version of Maven you're testing with. We run the same body on integration tests against the branches and trunk all the time. This way we can make sure, or detect, when things work in the branch but don't in the trunk. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
Jason, The issues I'm finding (or my userbase actually) are not with mevenide integration. It's also not something I could test on my side. It's in 99% of cases incompatibilities with 2.0.x. And it's not a reoccuring pattern, no trunk-to-trunk regressions. So no test could save me from it anyway. And *if* I wrote tests, it would be in maven not mevenide. That's where it belongs IMHO. So please don't make it sound like it's my own fault anyway. more inline On Sun, Aug 10, 2008 at 10:18 PM, Jason van Zyl [EMAIL PROTECTED] wrote: I think having the intermediary bridge is a good idea, and I would be comfortable finding the last stable version of trunk that works with Mevenide and then release that and then leave that as a stable branch for you to work off. One of the problems is that your code seems not to be very testable from your own description and there's nothing we could run to validate changes in trunk haven't busted you without you manually testing. You have to do something about that because asking you to manually try things isn't tenable. We'll make the stable branch of 3.0.x, and then we can leave that pretty much static except for bug fixes you want to put in there. I need a release just as badly as you for the Eclipse IP process. So if you we can match what you're using and find that point in time where you're happy we'll roll back trunk to there, cut a 3.0.x branch and you will have something stable. well, any of the 6 or so snapshots I've used in the past 6-8 months had some (different) rough edges. So from my perspective it can be current trunk, no need to go backwards. I want to continue getting Mercury and Shane's new project builder in because to me that will be a massive stabilization in the artifact mechanism and Shane is just tearing out all sort of cruft that's built up in the POM builder and we're just not going to be able to create a spec'd process, mixins support, multi-format/version support, and a many other things with these two changes. It's all cool and I want it in the released bits just as you do but it IMHO pushes the release into more distant future. That's what I was pointing to my previous emails. regards Milos Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy to rollback/patch to whatever point in time makes you comfortable. I would prefer to plough along on trunk which looks like would become 3.1.x in this scheme. You would probably stay away from Mercury and we are really going to need a harness from you we can run. The ITs will get better and be protection at the CLI level but you seem to keep getting bitten at the embedder level. Let me know what you would like to do. On 10-Aug-08, at 10:37 AM, Milos Kleint wrote: On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi [EMAIL PROTECTED] wrote: Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? well, the version number itself is of little interest to me, but I see a lot of people cooking new stuff at branches. I suppose the intention is to get this code into trunk. The question for me is wheher it gets into trunk before the maven.next is released or after (be it 2.1 or 3.0 ). The maven.next that's interesting to me is the version that is embeddable. Also cutting an alpha or beta would enable IDE devs to work to that without having sleepless nights about stabilisation. Well, if the alphas and betas get cut from a stable branch that will ultimately become the next final release, I'm cool with it. Milos Cheers - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
On 10-Aug-08, at 9:05 PM, Milos Kleint wrote: Jason, The issues I'm finding (or my userbase actually) are not with mevenide integration. It's also not something I could test on my side. It's in 99% of cases incompatibilities with 2.0.x. And it's not a reoccuring pattern, no trunk-to-trunk regressions. So no test could save me from it anyway. And *if* I wrote tests, it would be in maven not mevenide. That's where it belongs IMHO. So please don't make it sound like it's my own fault anyway. I'm not trying to make it sound like your fault. The specific case you mentioned was a trunk-to-trunk regression so that's what I based my message. Sorry, if it sounded like I was trying to pin it on you. There is a bigger problem with digression between the trunk and what's released and a lot of this surfaces in plugins. That is rapidly being addressed in the work going on with testing the plugins and setting up a set of plugin ITs we can run against trunk to find problems. I bet when we run them we'll have a lot of information to work with. So I'm definitely not trying to pin anything on you. We have had a hard time automating tests in m2eclipse, and after creating integration with Tycho to the point where we can automate them without PDE headless build we are in good shape and it will be harder for regressions to slip through. So it appears there will be a mediating 2.1.x branch, and if you're willing to take what's on trunk (or at least work off it) then I'm happy to cut a release as raw as it is. It's really only going to be for embedder users in the next few weeks anyway. We'll make it clear what we're doing and we'll have to work fast to get some parity. I think with a plugin IT harness in place all sorts of crap will fall out. more inline On Sun, Aug 10, 2008 at 10:18 PM, Jason van Zyl [EMAIL PROTECTED] wrote: I think having the intermediary bridge is a good idea, and I would be comfortable finding the last stable version of trunk that works with Mevenide and then release that and then leave that as a stable branch for you to work off. One of the problems is that your code seems not to be very testable from your own description and there's nothing we could run to validate changes in trunk haven't busted you without you manually testing. You have to do something about that because asking you to manually try things isn't tenable. We'll make the stable branch of 3.0.x, and then we can leave that pretty much static except for bug fixes you want to put in there. I need a release just as badly as you for the Eclipse IP process. So if you we can match what you're using and find that point in time where you're happy we'll roll back trunk to there, cut a 3.0.x branch and you will have something stable. well, any of the 6 or so snapshots I've used in the past 6-8 months had some (different) rough edges. So from my perspective it can be current trunk, no need to go backwards. I want to continue getting Mercury and Shane's new project builder in because to me that will be a massive stabilization in the artifact mechanism and Shane is just tearing out all sort of cruft that's built up in the POM builder and we're just not going to be able to create a spec'd process, mixins support, multi-format/version support, and a many other things with these two changes. It's all cool and I want it in the released bits just as you do but it IMHO pushes the release into more distant future. That's what I was pointing to my previous emails. regards Milos Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy to rollback/patch to whatever point in time makes you comfortable. I would prefer to plough along on trunk which looks like would become 3.1.x in this scheme. You would probably stay away from Mercury and we are really going to need a harness from you we can run. The ITs will get better and be protection at the CLI level but you seem to keep getting bitten at the embedder level. Let me know what you would like to do. On 10-Aug-08, at 10:37 AM, Milos Kleint wrote: On Sat, Aug 9, 2008 at 11:32 AM, Mauro Talevi [EMAIL PROTECTED] wrote: Milos Kleint wrote: please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again. Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Milos, isn't just a case of renaming trunk/2.1 to trunk/3 ? well, the version number itself is of little interest to me, but I see a lot of people cooking new stuff at branches. I suppose the intention is to get this code into trunk. The question for me is wheher it gets into trunk before the maven.next is released or after (be it 2.1 or 3.0 ). The maven.next that's interesting to
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
So it looks like the general consensus is: - Cut a 2.1.x branch from a 2.0.x tag (I saw 2.0.9 and 2.0.10 float by as options) - Call trunk 3.0-SNAPSHOT We'll just bugfix 2.0.x. The 2.1.x branch will be the mediator toward 3.0, and given the mediator exists we're a lot safer doing a 3.0- alpha-1 release of trunk primarily for embedder consumers. We'll work toward fixing all the regressions which will become readily apparent with the plugin IT testing in Hudson. I still think an IRC discussion would be prudent but the scheduling seems to have not come up again. After this week I bet there will be a lot to talk about. I would say pick next Monday/Tuesday and give people a week to plan for a discussion that will probably last a couple hours. On 10-Aug-08, at 9:34 PM, Jason van Zyl wrote: On 10-Aug-08, at 9:05 PM, Milos Kleint wrote: Jason, The issues I'm finding (or my userbase actually) are not with mevenide integration. It's also not something I could test on my side. It's in 99% of cases incompatibilities with 2.0.x. And it's not a reoccuring pattern, no trunk-to-trunk regressions. So no test could save me from it anyway. And *if* I wrote tests, it would be in maven not mevenide. That's where it belongs IMHO. So please don't make it sound like it's my own fault anyway. I'm not trying to make it sound like your fault. The specific case you mentioned was a trunk-to-trunk regression so that's what I based my message. Sorry, if it sounded like I was trying to pin it on you. There is a bigger problem with digression between the trunk and what's released and a lot of this surfaces in plugins. That is rapidly being addressed in the work going on with testing the plugins and setting up a set of plugin ITs we can run against trunk to find problems. I bet when we run them we'll have a lot of information to work with. So I'm definitely not trying to pin anything on you. We have had a hard time automating tests in m2eclipse, and after creating integration with Tycho to the point where we can automate them without PDE headless build we are in good shape and it will be harder for regressions to slip through. So it appears there will be a mediating 2.1.x branch, and if you're willing to take what's on trunk (or at least work off it) then I'm happy to cut a release as raw as it is. It's really only going to be for embedder users in the next few weeks anyway. We'll make it clear what we're doing and we'll have to work fast to get some parity. I think with a plugin IT harness in place all sorts of crap will fall out. more inline On Sun, Aug 10, 2008 at 10:18 PM, Jason van Zyl [EMAIL PROTECTED] wrote: I think having the intermediary bridge is a good idea, and I would be comfortable finding the last stable version of trunk that works with Mevenide and then release that and then leave that as a stable branch for you to work off. One of the problems is that your code seems not to be very testable from your own description and there's nothing we could run to validate changes in trunk haven't busted you without you manually testing. You have to do something about that because asking you to manually try things isn't tenable. We'll make the stable branch of 3.0.x, and then we can leave that pretty much static except for bug fixes you want to put in there. I need a release just as badly as you for the Eclipse IP process. So if you we can match what you're using and find that point in time where you're happy we'll roll back trunk to there, cut a 3.0.x branch and you will have something stable. well, any of the 6 or so snapshots I've used in the past 6-8 months had some (different) rough edges. So from my perspective it can be current trunk, no need to go backwards. I want to continue getting Mercury and Shane's new project builder in because to me that will be a massive stabilization in the artifact mechanism and Shane is just tearing out all sort of cruft that's built up in the POM builder and we're just not going to be able to create a spec'd process, mixins support, multi-format/version support, and a many other things with these two changes. It's all cool and I want it in the released bits just as you do but it IMHO pushes the release into more distant future. That's what I was pointing to my previous emails. regards Milos Releasing trunk as 2.1 I think would be a very bad idea, but I'm happy to rollback/patch to whatever point in time makes you comfortable. I would prefer to plough along on trunk which looks like would become 3.1.x in this scheme. You would probably stay away from Mercury and we are really going to need a harness from you we can run. The ITs will get better and be protection at the CLI level but you seem to keep getting bitten at the embedder level. Let me know what you would like to do. On 10-Aug-08, at 10:37 AM, Milos Kleint wrote: On Sat, Aug 9, 2008 at
