Re: build maven 2.1 from repository
Thanks, I was, but I had problems with the embedder. It had bugs and I could not use it to call maven archetype goals with parameters and I got a code snippet that should work, only it depends on the 2.1 version I will try again. Jesse McConnell wrote: > > your better bet is to pull from > > http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x > > As that is there the next release is being worked on. it was decided > to do a couple more 2.0.X releases before committing to new 2.1 > features. In fact my bet is that the 2.0.x branch will be heading > back to trunk at some point before 2.1 actually rears its head up. > > jesse > > On 12/23/06, shooali <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> I am trying to build maven 2.1 from repository (from scratch) to no >> success. >> >> I have added the profiles to the settings.xml according to >> http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html >> >> but it does not help. >> >> Attached please find the error. >> >> Thanks in advance, >> >> Shooali >> >> + Error stacktraces are turned on. >> [INFO] Scanning for projects... >> [INFO] Reactor build order: >> [INFO] Apache Maven >> [INFO] Maven Artifact >> [INFO] Maven Repository Metadata Model >> [INFO] Maven Artifact Manager >> [INFO] Maven Model >> [INFO] Maven Local Settings Model >> [INFO] Maven Artifact Test Helper Library >> [INFO] Maven Plugin API >> [INFO] Maven Plugin Descriptor Model >> [INFO] Maven Error Diagnostics >> [INFO] Maven Profile Model >> [INFO] Maven Tools >> [INFO] Maven Project Builder >> [INFO] Maven Monitor >> [INFO] Maven Plugin Registry Model >> [INFO] Maven Reporting >> [INFO] Maven Reporting API >> [INFO] Maven Plugin Parameter Documenter API >> [INFO] Maven Core >> [INFO] Maven Script Support Root >> [INFO] Maven Ant Mojo Support >> [INFO] Maven Beanshell Mojo Support >> [INFO] Maven Embedder >> [INFO] Maven Core - CLI >> [INFO] >> >> [INFO] Building Apache Maven >> [INFO]task-segment: [install] >> [INFO] >> >> [INFO] >> >> [ERROR] BUILD ERROR >> [INFO] >> >> [INFO] Error building POM (may not be this project's POM). >> >> >> Project ID: org.apache.maven.plugins:maven-site-plugin >> >> Reason: Error getting POM for >> 'org.apache.maven.plugins:maven-site-plugin' >> from the repository: Failed to resolve artifact, possibly due to a >> repository list that is not appropriately equipped for this artifact's >> metadata. >> org.apache.maven.plugins:maven-site-plugin:pom:2.0-SNAPSHOT >> >> from the specified remote repositories: >> apache.snapshots >> (http://people.apache.org/repo/m2-snapshot-repository), >> codehaus.org (http://snapshots.repository.codehaus.org), >> central (http://repo1.maven.org/maven2) >> >> >> >> [INFO] >> >> [INFO] Trace >> org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving >> version for 'org.apache.maven.plugins:maven-site-plugin': Unable to read >> the >> metadata file for artifact >> 'org.apache.maven.plugins:maven-site-plugin:pom': >> Error getting POM for 'org.apache.maven.plugins:maven-site-plugin' from >> the >> repository: Failed to resolve artifact, possibly due to a repository list >> that is not appropriately equipped for this artifact's metadata. >> org.apache.maven.plugins:maven-site-plugin:pom:2.0-SNAPSHOT >> >> from the specified remote repositories: >> apache.snapshots >> (http://people.apache.org/repo/m2-snapshot-repository), >> codehaus.org (http://snapshots.repository.codehaus.org), >> central (http://repo1.maven.org/maven2) >> >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1261) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1011) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:975) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) >> at org.apache.mav
Re: status of staging/release updates for plugins?
On 23 Dec 06, at 5:39 PM 23 Dec 06, Brett Porter wrote: On 24/12/2006, at 2:31 AM, Jason van Zyl wrote: On 22 Dec 06, at 11:18 PM 22 Dec 06, Brett Porter wrote: Hi, I was pretty confused by the state of the plugin process, and just wanted to check: - should the "remote resources" plugin be in the main configuration, rather than profiles? It makes sense for all plugin deployments to have that, and is less error prone Once I'm done testing it and there are three more releases I'll be doing this weekend. Sorry, side track - what are the 3 releases? I only recall the vote of EAR. EAR Eclipse WAR - if not, should the release plugin configure itself to add that profile? The remote resources setup should be pushed up for anyone at apache doing releases. It seems to be working from Joakim's account, for the Geronimo releases and the few that I've done so far. Yes, it worked just fine for me (that's why I thought it should just be in the main build). - what is left to do to make the staging usable? Test the copying tool which I've done for file:/// based urls. There is a bug in Wagon which prevents it from working on scp:// based urls. Joakim will look at that later. Is it in JIRA? I told Joakim, not sure if he put it in there. - is any docs started on this somewhere? It's really just setting up your profile, using it and it will be passed along in the release plugin when it picks up the active profiles: http://svn.apache.org/repos/asf/maven/release/trunk/releasing.apt Right, forgotten about that one. Need to get it over to the dev section of the site so I can find it :) The remote resources stuff works fine, the staging has only been tried once. I would stick with just using the remote resources profile with a standard release for your release and when I've tested the staging using Tom's copier I'll document that for the standard process incorporating John's release report. Using the "remoteResources" profile with what you're used to will work for your plugin release. ok - Brett - 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
On 24/12/2006, at 2:34 AM, Jason van Zyl wrote: I have a proposal for maven-artifact that I'll work on with Kenney which will complement his versioning proposal. How do I get involved? I kind of feel like this is unfinished business for me, so I'd like to participate. I have a bunch of ideas. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning
If it's backwards compatible, then there should be no problem with just replacing the current algorithm with this one in 2.1. I think the other points will certainly need to be addressed before any other maven-artifact work. Cheers, Brett On 24/12/2006, at 8:54 AM, Kenney Westerhof wrote: FYI, I've created a Wiki page under the Maven 2.1 design documents describing the proposal: http://docs.codehaus.org/display/MAVEN/Versioning FWIW,I think '1.0-alpha10' being treated as older than 1.0-alpha2 is a bug, and doesn't warrant a pom version change. The only incompatibility, aside from being able to support '1.2.3.4.betaX' and, generally, more version schemes, is the consideration of 1.0-xyz being considered newer than 1.0, which I've put up for debate. If my proposed behaviour is changed to match the current handling, I don't think a pom change is needed (so point B is not necessarily true). Point A is part of the proposal too, though I feel it's not required at all; the same goes for the version conflict resolution which should be pluggable. THough we will need to make provisions for this in a new pom model. As for point C, I agree - we should somehow be able to use different component implementations depending on the pom version specified, although this can get pretty complicated: - I say different component versions since I'd hate for the maven code to be full of conditionals depending on the pom version; - Complication in that you'll get mixed versions in the dependency tree or reactor, and some behaviours are not confined to a single pom. I'm sure you can think of some examples. I've seen that there's a section on this on the wiki, and it needs a lot of work (currently just the requirement of loading poms with modelVersion above 4.0.0 is stated, although modelVersion and maven behaviour are different things to me). What's the plan? It seems there's a ton of designing to do before we could incorporate some proposals (including mine which is basically finished and ready to go). -- Kenney Jason van Zyl wrote: On 22 Dec 06, at 5:07 PM 22 Dec 06, Brett Porter wrote: At first blush this seems good. I haven't looked in detail. We have some key things to put in place first though (not in this order). a) support for selection of alternate versioning b) since it's not backwards compatible, we need to use the old scheme for v4.0.0 POMs c) ability to read different versions of POMs. The last one is really a blocker to us doing anything in Maven 2.1 that might alter behaviour (changes to dependency handling, conflict resolution, versioning, lifecycle, ...) I have a proposal for maven-artifact that I'll work on with Kenney which will complement his versioning proposal. Jason. I still need to take a more detailed look at this, but I've switched my brain of for the holidays unfortunately :) - Brett On 19/12/2006, at 9:43 AM, Kenney Westerhof wrote: Hi, The current versioning implementation is IMHO too 'tight'. For instance, 2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', whereas this should be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1. Here's a proposal: - don't use the current 4-digit limitation, but instead list with a random amount of entries - entries are separated by dots or dashes - entries are separated by transition to/from alpha to numeric - sub-lists are indicated by '-' - entries can be either: string, integer, or sublist - versions are compared entry by entry, where we have 3 options; * integer <=> integer: normal numerical compare * integer <=> string: integers are newer * integer <=> list: integers are newer * string <=> string: if it's a qualifier, qualifier compare, else lexical compare, taking into account if either is a qualifier. * string <=> list: list is newer * list <=> list: recursion, same as a 'top-level' version compare. Where one list is shorter, '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0- alpha <=> 2.0.0 = -1 (2.0 = newer)) Now for some examples to explain the rules above: (note; i'm using the following notation:[1, 0] is a list with items 1, 0; [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter is a sublist) Version parsing: '1.0':[1, 0] '1.0.0.0.0'[1, 0, 0, 0, 0] '1.0-2.3':[1, 0, [2, 3]] '1.0-2-3':[1, 0, [2, [3]]] '1.0-alpha-1':[1, 0, ["alpha", [1]]] '1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is the current implementation (see bottom) String sorting (qualifiers) SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < '' < sp (ga = latest rc, final version '' = no qualifier, final version sp = service pack, improvement/addition on final release) usually systems either use '' or ga, not both. so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1 Comparing; 1) 1.0-SNAPSHOT <=> 1.0 [1, 0, [SNAPSHOT]] <=> [1, 0] t
Re: Feedback Needed on Release Reporting Tool
On 24/12/2006, at 2:00 AM, Jason van Zyl wrote: - build status report (for developers, from Continuum, things that need immediate attention like broken build, failing tests, failing ITs, failing checks) This report is strictly a record of something that is ready to release. Once all the work was done so that a vote can be presented with it all the pertinent information. The successful docck and verification plugin output is for completeness. Removing the manual tedium. Yes, I was adding a new report to complete the set. Not something that needs to be done, just trying to be complete. - development priorities report (for developers, information on what needs attention at any time) This is captured in other swizzle reports and can definitely be integrated into guides for developers. The plugin report that is generated daily is starting to be an accurate guide for what plugin issues people have: http://repo1.maven.org/reports/plugins/plugin-issues.txt Yes, that's what I meant. - release readiness report (for developers, information on what needs attention before a release can be cut) They really could use the release report to check themselves. Yes, we're talking about the same report here. The report John is working on is really a "release readiness" report. - changes/release report (for users, information on what was in the last release. Could also include announcement text, download links, etc). These could be integrated into the same report. I think this would be good because then we have one concise report for a release. At the point something is released all this information could be presented. I say this as I've chatted with John and this one piece of information could be attached to a release so that the record of what occurred lives on in perpetuity in the repository. The reporting API is good for outputting html right now but it's not good at aggregating information which is what this would be. It would essentially be a datasource being turned into an XML structure that could be released. Eventually you have an IDE tool that can retrieve those to browse them. Or an Archiva report to create a historical report of releases. I think it's worth having separate "user" and "developer" reports. The public don't care if docck passed, good documentation should just be a given. I think we are getting at the same thing, though, it's all just different views on the same data. I think the key differences between 2 and 3 are different handling of JIRA. An issue with 1024 votes needs to be scheduled, but it still shouldn't block a release (eg, it's a feature, and the release in question is only a point release). However, a scheduled issue for the point release will block that release and so needs to be considered. It wouldn't block the release, it would have already been moved out of the version so that the road map reflected what was being worked on for the release. I think that's what I was saying too. I think John is on the right track and that's pretty close to good enough for a first version. I agree. Was just a bit thrown by the inclusion of "votes" in the issue table, since it's not really relevant once the issue is completed. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of staging/release updates for plugins?
On 24/12/2006, at 2:31 AM, Jason van Zyl wrote: On 22 Dec 06, at 11:18 PM 22 Dec 06, Brett Porter wrote: Hi, I was pretty confused by the state of the plugin process, and just wanted to check: - should the "remote resources" plugin be in the main configuration, rather than profiles? It makes sense for all plugin deployments to have that, and is less error prone Once I'm done testing it and there are three more releases I'll be doing this weekend. Sorry, side track - what are the 3 releases? I only recall the vote of EAR. - if not, should the release plugin configure itself to add that profile? The remote resources setup should be pushed up for anyone at apache doing releases. It seems to be working from Joakim's account, for the Geronimo releases and the few that I've done so far. Yes, it worked just fine for me (that's why I thought it should just be in the main build). - what is left to do to make the staging usable? Test the copying tool which I've done for file:/// based urls. There is a bug in Wagon which prevents it from working on scp:// based urls. Joakim will look at that later. Is it in JIRA? - is any docs started on this somewhere? It's really just setting up your profile, using it and it will be passed along in the release plugin when it picks up the active profiles: http://svn.apache.org/repos/asf/maven/release/trunk/releasing.apt Right, forgotten about that one. Need to get it over to the dev section of the site so I can find it :) The remote resources stuff works fine, the staging has only been tried once. I would stick with just using the remote resources profile with a standard release for your release and when I've tested the staging using Tom's copier I'll document that for the standard process incorporating John's release report. Using the "remoteResources" profile with what you're used to will work for your plugin release. ok - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning
FYI, I've created a Wiki page under the Maven 2.1 design documents describing the proposal: http://docs.codehaus.org/display/MAVEN/Versioning FWIW,I think '1.0-alpha10' being treated as older than 1.0-alpha2 is a bug, and doesn't warrant a pom version change. The only incompatibility, aside from being able to support '1.2.3.4.betaX' and, generally, more version schemes, is the consideration of 1.0-xyz being considered newer than 1.0, which I've put up for debate. If my proposed behaviour is changed to match the current handling, I don't think a pom change is needed (so point B is not necessarily true). Point A is part of the proposal too, though I feel it's not required at all; the same goes for the version conflict resolution which should be pluggable. THough we will need to make provisions for this in a new pom model. As for point C, I agree - we should somehow be able to use different component implementations depending on the pom version specified, although this can get pretty complicated: - I say different component versions since I'd hate for the maven code to be full of conditionals depending on the pom version; - Complication in that you'll get mixed versions in the dependency tree or reactor, and some behaviours are not confined to a single pom. I'm sure you can think of some examples. I've seen that there's a section on this on the wiki, and it needs a lot of work (currently just the requirement of loading poms with modelVersion above 4.0.0 is stated, although modelVersion and maven behaviour are different things to me). What's the plan? It seems there's a ton of designing to do before we could incorporate some proposals (including mine which is basically finished and ready to go). -- Kenney Jason van Zyl wrote: On 22 Dec 06, at 5:07 PM 22 Dec 06, Brett Porter wrote: At first blush this seems good. I haven't looked in detail. We have some key things to put in place first though (not in this order). a) support for selection of alternate versioning b) since it's not backwards compatible, we need to use the old scheme for v4.0.0 POMs c) ability to read different versions of POMs. The last one is really a blocker to us doing anything in Maven 2.1 that might alter behaviour (changes to dependency handling, conflict resolution, versioning, lifecycle, ...) I have a proposal for maven-artifact that I'll work on with Kenney which will complement his versioning proposal. Jason. I still need to take a more detailed look at this, but I've switched my brain of for the holidays unfortunately :) - Brett On 19/12/2006, at 9:43 AM, Kenney Westerhof wrote: Hi, The current versioning implementation is IMHO too 'tight'. For instance, 2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', whereas this should be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1. Here's a proposal: - don't use the current 4-digit limitation, but instead list with a random amount of entries - entries are separated by dots or dashes - entries are separated by transition to/from alpha to numeric - sub-lists are indicated by '-' - entries can be either: string, integer, or sublist - versions are compared entry by entry, where we have 3 options; * integer <=> integer: normal numerical compare * integer <=> string: integers are newer * integer <=> list: integers are newer * string <=> string: if it's a qualifier, qualifier compare, else lexical compare, taking into account if either is a qualifier. * string <=> list: list is newer * list <=> list: recursion, same as a 'top-level' version compare. Where one list is shorter, '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0-alpha <=> 2.0.0 = -1 (2.0 = newer)) Now for some examples to explain the rules above: (note; i'm using the following notation:[1, 0] is a list with items 1, 0; [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter is a sublist) Version parsing: '1.0':[1, 0] '1.0.0.0.0'[1, 0, 0, 0, 0] '1.0-2.3':[1, 0, [2, 3]] '1.0-2-3':[1, 0, [2, [3]]] '1.0-alpha-1':[1, 0, ["alpha", [1]]] '1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is the current implementation (see bottom) String sorting (qualifiers) SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < '' < sp (ga = latest rc, final version '' = no qualifier, final version sp = service pack, improvement/addition on final release) usually systems either use '' or ga, not both. so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1 Comparing; 1) 1.0-SNAPSHOT <=> 1.0 [1, 0, [SNAPSHOT]] <=> [1, 0] the first 2 items are equal, the last is assumed to be 0 for the right hand, and thus is newer. 2) 1.0-beta-3<=> 1.0-alpha-4 [1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]] same here, then "beta" is newer then "alpha" so the first half wins 3) 1.0-2.3 <=> 1.0-2-3 [1, 0, [2, 3]] <=> [1, 0, [2, [3]]] first 2
Re: Removal of the Application Component
On 23 Dec 06, at 4:39 PM 23 Dec 06, Brett Porter wrote: Maybe I put the comment there and didn't realise - I thought it was yours. At the top it said to replace it with a generic converter component, which is what the other one seemed to be. It wasn't adding anything. I don't necessarily agree with the one entry point to rule them all. The first converter was at the right level of abstraction but certainly required a lot of scaffolding of repositories to use, so the converter component you added was a good way to do that. But I don't understand why it then needs to be delegated via yet another component that won't actually add anything. I meant the Archiva component itself, it only had the converter but should have everything else as well. The application entry point which should be the single place people interact with the system. We really can hide everything else. We can have oodles of components but they should be unified for reuse from one place. I'm not that committed to it, if it was meant to be there I'm happy for it to come back. Cool, I'll put it back. - Brett On 24/12/2006, at 1:37 AM, Jason van Zyl wrote: Brett, Why did you remove the application component? I was using that as a binding to another view, but at any rate why remove the entry point? It makes everyone have to deal with numerous components, having one facade decouples the innner components from someone trying to use all of Archiva's capabilities. I would like it put back. Jason.
Re: Removal of the Application Component
Maybe I put the comment there and didn't realise - I thought it was yours. At the top it said to replace it with a generic converter component, which is what the other one seemed to be. It wasn't adding anything. I don't necessarily agree with the one entry point to rule them all. The first converter was at the right level of abstraction but certainly required a lot of scaffolding of repositories to use, so the converter component you added was a good way to do that. But I don't understand why it then needs to be delegated via yet another component that won't actually add anything. I'm not that committed to it, if it was meant to be there I'm happy for it to come back. - Brett On 24/12/2006, at 1:37 AM, Jason van Zyl wrote: Brett, Why did you remove the application component? I was using that as a binding to another view, but at any rate why remove the entry point? It makes everyone have to deal with numerous components, having one facade decouples the innner components from someone trying to use all of Archiva's capabilities. I would like it put back. Jason.
Re: build maven 2.1 from repository
your better bet is to pull from http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x As that is there the next release is being worked on. it was decided to do a couple more 2.0.X releases before committing to new 2.1 features. In fact my bet is that the 2.0.x branch will be heading back to trunk at some point before 2.1 actually rears its head up. jesse On 12/23/06, shooali <[EMAIL PROTECTED]> wrote: Hi all, I am trying to build maven 2.1 from repository (from scratch) to no success. I have added the profiles to the settings.xml according to http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html but it does not help. Attached please find the error. Thanks in advance, Shooali + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache Maven [INFO] Maven Artifact [INFO] Maven Repository Metadata Model [INFO] Maven Artifact Manager [INFO] Maven Model [INFO] Maven Local Settings Model [INFO] Maven Artifact Test Helper Library [INFO] Maven Plugin API [INFO] Maven Plugin Descriptor Model [INFO] Maven Error Diagnostics [INFO] Maven Profile Model [INFO] Maven Tools [INFO] Maven Project Builder [INFO] Maven Monitor [INFO] Maven Plugin Registry Model [INFO] Maven Reporting [INFO] Maven Reporting API [INFO] Maven Plugin Parameter Documenter API [INFO] Maven Core [INFO] Maven Script Support Root [INFO] Maven Ant Mojo Support [INFO] Maven Beanshell Mojo Support [INFO] Maven Embedder [INFO] Maven Core - CLI [INFO] [INFO] Building Apache Maven [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-site-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-site-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-site-plugin:pom:2.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus.org (http://snapshots.repository.codehaus.org), central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving version for 'org.apache.maven.plugins:maven-site-plugin': Unable to read the metadata file for artifact 'org.apache.maven.plugins:maven-site-plugin:pom': Error getting POM for 'org.apache.maven.plugins:maven-site-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-site-plugin:pom:2.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus.org (http://snapshots.repository.codehaus.org), central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1261) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1011) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:975) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.class
build maven 2.1 from repository
Hi all, I am trying to build maven 2.1 from repository (from scratch) to no success. I have added the profiles to the settings.xml according to http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html but it does not help. Attached please find the error. Thanks in advance, Shooali + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache Maven [INFO] Maven Artifact [INFO] Maven Repository Metadata Model [INFO] Maven Artifact Manager [INFO] Maven Model [INFO] Maven Local Settings Model [INFO] Maven Artifact Test Helper Library [INFO] Maven Plugin API [INFO] Maven Plugin Descriptor Model [INFO] Maven Error Diagnostics [INFO] Maven Profile Model [INFO] Maven Tools [INFO] Maven Project Builder [INFO] Maven Monitor [INFO] Maven Plugin Registry Model [INFO] Maven Reporting [INFO] Maven Reporting API [INFO] Maven Plugin Parameter Documenter API [INFO] Maven Core [INFO] Maven Script Support Root [INFO] Maven Ant Mojo Support [INFO] Maven Beanshell Mojo Support [INFO] Maven Embedder [INFO] Maven Core - CLI [INFO] [INFO] Building Apache Maven [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-site-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-site-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-site-plugin:pom:2.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus.org (http://snapshots.repository.codehaus.org), central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving version for 'org.apache.maven.plugins:maven-site-plugin': Unable to read the metadata file for artifact 'org.apache.maven.plugins:maven-site-plugin:pom': Error getting POM for 'org.apache.maven.plugins:maven-site-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-site-plugin:pom:2.0-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus.org (http://snapshots.repository.codehaus.org), central (http://repo1.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1261) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1011) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:975) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:597) 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.version.PluginVersionResolutionException: Error resolving version for 'org.apache.maven.plugins:maven-site-plugin': Unable to read the metadata file for artifact 'org.apache.maven.plugins:maven-site-p
Voting
Hi, Voting for PMC members should happen here, and we have often had a sounding board for new people on projects here but the votes should be open and on the dev list. The vote going up for commit privs should be done in the open. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-plugin-plugin 2.2
+1 Stéphane On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: Please vote on maven-plugin-plugin and maven-plugin-tools-2.0.x: - svn rev. 489850 - plugin snapshot is 2.2-20061223.040931-3, plugin-tools snapshot is 2.0.5-20061223.041242-4 - documentation already updated at http://maven.apache.org/plugins/ maven-plugin-plugin/ - changelog available at http://jira.codehaus.org/browse/MPLUGIN? report=com.atlassian.jira.plugin.system.project:roadmap-panel Things of note: - this now works on Maven 2.0.4 (and earlier) - this includes the new improved plugin documentation format that we have been using for months - it now handles Java 5 - all license headers updated. - all bugs in JIRA have been reviewed and either fixed, or unscheduled for later. Vote is open for 72h [ ] +1 [ ] 0 [ ] -1 Cheers, Brett - 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
On 22 Dec 06, at 5:07 PM 22 Dec 06, Brett Porter wrote: At first blush this seems good. I haven't looked in detail. We have some key things to put in place first though (not in this order). a) support for selection of alternate versioning b) since it's not backwards compatible, we need to use the old scheme for v4.0.0 POMs c) ability to read different versions of POMs. The last one is really a blocker to us doing anything in Maven 2.1 that might alter behaviour (changes to dependency handling, conflict resolution, versioning, lifecycle, ...) I have a proposal for maven-artifact that I'll work on with Kenney which will complement his versioning proposal. Jason. I still need to take a more detailed look at this, but I've switched my brain of for the holidays unfortunately :) - Brett On 19/12/2006, at 9:43 AM, Kenney Westerhof wrote: Hi, The current versioning implementation is IMHO too 'tight'. For instance, 2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', whereas this should be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1. Here's a proposal: - don't use the current 4-digit limitation, but instead list with a random amount of entries - entries are separated by dots or dashes - entries are separated by transition to/from alpha to numeric - sub-lists are indicated by '-' - entries can be either: string, integer, or sublist - versions are compared entry by entry, where we have 3 options; * integer <=> integer: normal numerical compare * integer <=> string: integers are newer * integer <=> list: integers are newer * string <=> string: if it's a qualifier, qualifier compare, else lexical compare, taking into account if either is a qualifier. * string <=> list: list is newer * list <=> list: recursion, same as a 'top-level' version compare. Where one list is shorter, '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0- alpha <=> 2.0.0 = -1 (2.0 = newer)) Now for some examples to explain the rules above: (note; i'm using the following notation:[1, 0] is a list with items 1, 0; [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter is a sublist) Version parsing: '1.0': [1, 0] '1.0.0.0.0' [1, 0, 0, 0, 0] '1.0-2.3': [1, 0, [2, 3]] '1.0-2-3': [1, 0, [2, [3]]] '1.0-alpha-1': [1, 0, ["alpha", [1]]] '1.0alpha1': [1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is the current implementation (see bottom) String sorting (qualifiers) SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < '' < sp (ga = latest rc, final version '' = no qualifier, final version sp = service pack, improvement/addition on final release) usually systems either use '' or ga, not both. so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1 Comparing; 1) 1.0-SNAPSHOT <=> 1.0 [1, 0, [SNAPSHOT]] <=> [1, 0] the first 2 items are equal, the last is assumed to be 0 for the right hand, and thus is newer. 2) 1.0-beta-3<=> 1.0-alpha-4 [1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]] same here, then "beta" is newer then "alpha" so the first half wins 3) 1.0-2.3 <=> 1.0-2-3 [1, 0, [2, 3]] <=> [1, 0, [2, [3]]] first 2 items are the same, then this is left; [2, 3] <=> [2, [3]] first item is the same, second item: the left list wins since the right one is a sublist. So 1.0-2.3 is newer than 1.0-2-3 (which seems right: -[digit] usually indicates a maintainer update, and '.' here a bugfix version, though i doubt this will be a valid usecase). 4) 1.0-alpha-2 <=> 1.0alpha2 The current implementation parses this as: [1, 0, [alpha, [2]]] <=> [1, 0, alpha, 2] The right one is newer. If we change parsing '1.0alpha2' by using sublists on alpha<- >digit transition, both will parse as [1, 0, ["alpha", [2]]. I think this is preferrable. we may need to flatten the list or assume alpha<->digit transitions create a new sublist. So, I've given both a way to represent versions in a generic way, and an algorithm to compare versions. Replacing DefaultArtifactVersion is easy enough (see bottom), though ranges may be a bit more complicated. This scheme will support the eclipse version numbering: http:// wiki.eclipse.org/index.php/Version_Numbering (basically: major.minor.bugfix.qualifier: [major, minor, bugfix, qualifier] and Jboss: http://docs.jboss.org/process-guide/en/html/release- procedure.html, (basically: X.YY.ZZ.Q*, for instance 1.2.3.alpha4: [1, 2, 3, "alpha", 4] Maven: major.minor(.bugfix)?(-(alpha|beta|rc)-X)? which will be: [ major, minor, bugfix?, [ alpha|beta|rc, [X] ] I'll probably miss some usecases or got some things wrong, but if we do not support some sort of tag in the POM, we want to be able to accommodate versioning in a most generic way, and I think this comes close. I've created an implementation[1] and a unit test[2]. I've had to comment out one assert:
Re: status of staging/release updates for plugins?
On 22 Dec 06, at 11:18 PM 22 Dec 06, Brett Porter wrote: Hi, I was pretty confused by the state of the plugin process, and just wanted to check: - should the "remote resources" plugin be in the main configuration, rather than profiles? It makes sense for all plugin deployments to have that, and is less error prone Once I'm done testing it and there are three more releases I'll be doing this weekend. - if not, should the release plugin configure itself to add that profile? The remote resources setup should be pushed up for anyone at apache doing releases. It seems to be working from Joakim's account, for the Geronimo releases and the few that I've done so far. - what is left to do to make the staging usable? Test the copying tool which I've done for file:/// based urls. There is a bug in Wagon which prevents it from working on scp:// based urls. Joakim will look at that later. - is any docs started on this somewhere? It's really just setting up your profile, using it and it will be passed along in the release plugin when it picks up the active profiles: http://svn.apache.org/repos/asf/maven/release/trunk/releasing.apt The remote resources stuff works fine, the staging has only been tried once. I would stick with just using the remote resources profile with a standard release for your release and when I've tested the staging using Tom's copier I'll document that for the standard process incorporating John's release report. Using the "remoteResources" profile with what you're used to will work for your plugin release. Jason. Thanks, Brett - 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: Feedback Needed on Release Reporting Tool
On 22 Dec 06, at 5:13 PM 22 Dec 06, John Tolentino wrote: Here's version 2: I would still put the issues resolved on the top, I think that's what people looking at new releases want to see first. "Was my issue fixed?" is what they are asking. Jason. http://people.apache.org/~jtolentino/release-reports/MockReport2.html You can also find the corresponding xdoc here: http://people.apache.org/~jtolentino/release-reports/MockReport2.xml I didn't change the left navigation yet as we're still deciding on which reports gets linked to and which will be included within the page. On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: I see what you mean. I'll post the second version of the mock report and let's group it from there. :-) On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 23/12/2006, at 9:13 AM, John Tolentino wrote: > > > > > The vote is an indicator that we're prioritizing what the community > > needs/wants to get fixed. I think this would be of interest for those > > making a vote for the release, if the issues they want fixed will go > > in. > > > > I think these really should be two separate, but related reports. The > stable would be: > > - build status report (for developers, from Continuum, things that > need immediate attention like broken build, failing tests, failing > ITs, failing checks) > - development priorities report (for developers, information on what > needs attention at any time) > - release readiness report (for developers, information on what needs > attention before a release can be cut) > - changes/release report (for users, information on what was in the > last release. Could also include announcement text, download links, > etc). > > I think the key differences between 2 and 3 are different handling of > JIRA. An issue with 1024 votes needs to be scheduled, but it still > shouldn't block a release (eg, it's a feature, and the release in > question is only a point release). However, a scheduled issue for the > point release will block that release and so needs to be considered. > > WDYT? > > - Brett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback Needed on Release Reporting Tool
On 22 Dec 06, at 4:48 PM 22 Dec 06, Brett Porter wrote: On 23/12/2006, at 9:13 AM, John Tolentino wrote: The vote is an indicator that we're prioritizing what the community needs/wants to get fixed. I think this would be of interest for those making a vote for the release, if the issues they want fixed will go in. I think these really should be two separate, but related reports. The stable would be: - build status report (for developers, from Continuum, things that need immediate attention like broken build, failing tests, failing ITs, failing checks) This report is strictly a record of something that is ready to release. Once all the work was done so that a vote can be presented with it all the pertinent information. The successful docck and verification plugin output is for completeness. Removing the manual tedium. - development priorities report (for developers, information on what needs attention at any time) This is captured in other swizzle reports and can definitely be integrated into guides for developers. The plugin report that is generated daily is starting to be an accurate guide for what plugin issues people have: http://repo1.maven.org/reports/plugins/plugin-issues.txt - release readiness report (for developers, information on what needs attention before a release can be cut) They really could use the release report to check themselves. - changes/release report (for users, information on what was in the last release. Could also include announcement text, download links, etc). These could be integrated into the same report. I think this would be good because then we have one concise report for a release. At the point something is released all this information could be presented. I say this as I've chatted with John and this one piece of information could be attached to a release so that the record of what occurred lives on in perpetuity in the repository. The reporting API is good for outputting html right now but it's not good at aggregating information which is what this would be. It would essentially be a datasource being turned into an XML structure that could be released. Eventually you have an IDE tool that can retrieve those to browse them. Or an Archiva report to create a historical report of releases. I think the key differences between 2 and 3 are different handling of JIRA. An issue with 1024 votes needs to be scheduled, but it still shouldn't block a release (eg, it's a feature, and the release in question is only a point release). However, a scheduled issue for the point release will block that release and so needs to be considered. It wouldn't block the release, it would have already been moved out of the version so that the road map reflected what was being worked on for the release. I think John is on the right track and that's pretty close to good enough for a first version. One other interesting thing that we've chatted about is even though we are producing xdoc right now that could easily be reparsed into doxia events to produce the report in anything, so a primitive merging could be done like that but the reporting api isn't really suited for it right now. Jason. WDYT? - Brett - 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: Feedback Needed on Release Reporting Tool
On 23 Dec 06, at 2:03 AM 23 Dec 06, Stephane Nicoll wrote: Tagging the sources with a standardized scheme and use it would be the best for CVS I think. Ultimately we decide what tool is helping with the release, the API created for making releases must shape this information in a standard way so that the API works. Much like Maven SCM tries to shoehorn different concepts as best it can. Using a tag won't always work because people can modify tags. Jason. Stéphane On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: I see. So if a project is using CVS, they have to rely on their process having to tag a revision first. I used the revision on the checkout instructions in the mock reports, but like you said, this is only applicable to SVN. On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: > I don't think we can really do much special with the label - it just > needs to be something that won't change in that system (under the > assumption the user doesn't deliberately change it, we can't guard > against it). > > So, an SVN revision number is valid, but so is a URL to a tag, as is > a CVS tag, or the equivalent in another system. We can't rely on the > system having a unique repository revision (since CVS doesn't). > > - Brett > > On 23/12/2006, at 10:18 AM, John Tolentino wrote: > > > By the way, I need some help with the "labels" for the SCM. I'm not > > familiar with other SCM tools and would appreciate some suggestions on > > how to generally approach this one. > > > > On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: > >> Here's version 2: > >> > >> http://people.apache.org/~jtolentino/release-reports/ > >> MockReport2.html > >> > >> You can also find the corresponding xdoc here: > >> > >> http://people.apache.org/~jtolentino/release-reports/ > >> MockReport2.xml > >> > >> I didn't change the left navigation yet as we're still deciding on > >> which reports gets linked to and which will be included within the > >> page. > >> > >> On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: > >> > I see what you mean. I'll post the second version of the mock > >> report > >> > and let's group it from there. :-) > >> > > >> > On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: > >> > > > >> > > On 23/12/2006, at 9:13 AM, John Tolentino wrote: > >> > > > >> > > > > >> > > > The vote is an indicator that we're prioritizing what the > >> community > >> > > > needs/wants to get fixed. I think this would be of interest > >> for those > >> > > > making a vote for the release, if the issues they want fixed > >> will go > >> > > > in. > >> > > > > >> > > > >> > > I think these really should be two separate, but related > >> reports. The > >> > > stable would be: > >> > > > >> > > - build status report (for developers, from Continuum, things > >> that > >> > > need immediate attention like broken build, failing tests, > >> failing > >> > > ITs, failing checks) > >> > > - development priorities report (for developers, information > >> on what > >> > > needs attention at any time) > >> > > - release readiness report (for developers, information on > >> what needs > >> > > attention before a release can be cut) > >> > > - changes/release report (for users, information on what was > >> in the > >> > > last release. Could also include announcement text, download > >> links, > >> > > etc). > >> > > > >> > > I think the key differences between 2 and 3 are different > >> handling of > >> > > JIRA. An issue with 1024 votes needs to be scheduled, but it > >> still > >> > > shouldn't block a release (eg, it's a feature, and the release in > >> > > question is only a point release). However, a scheduled issue > >> for the > >> > > point release will block that release and so needs to be > >> considered. > >> > > > >> > > WDYT? > >> > > > >> > > - Brett > >> > > > >> > > > >> - > >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > >> > > > >> > > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Feedback Needed on Release Reporting Tool
On 22 Dec 06, at 5:28 PM 22 Dec 06, John Tolentino wrote: I see. So if a project is using CVS, they have to rely on their process having to tag a revision first. I used the revision on the checkout instructions in the mock reports, but like you said, this is only applicable to SVN. No, you can mimic with a timestamp, that's the closest you can come to the atomic revision SVN/P4 has. Jason. On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: I don't think we can really do much special with the label - it just needs to be something that won't change in that system (under the assumption the user doesn't deliberately change it, we can't guard against it). So, an SVN revision number is valid, but so is a URL to a tag, as is a CVS tag, or the equivalent in another system. We can't rely on the system having a unique repository revision (since CVS doesn't). - Brett On 23/12/2006, at 10:18 AM, John Tolentino wrote: > By the way, I need some help with the "labels" for the SCM. I'm not > familiar with other SCM tools and would appreciate some suggestions on > how to generally approach this one. > > On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: >> Here's version 2: >> >> http://people.apache.org/~jtolentino/release-reports/ >> MockReport2.html >> >> You can also find the corresponding xdoc here: >> >> http://people.apache.org/~jtolentino/release-reports/ >> MockReport2.xml >> >> I didn't change the left navigation yet as we're still deciding on >> which reports gets linked to and which will be included within the >> page. >> >> On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: >> > I see what you mean. I'll post the second version of the mock >> report >> > and let's group it from there. :-) >> > >> > On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: >> > > >> > > On 23/12/2006, at 9:13 AM, John Tolentino wrote: >> > > >> > > > >> > > > The vote is an indicator that we're prioritizing what the >> community >> > > > needs/wants to get fixed. I think this would be of interest >> for those >> > > > making a vote for the release, if the issues they want fixed >> will go >> > > > in. >> > > > >> > > >> > > I think these really should be two separate, but related >> reports. The >> > > stable would be: >> > > >> > > - build status report (for developers, from Continuum, things >> that >> > > need immediate attention like broken build, failing tests, >> failing >> > > ITs, failing checks) >> > > - development priorities report (for developers, information >> on what >> > > needs attention at any time) >> > > - release readiness report (for developers, information on >> what needs >> > > attention before a release can be cut) >> > > - changes/release report (for users, information on what was >> in the >> > > last release. Could also include announcement text, download >> links, >> > > etc). >> > > >> > > I think the key differences between 2 and 3 are different >> handling of >> > > JIRA. An issue with 1024 votes needs to be scheduled, but it >> still >> > > shouldn't block a release (eg, it's a feature, and the release in >> > > question is only a point release). However, a scheduled issue >> for the >> > > point release will block that release and so needs to be >> considered. >> > > >> > > WDYT? >> > > >> > > - Brett >> > > >> > > >> - >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> > > >> > > >> > >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 22 Dec 06, at 10:03 PM 22 Dec 06, Craig McClanahan wrote: On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > If I understand correctly, the problem is that a 'staged' release > > still contains a SNAPSHOT keyword in the metadata/filename? > > Yes, that's the problem. I would agree, but that's not how I understand staging to work at all. The Apache projects I work on like to vote on the *exact* artifacts that will be released to the public, so the staged release must not have a -SNAPSHOT qualifier. Agreed. When I vote on a release, I'm always saying "show me the bits." In this scenario, it would be nice for the release plugin to have an option to copy approved artifacts from the staging area to the release area (along with corresponding signatures and metadata updates) *without* any modification to the artifacts themselves. Yes, that's what we have just tried with a Geronimo release where the actual release was staged, Geronimo folks votes and then I merged the artifacts into the central syncing directory on Apache using Tom's new repository copier which takes into account merging the necessary metadata. Jason. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 22 Dec 06, at 9:45 PM 22 Dec 06, Wendy Smoak wrote: On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > If I understand correctly, the problem is that a 'staged' release > still contains a SNAPSHOT keyword in the metadata/filename? Yes, that's the problem. I would agree, but that's not how I understand staging to work at all. The staging directory would container artifacts as they would be released in the wild. No SNAPSHOTs, and in the form they would be merged into the central repository. Jason. The Apache projects I work on like to vote on the *exact* artifacts that will be released to the public, so the staged release must not have a -SNAPSHOT qualifier. -- 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: ApacheCon Talks
On 12/22/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
Dennis Lundberg wrote:
> Steve Loughran wrote:
>> Dennis Lundberg wrote:
>>> Jason van Zyl wrote:
On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
> Jason van Zyl wrote:
>> Hi,
>> Just checking in with folks to see if anyone is planning ApacheCon
>> talks.
>
> 1. "fear the repository police". We will pick people in the
> audience and beat them with rolled up copies of the pom schema
> until they promise not to publish invalid metadata. we will start
> off with "Is there anyone here who works on commons-logging?",
>
It will soon be impossible to publish invalid metadata.
>>>
>>> Speaking as someone who also works on commons-logging (*ducking*), is
>>> there work being done on a maven-repo-compliant-plugin or something
>>> similar that could be run on every pom that is submitted through
>>> MAVENUPLOAD? I.e. confirming to the rules set up here:
>>> http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
>>>
>>> If not, I think I could put something together.
>>
>>
>> 1. dont worry, we wouldnt do any serious public humilation in the
>> talk. Mainly through fear you'd ban all user.name=stevel &&
>> ipaddres.startswith("15.") from commons logging.
>>
>> 2. There's been lots of discussion on the repo list at automating
>> this. We need something to audit artifacts in a staging place (like
>> all stuff rsynced over), as well as do a piece-by-piece analysis of
>> submitted files. For the latter, you could do something fancy that
>> uses the Jira APis to automate pulling down the pom+JAR and auditing
>> them. A web based thing would make it easier for people to test their
>> artifacts before submission.
>
> I was thinking along the lines of a Maven plugin that people could use
> to verify that the pom they intend to upload has all the necessary bits
> and pieces.
>
+1, but you also need that code to run outside maven, so you can audit
incoming metadata of unknown provenance
+1
what matters most are the methods to interpret existing meta-data and
the rules that need to be applied. IMO we should cooperate in
developing this.
it makes sense to me to share library implementations as well (though
the pay is less than for the rules). i'd prefer to have a single set
of libraries which can be ported to whatever langauges are needed
(definitely java but perhaps python for checking staged artifacts) and
then maven, ant, ivy, RAT etc could use the libraries. collaborative
development would depend on the communities being comfortable working
together, though.
stefano has suggested that labs might be a useful forum for collaboration
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
On 12/23/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > > > > > If I understand correctly, the problem is that a 'staged' release > > > still contains a SNAPSHOT keyword in the metadata/filename? > > > > Yes, that's the problem. > > I would agree, but that's not how I understand staging to work at all. > > The Apache projects I work on like to vote on the *exact* artifacts > that will be released to the public, so the staged release must not > have a -SNAPSHOT qualifier. Agreed. When I vote on a release, I'm always saying "show me the bits." In this scenario, it would be nice for the release plugin to have an option to copy approved artifacts from the staging area to the release area (along with corresponding signatures and metadata updates) *without* any modification to the artifacts themselves. I wrote the repositorytools plugin in mojo-sandbox for this reason. It has goals to copy a specific artifact (including signatures) or an entire remote repository to another repository, while merging the necessary repository metadata. This is still work-in-progress although Jason already tested it (I think it was on a Geronimo release ). Tom -- > Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-plugin-plugin 2.2
+1 fabrizio On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: Please vote on maven-plugin-plugin and maven-plugin-tools-2.0.x: - svn rev. 489850 - plugin snapshot is 2.2-20061223.040931-3, plugin-tools snapshot is 2.0.5-20061223.041242-4 - documentation already updated at http://maven.apache.org/plugins/ maven-plugin-plugin/ - changelog available at http://jira.codehaus.org/browse/MPLUGIN? report=com.atlassian.jira.plugin.system.project:roadmap-panel Things of note: - this now works on Maven 2.0.4 (and earlier) - this includes the new improved plugin documentation format that we have been using for months - it now handles Java 5 - all license headers updated. - all bugs in JIRA have been reviewed and either fixed, or unscheduled for later. Vote is open for 72h [ ] +1 [ ] 0 [ ] -1 Cheers, Brett - 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: Feedback Needed on Release Reporting Tool
Tagging the sources with a standardized scheme and use it would be the best for CVS I think. Stéphane On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: I see. So if a project is using CVS, they have to rely on their process having to tag a revision first. I used the revision on the checkout instructions in the mock reports, but like you said, this is only applicable to SVN. On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: > I don't think we can really do much special with the label - it just > needs to be something that won't change in that system (under the > assumption the user doesn't deliberately change it, we can't guard > against it). > > So, an SVN revision number is valid, but so is a URL to a tag, as is > a CVS tag, or the equivalent in another system. We can't rely on the > system having a unique repository revision (since CVS doesn't). > > - Brett > > On 23/12/2006, at 10:18 AM, John Tolentino wrote: > > > By the way, I need some help with the "labels" for the SCM. I'm not > > familiar with other SCM tools and would appreciate some suggestions on > > how to generally approach this one. > > > > On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: > >> Here's version 2: > >> > >> http://people.apache.org/~jtolentino/release-reports/ > >> MockReport2.html > >> > >> You can also find the corresponding xdoc here: > >> > >> http://people.apache.org/~jtolentino/release-reports/ > >> MockReport2.xml > >> > >> I didn't change the left navigation yet as we're still deciding on > >> which reports gets linked to and which will be included within the > >> page. > >> > >> On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote: > >> > I see what you mean. I'll post the second version of the mock > >> report > >> > and let's group it from there. :-) > >> > > >> > On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote: > >> > > > >> > > On 23/12/2006, at 9:13 AM, John Tolentino wrote: > >> > > > >> > > > > >> > > > The vote is an indicator that we're prioritizing what the > >> community > >> > > > needs/wants to get fixed. I think this would be of interest > >> for those > >> > > > making a vote for the release, if the issues they want fixed > >> will go > >> > > > in. > >> > > > > >> > > > >> > > I think these really should be two separate, but related > >> reports. The > >> > > stable would be: > >> > > > >> > > - build status report (for developers, from Continuum, things > >> that > >> > > need immediate attention like broken build, failing tests, > >> failing > >> > > ITs, failing checks) > >> > > - development priorities report (for developers, information > >> on what > >> > > needs attention at any time) > >> > > - release readiness report (for developers, information on > >> what needs > >> > > attention before a release can be cut) > >> > > - changes/release report (for users, information on what was > >> in the > >> > > last release. Could also include announcement text, download > >> links, > >> > > etc). > >> > > > >> > > I think the key differences between 2 and 3 are different > >> handling of > >> > > JIRA. An issue with 1024 votes needs to be scheduled, but it > >> still > >> > > shouldn't block a release (eg, it's a feature, and the release in > >> > > question is only a point release). However, a scheduled issue > >> for the > >> > > point release will block that release and so needs to be > >> considered. > >> > > > >> > > WDYT? > >> > > > >> > > - Brett > >> > > > >> > > > >> - > >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > >> > > > >> > > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
