RE: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)
Hi Jason, download of SNAPSHOT dependencies does not work at all in M2.0.4: http://jira.codehaus.org/browse/MNG-1908 - Jörg Jason Dillon wrote on Saturday, October 14, 2006 10:17 PM: On Oct 14, 2006, at 6:58 AM, Kenney Westerhof wrote: Running mvn with -U -cpu should fix that (or wait 24 hours and try again :)). I don't think this helps... at least not the wait 24 hours. I was up late and was running a build at 11:50pm and it ran fine, then ran a build at 12:02am and it puked about missing versions from genesis 1.1- SNAPSHOT versions... which I had versions in my local repo that were all newer than any snap that I had deployed and I am the only one who deploys them, so no chance that it as deployed by someone else. The only way I could fix was to build genesis locally after the failed 12:02am build. But the crazy part was that I had just done that at about 11:40pm, did *not deploy* so my local copy was newer, but maven decided not to resolve to those versions?!?! I don't think using `mvn -U` helps either, as that negates the use of caching SNAPSHOTs and will slowdown the build way to much. Another solution is to delete the metadata file from the local repository. Nope... this does not work either as the problem shows up quite often when you removed you local repo and build... ie... no local metadata at all. So I don't think the problem is there. If there is a problem with the local metadata it is getting corrupted while mvn is running, so even removing the local repo cache will not ensure that the run will succeed. Btw, how come the original snapshot versions are removed from the remote repository? The local metadata file probably contains a reference to the old snapshot version, but doesn't seem to have it locally, which needs investigation.. Who said anything about removing anything? The genesis 1.1-SNAPSHOTS have not been altered ore removed from the remote repo. In the specific problem build 1 - 23 of plugin-support are all available. As for the other snapshot errors: Maven 1 legacy repositories don't contain metadata files. Updating snapshots from them doesn't seem to work. That's another thing that should be investigated. I personally never have problems with snapshot versions, so maybe the use of maven 1 repositories and the removal of snapshots from the remote repository isn't handled correctly by Maven. I know there are issues with m1 repos... not specific to snapshots... though unfortunately we can not eliminate them completely from out build because we have a few dependencies which define m1 repos in their poms. But... I think that use of m1 repos is only one of the problems going on here... something else, which I have yet to understand, is broken. One thing does look very fishy to me though snip 1) org.apache.geronimo.genesis.plugins:plugin-support:jar:1.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=plugin- support \ -Dversion=1.1-20061013.014841-21 -Dpackaging=jar -Dfile=/ path/to/file Path to dependency: 1) org.apache.geronimo.genesis.plugins:tools-maven- plugin:maven-plugin:1.1-20061013.014841-21 2) org.apache.geronimo.genesis.plugins:plugin-support:jar: 1.1-20061013.014841-21 -- 1 required artifact is missing. for artifact: org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven-plugin: 1.1-20061013.014841-21 from the specified /snip Notice that the tools-maven-plugin's timestamp-build is 20061013.014841-21 and this is also the same timestamp-build that is being used for the plugin-support jar. However the real timestamp for build 21 of plugins-support is 20061012.062745. --jason - 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]
Antwort: Re: Maven and the Apache processes...
Joakim Erdfelt [EMAIL PROTECTED] schrieb am 13.10.2006 20:06:51: === == LICENSE FILE / HEADER The LICENSE file is a unique monster in the world of apache. It will always be Apache v2.0. Thank you. But please keep in mind that maven is also used by non-apache projects which just might not like the idea to be relicensed automatically ;-) Please create the plugin in such a way that a different license can be specified easily. Also, allow to specify where it should go to in the release. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antwort: Re: Maven and the Apache processes...
[EMAIL PROTECTED] wrote on Monday, October 16, 2006 9:05 AM: Joakim Erdfelt [EMAIL PROTECTED] schrieb am 13.10.2006 20:06:51: == = == LICENSE FILE / HEADER The LICENSE file is a unique monster in the world of apache. It will always be Apache v2.0. Thank you. But please keep in mind that maven is also used by non-apache projects which just might not like the idea to be relicensed automatically ;-) Please create the plugin in such a way that a different license can be specified easily. Also, allow to specify where it should go to in the release. ... and remember that some projects are dual licensed (and some just becuase of a special request from an Apache group) ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] lifecycle design
Hi, i try what you write below but it doesn't work but i have missed something. I have my first class like this : /** * A small tutorial that shows how to create a report. * @goal generate * @phase post-site */ public class DashBoardMojo extends AbstractMojo after, i have my mojo report like this : /** * A small tutorial that shows how to create a report. * @goal dashboard */ public class DashBoardReportMojo extends DashBoardMojo implements MavenReport and at the end, i configure my report in my POM : reporting plugins ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dashboard-report-plugin1/artifactId version1.0/version /plugin ... plugins /reporting i must do another thing ? thanks for your help David Vincent Siveton wrote: Hi, Try instead of the following: public class DashBoardReportMojo extends DashBoardMojo implements MavenReport DashBoardMojo uses post-site Cheers, Vincent 2006/10/9, dvicente [EMAIL PROTECTED]: nobody can help me ? http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html dvicente wrote: Hi, How to develop a maven report plugin which can be excuted as single plugin with a specific goal and which can participate of site lifecycle during post-site phase ? As my old messages about my dashboard report plugin, i want my report to be generated as the last one or during the post-site phase if it's impossible to order the report generation. Thanks for your help David -- View this message in context: http://www.nabble.com/-m2--lifecycle-design-tf2350045.html#a6715330 Sent from the Maven Developers mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/-m2--lifecycle-design-tf2350045.html#a6832018 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] lifecycle design
Hi David, 2006/10/16, dvicente [EMAIL PROTECTED]: Hi, i try what you write below but it doesn't work but i have missed something. I have my first class like this : /** * A small tutorial that shows how to create a report. * @goal generate * @phase post-site */ public class DashBoardMojo extends AbstractMojo after, i have my mojo report like this : /** * A small tutorial that shows how to create a report. * @goal dashboard */ public class DashBoardReportMojo extends DashBoardMojo implements MavenReport try adding @phase post-site and at the end, i configure my report in my POM : reporting plugins ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dashboard-report-plugin1/artifactId version1.0/version /plugin ... plugins /reporting i must do another thing ? No All sounds good. FYI post-site goal is from the site lifecycle not the default one. I guess you need also: * @goal dashboard * @execute phase=post-site lifecycle=site Let me know. Cheers, Vincent thanks for your help David Vincent Siveton wrote: Hi, Try instead of the following: public class DashBoardReportMojo extends DashBoardMojo implements MavenReport DashBoardMojo uses post-site Cheers, Vincent 2006/10/9, dvicente [EMAIL PROTECTED]: nobody can help me ? http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html dvicente wrote: Hi, How to develop a maven report plugin which can be excuted as single plugin with a specific goal and which can participate of site lifecycle during post-site phase ? As my old messages about my dashboard report plugin, i want my report to be generated as the last one or during the post-site phase if it's impossible to order the report generation. Thanks for your help David -- View this message in context: http://www.nabble.com/-m2--lifecycle-design-tf2350045.html#a6715330 Sent from the Maven Developers mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/-m2--lifecycle-design-tf2350045.html#a6832018 Sent from the Maven Developers mailing list archive at Nabble.com. - 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: [m2] lifecycle design
i have writed in my class DashBoardReportMojo :
*/**
* A small tutorial that shows how to create a report.
* @goal dashboard
* @execute phase=post-site lifecycle=site
*/
public class DashBoardReportMojo extends DashBoardMojo implements
MavenReport {
and i have this error :
[INFO] Preparing dashboard-report1:dashboard
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Lifecycle 'site' not found in plugin
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Lifecycle 'site' not
found in plugin
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:777)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:734)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:525)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
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:324)
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)
Vincent Siveton wrote:
Hi David,
2006/10/16, dvicente [EMAIL PROTECTED]:
Hi,
i try what you write below but it doesn't work but i have missed
something.
I have my first class like this :
/**
* A small tutorial that shows how to create a report.
* @goal generate
* @phase post-site
*/
public class DashBoardMojo extends AbstractMojo
after, i have my mojo report like this :
/**
* A small tutorial that shows how to create a report.
* @goal dashboard
*/
public class DashBoardReportMojo extends DashBoardMojo implements
MavenReport
try adding @phase post-site
and at the end, i configure my report in my POM :
reporting
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dashboard-report-plugin1/artifactId
version1.0/version
/plugin
...
plugins
/reporting
i must do another thing ?
No All sounds good.
FYI post-site goal is from the site lifecycle not the default
one. I guess you need also:
* @goal dashboard
* @execute phase=post-site lifecycle=site
Let me know.
Cheers,
Vincent
thanks for your help
David
Vincent Siveton wrote:
Hi,
Try instead of the following:
public class DashBoardReportMojo
extends DashBoardMojo
implements MavenReport
DashBoardMojo uses post-site
Cheers,
Vincent
2006/10/9, dvicente [EMAIL PROTECTED]:
nobody can help me ?
http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html
http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html
dvicente wrote:
Hi,
How to develop a maven report plugin which can be excuted as single
plugin
with a specific goal and which can participate of site lifecycle
during
post-site phase ?
As my old messages about my dashboard report plugin, i want my
report
to
be generated as the last one or during the post-site phase if it's
impossible to order the report generation.
Thanks for your help
David
--
View this message in context:
http://www.nabble.com/-m2--lifecycle-design-tf2350045.html#a6715330
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
Re: Maven and the Apache processes...
Kenney Westerhof wrote: [snip - much discussion] Hm. This only describes a major release. I think that branches should be created off tags, and that a developer should do that, not a release plugin. The above process looks ok for major releases (with reservations), but we probably don't want to create a branch for each bugfix release. Say you're working on maven-2.0.x branch, currently at 2.0.5-SNAPSHOT. If we follow the above process, assuming that 'TRUNK' can also mean 'branch', we'd get a branch for 2.0.5, which will never change since there are no 2.0.5.x releases. You have to stop this recursion somewhere - otherwise you'd get 2.0.5.1.1.1.1 branches. Personally I like the following process when doing a bugfix release: 1) release:prepare: tag branch 2.0.x as 2.0.5-rc1 2) release:propose: stage 2.0.5-rc1 3) if there are -1's on the proposed release, work on 2.0.x branch (still at 2.0.5-SNAPHSHOT) and release 2.0.5-rc2, -rc3 etc, until the release is ACK'd. (so basically: work on the code, goto step 1, incrementing the rcX counter). 4) release:accept: tag 2.0.5-rcX (which should be the same as the branch) as 2.0.5, build tag 2.0.5 and deploy to the live site. Also update the 2.0.x branch's pom to 2.0.6-SNAPSHOT. 5) For a bugfix release: that's it. For a major release (say 2.1), also copy the 2.1 tag to a 2.1.x branch. (the pom's version in trunk will have been updated to 2.2-SNAPSHOT in step 4). Comments? -- Kenney I like that - automates pretty much what I try to do when releasing :) Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and the Apache processes...
I agree that promoting the actual built artifacts is the best way, but what about projects that have filtered the build number into the artifact somehow? (we use a property file that is filtered) -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Sunday, October 15, 2006 11:13 PM To: Maven Developers List Subject: Re: Maven and the Apache processes... Ya... the build would need to use the release numbers for all those bits, and only use the rc bits for the artifacts. Else, you'd have to rebuild... but by rebuilding you basically invalidate any assurance that the new build will be the same as the rc build which presumably was voted upon. So the only real option is to make a release build with the real release numbers internally, but publish the jars with their rc versions. And once approved copy the rc artifacts to the release artifacts. --jason On Oct 15, 2006, at 6:01 PM, Craig McClanahan wrote: On 10/15/06, Tom Huybrechts [EMAIL PROTECTED] wrote: Hi, just one comment: wouldn't it be better if release:accept would copy the 2.0.5-rcX artifacts to 2.0.5 (like in Joakim's proposal) instead of doing the build again ? Wouldn't all the internal version numbers in things like META-INF/MANIFEST.MF be messed up if Maven just copied and renamed the files? Tom Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and the Apache processes...
On 16 Oct 06, at 9:43 AM 16 Oct 06, Brian E. Fox wrote: I agree that promoting the actual built artifacts is the best way, but what about projects that have filtered the build number into the artifact somehow? (we use a property file that is filtered) I'm sure we could arrive at a number that identified builds that occurred during this release process. So a build number is a build number regardless of where in the process and I'm sure we could create an identifier for this process if deemed necessary. Then the builds happening during the release process could use the build number, if people are using it for something critical, but the builds happening during the release could be clearly differentiated. Jason. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Sunday, October 15, 2006 11:13 PM To: Maven Developers List Subject: Re: Maven and the Apache processes... Ya... the build would need to use the release numbers for all those bits, and only use the rc bits for the artifacts. Else, you'd have to rebuild... but by rebuilding you basically invalidate any assurance that the new build will be the same as the rc build which presumably was voted upon. So the only real option is to make a release build with the real release numbers internally, but publish the jars with their rc versions. And once approved copy the rc artifacts to the release artifacts. --jason On Oct 15, 2006, at 6:01 PM, Craig McClanahan wrote: On 10/15/06, Tom Huybrechts [EMAIL PROTECTED] wrote: Hi, just one comment: wouldn't it be better if release:accept would copy the 2.0.5-rcX artifacts to 2.0.5 (like in Joakim's proposal) instead of doing the build again ? Wouldn't all the internal version numbers in things like META-INF/MANIFEST.MF be messed up if Maven just copied and renamed the files? Tom Craig - 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: [m2] lifecycle design
I think that i have the same problem as Clover plugin as described in JIRA:
http://jira.codehaus.org/browse/MNG-2184
No ?
dvicente wrote:
i have writed in my class DashBoardReportMojo :
*/**
* A small tutorial that shows how to create a report.
* @goal dashboard
* @execute phase=post-site lifecycle=site
*/
public class DashBoardReportMojo extends DashBoardMojo implements
MavenReport {
and i have this error :
[INFO] Preparing dashboard-report1:dashboard
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Lifecycle 'site' not found in plugin
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Lifecycle 'site'
not found in plugin
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:777)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:734)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:525)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
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:324)
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)
Vincent Siveton wrote:
Hi David,
2006/10/16, dvicente [EMAIL PROTECTED]:
Hi,
i try what you write below but it doesn't work but i have missed
something.
I have my first class like this :
/**
* A small tutorial that shows how to create a report.
* @goal generate
* @phase post-site
*/
public class DashBoardMojo extends AbstractMojo
after, i have my mojo report like this :
/**
* A small tutorial that shows how to create a report.
* @goal dashboard
*/
public class DashBoardReportMojo extends DashBoardMojo implements
MavenReport
try adding @phase post-site
and at the end, i configure my report in my POM :
reporting
plugins
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dashboard-report-plugin1/artifactId
version1.0/version
/plugin
...
plugins
/reporting
i must do another thing ?
No All sounds good.
FYI post-site goal is from the site lifecycle not the default
one. I guess you need also:
* @goal dashboard
* @execute phase=post-site lifecycle=site
Let me know.
Cheers,
Vincent
thanks for your help
David
Vincent Siveton wrote:
Hi,
Try instead of the following:
public class DashBoardReportMojo
extends DashBoardMojo
implements MavenReport
DashBoardMojo uses post-site
Cheers,
Vincent
2006/10/9, dvicente [EMAIL PROTECTED]:
nobody can help me ?
http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html
http://www.nabble.com/-M2--dashboard-report-plugin-tf2342819.html
dvicente wrote:
Hi,
How to develop a maven report plugin which can be excuted as single
plugin
with a specific goal and which can participate of site lifecycle
during
post-site phase ?
As my old messages about my dashboard report plugin, i want my
report
to
be generated as the last one or during the post-site phase if it's
impossible to order the report generation.
Thanks for your help
David
--
View this message in context:
http://www.nabble.com/-m2--lifecycle-design-tf2350045.html#a6715330
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Re: [VOTE] Release maven clean plugin 2.1.1
Result: +1 evenisse, vsiveton, jerdfelt, jdcasey, Brian E. Fox Proceeding with the release On 10/12/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: +1 Emmanuel Carlos Sanchez a écrit : Last release was in February, and last change from august, can we release this? Changelog: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11128fixfor=12380 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven 2 war.bundle
Hi, If I don't want all my external dependencies bundled in the resulting war artifact, how do I configure this in my project's pom? Basically I want the functionality that was provided in Maven 1.x by adding the war.bundle property to the dependencies I do want to include in the WEB-INF/lib directory of the war maven creates. Thanks! -- View this message in context: http://www.nabble.com/maven-2-war.bundle-tf2454129.html#a684 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
contents of a 1.1 release
I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) thoughts? should we open this out to the users list maybe? jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)
Hi Jason,
Jason Dillon wrote:
I think I have tracked this down... looks like ${pom.version} is
getting resolved to a timestamp version instead of the value it its
parents version element.
Is this expected?
If my parent has 1.1-SNAPSHOT, and an intermediate module defines a
dependency using ${pom.version}, should this resolve to 1.1-SNAPSHOT
or to 1.1-timestamp-build for the current module?
What's you setting for the repo? See uniqueVersion:
http://maven.apache.org/ref/current/maven-model/maven.html#class_snapshotRepository
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)
It is the default, this element is not set on any repos. Is the
default value true? Setting to false should keep it from using
timestamp versions?
What are the implications of this change?
--jason
On Oct 16, 2006, at 11:46 AM, Jörg Schaible wrote:
Hi Jason,
Jason Dillon wrote:
I think I have tracked this down... looks like ${pom.version} is
getting resolved to a timestamp version instead of the value it its
parents version element.
Is this expected?
If my parent has 1.1-SNAPSHOT, and an intermediate module defines a
dependency using ${pom.version}, should this resolve to 1.1-SNAPSHOT
or to 1.1-timestamp-build for the current module?
What's you setting for the repo? See uniqueVersion:
http://maven.apache.org/ref/current/maven-model/
maven.html#class_snapshotRepository
- Jörg
-
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: contents of a 1.1 release
So we have ... 1) Profiles (should call this build-profile) This is a way to pre-define an environment type to execute the build under. Example of build-profile against a maven 2 java project: * Choose the JDK to run with. * Choose the Maven version to run with. Example of build-profile against a c/c++ shell project: * Choose the c compiler. * Choose the architecture output. Set up your project to execute against 1 (or more) build-profiles. Combining this effort with the G-Build functionality would mean we can a build farm of available environments / platforms and then have a single project build across all of those environments and produce a grid of success / failure for each build. Impact to user: Yes. Positive. Impact to developer: Yes. Impacts to code base: Huge. Impacts to Database Schema: Definite. 2) Refactoring for Workflows. This is an internal effort to make maintenance easier. Allows for extending the default continuum process / flows. Impact to user: No. Impact to developer: Large. Eases maintenance. Impacts to code base: Huge. Impacts to Database Schema: No. 3) Refactoring JDO Stores. Internal effort to reel in the mess that is continuum / jdo store management. Impact to user: Yes. Upgrade problematic. Ease initial configuration. Impact to developer: Large. Make contributions easier. Impacts to code base: Yes. Impacts to Database Schema: Yes. 4) Downstream Dependency Change build-trigger. If a downstream dependency has changed, but the project code in SCM has not, trigger a new build. Impact to user: Yes. Identifies potential problems before they linger too long. Impact to developer: Minor. Impacts to code base: Minor, mostly new functionality. Impacts to Database Schema: No. 5) Proactive Dependency Build. Creates a side project / build using an in-memory pom that is a copy of the project with all bleeding edge dependencies. This allows for proactive identification of potential dependency upgrade problems. Impact to user: Yes. Proactive compile helps in development of project. Impact to developer: Minor. Impacts to code base: Minor, mostly new functionality. Impacts to Database Schema: No. 6) Database Schema Tool. We really should create a tool to aide in the management of the database schema. So we can upgrade the database schema, or even create a blank schema for a new jdbc datasource. Maybe even a tool to move the data from one jdbc source to another. Impact to user: Yes. Tools are good. Impact to developer: Minor. Impacts to code base: Minor, mostly new functionality. Impacts to Database Schema: Yes. - Joakim Erdfelt Jesse McConnell wrote: I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object
RE: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)
Yes this is a known don't do that. I got burned by it recently. See
here: http://jira.codehaus.org/browse/MNG-2486
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Monday, October 16, 2006 2:27 PM
To: Maven Developers List
Cc: dev@geronimo.apache.org
Subject: Re: Maven's snapshot mechanism is horked (Re: Build error - Is
it from svn commit: r463555 -
/geronimo/genesis/trunk/config/project-config/pom.xml?)
I think I have tracked this down... looks like ${pom.version} is getting
resolved to a timestamp version instead of the value it its parents
version element.
Is this expected?
If my parent has 1.1-SNAPSHOT, and an intermediate module defines a
dependency using ${pom.version}, should this resolve to 1.1-SNAPSHOT or
to 1.1-timestamp-build for the current module?
--jason
On Oct 14, 2006, at 6:58 AM, Kenney Westerhof wrote:
The problem below seems to indicate that the local repository contains
an old metadata file.
Running mvn with -U -cpu should fix that (or wait 24 hours and try
again :)).
Another solution is to delete the metadata file from the local
repository.
Btw, how come the original snapshot versions are removed from the
remote repository?
The local metadata file probably contains a reference to the old
snapshot version, but doesn't seem to have it locally, which needs
investigation..
As for the other snapshot errors: Maven 1 legacy repositories don't
contain metadata files. Updating snapshots from them doesn't seem to
work. That's another thing that should be investigated.
I personally never have problems with snapshot versions, so maybe the
use of maven 1 repositories and the removal of snapshots from the
remote repository isn't handled correctly by Maven.
-- Kenney
Jason Dillon wrote:
Folks... maven's handling of *SNAPSHOT artifacts is killing us.
Any idea what is going on... and how we can fix this. Its an ongoing
problem, seems like new timestamp mismatch problems are popping up
quite often now. I've already removed our direct use of m1 repos to
get around some problems resolving artifacts... but something is
still very broken with maven's SNAPSHOT mechanism.
Any ideas?
--jason
Begin forwarded message:
From: Jason Dillon [EMAIL PROTECTED]
Date: October 13, 2006 2:00:50 PM PDT
To: dev@geronimo.apache.org
Cc: Jason van Zyl [EMAIL PROTECTED]
Subject: Maven's snapshot mechanism is horked (Re: Build error - Is
it from svn commit: r463555 - /geronimo/genesis/trunk/config/
project-config/pom.xml?)
Yes, build genesis locally for now to get around... I'm gonna need
to get the maven peeps to explain wtf is going on... and hopefully
fix maven to not freak out like this.
The metadata for plugin-support is correct... showing the latest
1.1-SNAPSHOT is -23:
metadata
groupIdorg.apache.geronimo.genesis.plugins/groupId
artifactIdplugin-support/artifactId
version1.1-SNAPSHOT/version
versioning
snapshot
timestamp20061013.014841/timestamp
buildNumber23/buildNumber
/snapshot
lastUpdated20061013014947/lastUpdated
/versioning
/metadata
And -23 is there:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin-
support-1.1-20061013.014841-23.jar
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin-
support-1.1-20061013.014841-23.pom
So, Maven *should* be resolving any 1.1-SNAPSHOT of plugin-config to
these files... but...
--jason
On Oct 13, 2006, at 1:50 PM, Joe Bohn wrote:
Prasad and I hit the same problem earlier today. There must be
something strange going on with the version # where 21 is
being assumed instead of the 23 that is actually in the repo.
I'm hoping that Jason will know what exactly is going on and how to
fix it and I suspect it may be related to one of his changes.
To get around the problem for now you can build genesis locally.
That worked for me.
Joe
Donald Woods wrote:
Having build problems today and wondering if the below genesis
change yesterday is causing it?
Started with a new trunk checkout directory on a SLES10 x86
machine.
Removed the existing .m2 repo.
bootstrap clean ran fine.
bootstrap specs is failing (also tried mvn -U install from
target/external/specs) because the file
version=1.1-20061013.014841-21 is not in the snapshot repo, but
version=1.1-20061013.014841-23 is.
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.genesis.plugins:plugin-support:jar:1.1-
SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -
Re: contents of a 1.1 release
I wouldn't like to push a release for more features, they can be released whenever we want as 1.2. Re backwards compatibility we should run some tool like clirr and minimize it. We absolutely need a database migration tool, and will be useful in next versions too. I've heard about ActiveMapper, a port of Ruby ActiveRecord to Java http://jroller.com/page/buggybean/20050710#activemapper_part_1_automatic_mapping On 10/16/06, Jesse McConnell [EMAIL PROTECTED] wrote: I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) thoughts? should we open this out to the users list maybe? jesse -- jesse mcconnell [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)
I think I have tracked this down... looks like ${pom.version} is
getting resolved to a timestamp version instead of the value it its
parents version element.
Is this expected?
If my parent has 1.1-SNAPSHOT, and an intermediate module defines a
dependency using ${pom.version}, should this resolve to 1.1-SNAPSHOT
or to 1.1-timestamp-build for the current module?
--jason
On Oct 14, 2006, at 6:58 AM, Kenney Westerhof wrote:
The problem below seems to indicate that the local repository
contains an old metadata file.
Running mvn with -U -cpu should fix that (or wait 24 hours and try
again :)).
Another solution is to delete the metadata file from the local
repository.
Btw, how come the original snapshot versions are removed from the
remote repository?
The local metadata file probably contains a reference to the old
snapshot version,
but doesn't seem to have it locally, which needs investigation..
As for the other snapshot errors: Maven 1 legacy repositories don't
contain metadata files. Updating snapshots from them doesn't seem
to work. That's another thing that
should be investigated.
I personally never have problems with snapshot versions, so maybe
the use of maven 1 repositories
and the removal of snapshots from the remote repository isn't
handled correctly by Maven.
-- Kenney
Jason Dillon wrote:
Folks... maven's handling of *SNAPSHOT artifacts is killing us.
Any idea what is going on... and how we can fix this. Its an
ongoing problem, seems like new timestamp mismatch problems are
popping up quite often now. I've already removed our direct use
of m1 repos to get around some problems resolving artifacts... but
something is still very broken with maven's SNAPSHOT mechanism.
Any ideas?
--jason
Begin forwarded message:
From: Jason Dillon [EMAIL PROTECTED]
Date: October 13, 2006 2:00:50 PM PDT
To: dev@geronimo.apache.org
Cc: Jason van Zyl [EMAIL PROTECTED]
Subject: Maven's snapshot mechanism is horked (Re: Build error -
Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/
project-config/pom.xml?)
Yes, build genesis locally for now to get around... I'm gonna
need to get the maven peeps to explain wtf is going on... and
hopefully fix maven to not freak out like this.
The metadata for plugin-support is correct... showing the latest
1.1-SNAPSHOT is -23:
metadata
groupIdorg.apache.geronimo.genesis.plugins/groupId
artifactIdplugin-support/artifactId
version1.1-SNAPSHOT/version
versioning
snapshot
timestamp20061013.014841/timestamp
buildNumber23/buildNumber
/snapshot
lastUpdated20061013014947/lastUpdated
/versioning
/metadata
And -23 is there:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin-
support-1.1-20061013.014841-23.jar
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin-
support-1.1-20061013.014841-23.pom
So, Maven *should* be resolving any 1.1-SNAPSHOT of plugin-config
to these files... but...
--jason
On Oct 13, 2006, at 1:50 PM, Joe Bohn wrote:
Prasad and I hit the same problem earlier today. There must be
something strange going on with the version # where 21 is
being assumed instead of the 23 that is actually in the repo.
I'm hoping that Jason will know what exactly is going on and how
to fix it and I suspect it may be related to one of his changes.
To get around the problem for now you can build genesis
locally. That worked for me.
Joe
Donald Woods wrote:
Having build problems today and wondering if the below genesis
change yesterday is causing it?
Started with a new trunk checkout directory on a SLES10 x86
machine.
Removed the existing .m2 repo.
bootstrap clean ran fine.
bootstrap specs is failing (also tried mvn -U install from
target/external/specs) because the file
version=1.1-20061013.014841-21 is not in the snapshot repo, but
version=1.1-20061013.014841-23 is.
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.geronimo.genesis.plugins:plugin-support:jar:1.1-
SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -
DgroupId=org.apache.geronimo.genesis.plugins -
DartifactId=plugin-support \
-Dversion=1.1-20061013.014841-21 -Dpackaging=jar -
Dfile=/path/to/file
Path to dependency:
1) org.apache.geronimo.genesis.plugins:tools-maven-
plugin:maven-plugin:1.1-20061013.014841-21 2)
org.apache.geronimo.genesis.plugins:plugin-support:jar:
1.1-20061013.014841-21 --
1 required artifact is missing.
for artifact:
org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven-
Re: Maven's snapshot mechanism is horked (Re: Build error - Is it from svn commit: r463555 - /geronimo/genesis/trunk/config/project-config/pom.xml?)
Holly crap... by not using ${pom.version} that means we are forced to
put all of our modules into the dependencyManagement section of our
top-level pom... which is crazy. Geronimo's server/trunk has like 130
+ modules and growing. Keeping that dependencyManagement section up
to date is going to be a maintenance nightmare... which is why we
were using version${pom.version}/version for all modules in the
project, and only using dependencyManagement for externals.
${pom.version} IMO should always resolve to the version in the
pom.xml... and no magically timestamp-build muck. If that timestamp-
build muck is needed, then a new ${pom.effectiveVersion} (or
something) should be added.
Bottom line is that in a project, the modules which are defined
within should be used... and it would be a royal PITA to have to
define 5x130 lines in the top-level pom to make that happen.
But still, I think that ${pom.version} should *always* resolve to the
version elements value, not the magically timestamp-build number.
--jason
On Oct 16, 2006, at 12:22 PM, Brian E. Fox wrote:
Yes this is a known don't do that. I got burned by it recently. See
here: http://jira.codehaus.org/browse/MNG-2486
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Monday, October 16, 2006 2:27 PM
To: Maven Developers List
Cc: dev@geronimo.apache.org
Subject: Re: Maven's snapshot mechanism is horked (Re: Build error
- Is
it from svn commit: r463555 -
/geronimo/genesis/trunk/config/project-config/pom.xml?)
I think I have tracked this down... looks like ${pom.version} is
getting
resolved to a timestamp version instead of the value it its parents
version element.
Is this expected?
If my parent has 1.1-SNAPSHOT, and an intermediate module defines a
dependency using ${pom.version}, should this resolve to 1.1-
SNAPSHOT or
to 1.1-timestamp-build for the current module?
--jason
On Oct 14, 2006, at 6:58 AM, Kenney Westerhof wrote:
The problem below seems to indicate that the local repository
contains
an old metadata file.
Running mvn with -U -cpu should fix that (or wait 24 hours and try
again :)).
Another solution is to delete the metadata file from the local
repository.
Btw, how come the original snapshot versions are removed from the
remote repository?
The local metadata file probably contains a reference to the old
snapshot version, but doesn't seem to have it locally, which needs
investigation..
As for the other snapshot errors: Maven 1 legacy repositories don't
contain metadata files. Updating snapshots from them doesn't seem to
work. That's another thing that should be investigated.
I personally never have problems with snapshot versions, so maybe the
use of maven 1 repositories and the removal of snapshots from the
remote repository isn't handled correctly by Maven.
-- Kenney
Jason Dillon wrote:
Folks... maven's handling of *SNAPSHOT artifacts is killing us.
Any idea what is going on... and how we can fix this. Its an
ongoing
problem, seems like new timestamp mismatch problems are popping up
quite often now. I've already removed our direct use of m1 repos to
get around some problems resolving artifacts... but something is
still very broken with maven's SNAPSHOT mechanism.
Any ideas?
--jason
Begin forwarded message:
From: Jason Dillon [EMAIL PROTECTED]
Date: October 13, 2006 2:00:50 PM PDT
To: dev@geronimo.apache.org
Cc: Jason van Zyl [EMAIL PROTECTED]
Subject: Maven's snapshot mechanism is horked (Re: Build error - Is
it from svn commit: r463555 - /geronimo/genesis/trunk/config/
project-config/pom.xml?)
Yes, build genesis locally for now to get around... I'm gonna need
to get the maven peeps to explain wtf is going on... and hopefully
fix maven to not freak out like this.
The metadata for plugin-support is correct... showing the latest
1.1-SNAPSHOT is -23:
metadata
groupIdorg.apache.geronimo.genesis.plugins/groupId
artifactIdplugin-support/artifactId
version1.1-SNAPSHOT/version
versioning
snapshot
timestamp20061013.014841/timestamp
buildNumber23/buildNumber
/snapshot
lastUpdated20061013014947/lastUpdated
/versioning
/metadata
And -23 is there:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin-
support-1.1-20061013.014841-23.jar
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
geronimo/genesis/plugins/plugin-support/1.1-SNAPSHOT/plugin-
support-1.1-20061013.014841-23.pom
So, Maven *should* be resolving any 1.1-SNAPSHOT of plugin-
config to
these files... but...
--jason
On Oct 13, 2006, at 1:50 PM, Joe Bohn wrote:
Prasad and I hit the same problem earlier today. There must be
something strange going on with the version # where 21 is
being assumed instead of the 23 that is actually in the repo.
I'm hoping that Jason will know what exactly is going on and
how to
fix it and I suspect it may
Re: svn commit: r464589 - /maven/plugins/trunk/maven-clean-plugin/pom.xml
[EMAIL PROTECTED] wrote: Author: carlos Date: Mon Oct 16 10:55:07 2006 New Revision: 464589 URL: http://svn.apache.org/viewvc?view=revrev=464589 Log: [maven-release-plugin] prepare for next development iteration Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-clean-plugin/pom.xml?view=diffrev=464589r1=464588r2=464589 == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Access to documentation for Wendy Smoak
sorry for the late vote, but I'm +1 as well! :-) -john On 10/15/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Wendy you now have access to the site: http://svn.apache.org/repos/asf/maven/site/trunk/ And I've sent you instructions for getting access to main Confluence Wiki. Jason. On 15 Oct 06, at 5:07 AM 15 Oct 06, Vincent Massol wrote: +1 -Vincent -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: samedi 14 octobre 2006 19:42 To: Maven Developers List Subject: [vote] Access to documentation for Wendy Smoak Hi, Wendy Smoak, from the Struts project, has kindly offered to help with our documentation. She wants to make the links to the Wiki more prominent and generally help with usability. I would like to give her access to our main Wiki and the site module so she can help without restriction. I don't think there is any downside in letting Apache committers who are using Maven to have access to our documentation. +1 Jason. __ _ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - 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: svn commit: r464589 - /maven/plugins/trunk/maven-clean-plugin/pom.xml
thanks for pointing, fixed! On 10/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: carlos Date: Mon Oct 16 10:55:07 2006 New Revision: 464589 URL: http://svn.apache.org/viewvc?view=revrev=464589 Log: [maven-release-plugin] prepare for next development iteration Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-clean-plugin/pom.xml?view=diffrev=464589r1=464588r2=464589 == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Database intialization error
Hi, I have been noticing an intialization error with database whenever the Continuum webapp restarts. And then jetty freezes after encountering that error. And it is making it hard to make any sort of even minor changes to Continuum webapp resources (working on cleaning up some CSS styles for displaying error messages here) Any one else noticing this error? (I tried inlining the logs in an email earlier but too big and apache mail server doesn't like that) Cheers, Rahul
Re: svn commit: r464589 - /maven/plugins/trunk/maven-clean-plugin/pom.xml
is it a bug in release plugin? -D On 10/16/06, Carlos Sanchez [EMAIL PROTECTED] wrote: thanks for pointing, fixed! On 10/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: carlos Date: Mon Oct 16 10:55:07 2006 New Revision: 464589 URL: http://svn.apache.org/viewvc?view=revrev=464589 Log: [maven-release-plugin] prepare for next development iteration Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-clean-plugin/pom.xml?view=diffrev=464589r1=464588r2=464589 == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r464589 - /maven/plugins/trunk/maven-clean-plugin/pom.xml
no, I changed it On 10/17/06, Dan Tran [EMAIL PROTECTED] wrote: is it a bug in release plugin? -D On 10/16/06, Carlos Sanchez [EMAIL PROTECTED] wrote: thanks for pointing, fixed! On 10/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: carlos Date: Mon Oct 16 10:55:07 2006 New Revision: 464589 URL: http://svn.apache.org/viewvc?view=revrev=464589 Log: [maven-release-plugin] prepare for next development iteration Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml Modified: maven/plugins/trunk/maven-clean-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-clean-plugin/pom.xml?view=diffrev=464589r1=464588r2=464589 == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: contents of a 1.1 release
snip I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I guess best to restructure code base now and add new features in for 1.1 than to impact a relatively larger number of users later on (assuming any breaking/incompatible changes). I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) I can commit hours over weekends and may odd hours here and there during weekdays. thoughts? should we open this out to the users list maybe? jesse Cheers, Rahul
Re: contents of a 1.1 release
I wouldn't make a feature-freeze just yet (I'm biased, as I have a feature planned that is very minimal-impact. :) but I wouldn't wnat to wait to release until the new year. I think momentum is an important thing, and the change to group handling, the ui changes, plus the rbac stuff makes continuum incrementally quite valuable. I would push hard to clean up but not dramatically refactor, focusing on stablizing, and release. Or at least stablize somewhat and release a 1.1-Alpha that's vaguely stable, but something. I think the current state (well, current feature set when tidied) solve most of my perceived deficiencies in the thing. It's tempting, but let's not do the big push until we release something. I don't think it would take too much of a detour to firm things up, before we can start hacking the model to bits (which I highly encourage). A few clean-up points: (may be in Jira, but just things I have noticed) 1. Project still depends on resources not available on public maven servers. We should through advocacy, or re-factoring to use available versions, seek to remedy that. 2. Some things like per-project build act buttons are missing 3. Adding notifiers manually is not implemented (at least in the UI) Christian. P.S. Notice I said we, which does imply my willingness to help and contribute. -cg. Jesse McConnell wrote: I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) thoughts? should we open this out to the users list maybe? jesse -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
SNAPSHOT policy (was: svn commit: r464589 - /maven/plugins/trunk/maven-clean-plugin/pom.xml)
Hi Dennis, Dennis Lundberg wrote: [snip] == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip What's wrong with this in general? We do this all the time! 2.1-SNAPSHOT means for us always the latest version from the 2.1-trunk and from time to time, we have a release, i.e. 2.1.0, 2.1.1, 2.1.2, ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SNAPSHOT policy (was: svn commit: r464589 - /maven/plugins/trunk/maven-clean-plugin/pom.xml)
On 10/16/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Dennis, Dennis Lundberg wrote: [snip] == --- maven/plugins/trunk/maven-clean-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-clean-plugin/pom.xml Mon Oct 16 10:55:07 2006 @@ -9,7 +9,7 @@ artifactIdmaven-clean-plugin/artifactId packagingmaven-plugin/packaging nameMaven Clean Plugin/name - version2.1.1/version + version2.1-SNAPSHOT/version This doesn't seem right. After version 2.1.1 comes version 2.1??? snip What's wrong with this in general? We do this all the time! 2.1-SNAPSHOT means for us always the latest version from the 2.1-trunk and from time to time, we have a release, i.e. 2.1.0, 2.1.1, 2.1.2, ... - Jörg That's not consistent with Maven's processing of the versions. Say you have version 2.1, 2.1.1, 2.1.2 and 2.1-SNAPSHOT, the order from first to last is 2.1-SNAPSHOT, 2.1, 2.1.1 and 2.1.2. Another way to look at it is that there are always 3 numeric version values, even if one is absent. For example, 2.1 and 2.1.0 are the same version. As such 2.1-SNAPSHOT is equivalent to 2.1.0-SNAPSHOT. Instead of using 2.1-SNAPSHOT for those fix versions, you should include the fix value. For example, when you release 2.1.2, the trunk version would be 2.1.3-SNAPSHOT. -Nathan
