Re: The Future of the Release Process.
On 14/12/2006, at 10:46 AM, Joakim Erdfelt wrote: * If unanimous +1 vote by 7 or more PMC members, then release can occur before 72 hour window is up. Don't really understand the rush, or the arbitrary number 7 (yes, it is the number of perfection, but other than that, it has no significance in a growing PMC of 18 and is far more than the required 3 :). A flat 3 days is far simpler, and if we are executing better on our releases it should be no real barrier. It also gives the important time for people to change their votes if someone else highlights something wrong. I'm not adverse to emergency releases either - if they are designated as such they only require the 3 PMC members to vote (though more is better, and it must be exceptional circumstances - I'd generally prefer to just pull the previous one if there was something that wrong). e) Age of development version (days since last non-snapshot release) is this necessary? I think it's a generally useful thing to know, but probably more when one is neglected, not when it is about to be released f) Downstream snapshot dependencies that might cause problems. There must be none when it comes to be voted on. It should be ready to pull the trigger. f) Tasks that have been completed in SCM but do not appear in the Jira completion list. I don't think we should encourage this. Just put it in JIRA. g) URL to jira completion report for this version. Is this needed if they have been pasted into the email? * If a change occurs to the project, the vote should be updated with the change and a new vote started. (this resets the 72 hours) This only consitutes changes that occur in the project itself, not downstream dependencies. Agreed, but the downstream dependencies changing will either not be part of the release, or cause the project to update to a new snapshot that does constitute a change, so I don't see that the statement adds anything. [snip agreed on rules] For these rules, can we incorporate the use of RAT? http:// code.google.com/p/arat/ See also stuff Commons were shopping for last time I started discussing this: * http://wiki.apache.org/jakarta-commons/ReleaseChecking * http://wiki.apache.org/jakarta-commons/ReleaseShoppingList It goes like this... a) Call vote I think this is (e) since it requires steps from b, c, c, d. BTW, I think voting on binaries + source is a Good Thing (TM), but if we expect this to be adopted widely, we need to be flexible enough to allow production of just the source tag to vote on as well. I think all this can be done via phases in the release plugin (with increased support for resuming later), and then being able to turn some on/off (or doing binding of some sort, like the build lifecycle). * Generate 'need to bless', email to mailing list about staged artifacts and site. Agree, as a template, not an automated mail. * Send email announcing (to announce@ mailing lists) the release. - Include links to artifacts on real repository. - Include changelog I think again, this should be a template to help rather than be automated. maven-release-staging-plugin (not written) This could be useful to bundle up the various other plugins into an simple goal. possible goals :prepare, :stage, :bless. This plugin could also ensure the configuration parameters needed in the settings.xml file to perform a release. Does it need a separate plugin? I think this is just an extra workflow in the main release process. You'll want to think about this in terms of how it can be triggered inside Continuum as well... maven-apache-deploy-check-plugin (not written) I think this is where RAT could come in. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Brett Porter wrote: I read through all these threads, and they kind of ran off into entirely different tracks on alternate build systems and CM. On Kenney's points in particular: On 06/12/2006, at 12:41 AM, Kenney Westerhof wrote: I'm basically -0 on adding generate-package-resources/process-package-resources since it doesn't add anything new - things done there can be done in generate-resources/process-resources. There's no need to duplicate those pases later on in the lifecycle (right?). Well, it depends on how 'resources' are defined. The definition, as defined by current behaviour, is a classpath resource (or equivalent for your given language that isn't Java). The WAR plugin already has a custom configuration webResources/, which are 'packaging resources', a different thing. We can't repurpose resources/ or change the war plugin in the ways you've suggested (disallowing classes) without a significant break in backwards compatibility (far worse than changing the lifecycle) My opinion is still that adding 'packaging resources' (or something with a better name), and the corresponding lifecycle stages (for consistency with other types of 'resources') is the best solution to the presented use cases (rather than a pre-package phase, though that'd do the trick too). WDYT? If you put it that way, then it sounds fine. Except it's not generally appliccable, only for (currently) war projects (possibly ear projects too). (Also for non-java projects, resources usually aren't classpath resources - real resources like windows .res files are linked in with the dll/exe, although that is kind of a 'classpath' resource too then). What about we just change the lifecycle for the war plugin and add phases there? -- Kenney - 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: svn commit: r484646 - in /maven/plugins/trunk/maven-gpg-plugin: ./ src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
My fix remove only a NPE when packaging is pom. Without that, the plugin tried
to sync artifact, but it doesn't exist when packaging is pom.
Emmanuel
Brett Porter a écrit :
I heard the same objection from Wendy. Can we roll this change back?
/me needs to track his objections more carefully, noting this has been
released since.
- Brett
On 09/12/2006, at 11:25 AM, Brett Porter wrote:
Why not? I think signing the metadata is just as important.
- Brett
On 09/12/2006, at 2:53 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Dec 8 07:53:20 2006
New Revision: 484646
URL: http://svn.apache.org/viewvc?view=revrev=484646
Log:
Don't generate signature on artifact when the project is a pom
Modified:
maven/plugins/trunk/maven-gpg-plugin/ (props changed)
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Propchange: maven/plugins/trunk/maven-gpg-plugin/
--
--- svn:ignore (added)
+++ svn:ignore Fri Dec 8 07:53:20 2006
@@ -0,0 +1 @@
+target
Modified:
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java?view=diffrev=484646r1=484645r2=484646
==
---
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
(original)
+++
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Fri Dec 8 07:53:20 2006
@@ -97,15 +97,18 @@
List signingBundles = new ArrayList();
-//
-// Project artifact
-//
+if ( !pom.equals( project.getPackaging() ) )
+{
+//
+// Project artifact
+//
-File projectArtifact = getProjectFile(
project.getBuild().getDirectory(), project.getBuild().getFinalName() );
+File projectArtifact = getProjectFile(
project.getBuild().getDirectory(), project.getBuild().getFinalName() );
-File projectArtifactSignature =
generateSignatureForArtifact( projectArtifact );
+File projectArtifactSignature =
generateSignatureForArtifact( projectArtifact );
-signingBundles.add( new SigningBundle(
project.getArtifact().getType(), projectArtifactSignature ) );
+signingBundles.add( new SigningBundle(
project.getArtifact().getType(), projectArtifactSignature ) );
+}
//
// POM
-
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.
Does this cover the whole topic? http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement +Documents I think it's all good - as long as it is all built on top of the stuff we already have (including what Joakim is proposing). It will probably require changes to many aspects of Maven (packaging, dependency resolution, deployment and release). It will also touch on Continuum and Archiva, I imagine. Is this right? - Brett On 14/12/2006, at 2:46 PM, Jason van Zyl wrote: Hi Dan, I think what you are describing is what you do at your work place, and I think it might be good if you could give us a full description of your system for folks here to help them understand exactly what it is you're talking about. I probably know a little more about it then most here but I still don't entirely grok the workflow you're describing. Maybe some simple examples of how artifacts names would change through the workflow you're describing versus our current approach would be helpful. Anything that makes releases easier is a good thing. Thanks, Jason. On 13 Dec 06, at 10:11 PM 13 Dec 06, Dan Fabulich wrote: Thanks for a great e-mail Joakim. I wanted to chime in with my two cents... (I've been off the radar for a couple of months while waiting for permission to sign my ICLA; it's in now, and I'm now back to paying more careful attention to this process... forgive me if some of this has already been covered.) One of the goals I know we've expressed before (but not explicitly listed here) is that Maven's release process should lead by example: other projects (whether open-source or closed-source) who haven't put as much thought into release engineering as we have should look to us as an example of the right way to do it. IMO, the requirements around SNAPSHOT releases is an important difference between open-source requirements for the release process and closed-source requirements... In this e-mail I want to describe an alternative release process (overlapping with the one Joakim described) that never uses SNAPSHOT and which is more appropriate to some organizations, perhaps especially closed-source ones. I think we all agree that it's bad (at least a little bit) to change things at the last minute before release (whether it be source code, binaries, or even your build process); one goal of the updated release process is that we should make as few last-minute changes as possible, and, to the greatest extent possible, bless binaries. But so long as you have the word SNAPSHOT embedded into your JARs during development, you'll have to change *something* at the last second, if only to remove the word SNAPSHOT. There is another way, which is better for at least some groups some of the time. If you never used SNAPSHOT, but Maven enforced a requirement that all JARs would have build numbers embedded in them (not appearing in the file name, but appearing in JAR manifest.mf and in the deployed POM), then the release process could be as little as copying the JARs into the right place and updating some metadata to call them released. Here's another way of saying the same thing. The release process Joakim described goes like this: a) Call vote b) Wait on approval. c) Collect release information. c) 'prepare' release (occurs once) d) 'stage' release (occurs 1 or more times) e) Wait on consensus from PMC for blessed artifacts. f) 'bless' release (occurs once) As this is described, it sounds as if projects would normally spend extremely little time in step D, stage. But if Maven provided more complete build numbering support for non-SNAPSHOT builds, you could imagine the project spending their entire development life in step D. After step E a decision was made to release, in step F the blessing would occur, and development would immediately begin on 1.1 in step D... no period of time spent in SNAPSHOT, so you wouldn't need to modify your code (prepare) right before release. Although I've highlighted one big advantage of not marking code under development as SNAPSHOT, the most significant disadvantage of doing it this way is that end users might confuse SNAPSHOT releases with the real official thing. (Perhaps especially if users just copy the relevant jars out of the repository and then leave Maven behind.) This can result in unnecessary support questions from users as they (unwittingly) complain about bugs in unreleased code, and can complicated support diagnostics as the person providing support may believe that the end-user has version 1.4, when they really have a developer snapshot of 1.4, never intended for release. With that said, I think most closed-source software development organizations don't have anywhere near as much fear of end-users grabbing under-development code and calling for support, since those binaries are typically kept a secret; in that case, the advantage of
svn:externals - duplicate sandbox
Hi, $ svn pg svn:externals https://svn.apache.org/repos/asf/maven/trunks archetype https://svn.apache.org/repos/asf/maven/archetype/trunk components https://svn.apache.org/repos/asf/maven/components/trunk core-integration-testing https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk maven-2.0.x https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x plugins https://svn.apache.org/repos/asf/maven/plugins/trunk continuum https://svn.apache.org/repos/asf/maven/continuum/trunk scm https://svn.apache.org/repos/asf/maven/scm/trunk site https://svn.apache.org/repos/asf/maven/site/trunk shared https://svn.apache.org/repos/asf/maven/shared/trunk skins https://svn.apache.org/repos/asf/maven/skins/trunk wagon https://svn.apache.org/repos/asf/maven/wagon/trunk surefire https://svn.apache.org/repos/asf/maven/surefire/trunk doxia https://svn.apache.org/repos/asf/maven/doxia/trunk archiva https://svn.apache.org/repos/asf/maven/archiva/trunk jxr https://svn.apache.org/repos/asf/maven/jxr/trunk pom https://svn.apache.org/repos/asf/maven/pom/trunk sandbox https://svn.apache.org/repos/asf/maven/sandbox continuum-sandbox https://svn.apache.org/repos/asf/maven/sandbox Is there a reason there are 2 externals entries for the sandbox? It's generating unneccessary repository load and traffic and I don't see how it adds anything. -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: downloading eclipse runtime binary or RCP delta pack
Thanks Graham for updates. Is there any expected time frame or maven release, which will have these features. eclipse:make-artifacts is a nice feature but it will work only if the person building and assembling the project has eclipse installed in his or her machine, which I think will not be the case as the RCP is one of the modules and not everybody will be working on it. For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. Regards, Bhupendra On 12/15/06, Graham Leggett [EMAIL PROTECTED] wrote: Bhupendra Bhardwaj wrote: The maven repository doesn't have the eclipse swt plugins for all platforms. I have few questions, can those be answered please if possible- - Can I download the eclipse runtime binary or any zip/tar from http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/. If yes, then how? I am currently in the process of trying to solve this problem. Although the latest eclipse jars are not (yet) available in a maven repository, the 2.3-SNAPSHOT maven-eclipse-plugin has a goal eclipse:make-artifacts that, given a directory containing an eclipse installation, will import all the eclipse jars into your local repository, complete with dependency information. It works very well. You can point the maven-eclipse-plugin at the deltapack, and those jars can be imported as well. - how can I assemble the RCP for different platform using maven? Is it profiles I need to use in assembling or there is some other or better way. That is my next task - the maven-pde-plugin seems the most likely solution, however I have not yet found a way to produce an eclipse RCP app for multiple platforms using this method, yet. Regards, Graham --
Re: downloading eclipse runtime binary or RCP delta pack
On Mon, December 18, 2006 11:03 am, Bhupendra Bhardwaj wrote: eclipse:make-artifacts is a nice feature but it will work only if the person building and assembling the project has eclipse installed in his or her machine, which I think will not be the case as the RCP is one of the modules and not everybody will be working on it. Not at all - we used eclipse:make-artifacts to create our own internal maven repository for eclipse. It's something you only need to do once. Previous to that we would often copy around the .m2/repository directory from developer to developer, as it was the quickest way for changes to to be propagated. For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. The eclipse jars in repo1.maven.org are over a year old, and only a small subset of the eclipse jars are available. It's far safer in the long term to create a complete and up to date repo of your own. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r484646 - in /maven/plugins/trunk/maven-gpg-plugin: ./ src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Ah, I see... sorry I misunderstood.
So - it works correctly right now? In a single pom, it signs it
normally and skips the additional signing of the non-existent
attached artifact?
If so, sorry for the noise.
- Brett
On 18/12/2006, at 7:29 PM, Emmanuel Venisse wrote:
My fix remove only a NPE when packaging is pom. Without that, the
plugin tried to sync artifact, but it doesn't exist when packaging
is pom.
Emmanuel
Brett Porter a écrit :
I heard the same objection from Wendy. Can we roll this change back?
/me needs to track his objections more carefully, noting this has
been released since.
- Brett
On 09/12/2006, at 11:25 AM, Brett Porter wrote:
Why not? I think signing the metadata is just as important.
- Brett
On 09/12/2006, at 2:53 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Dec 8 07:53:20 2006
New Revision: 484646
URL: http://svn.apache.org/viewvc?view=revrev=484646
Log:
Don't generate signature on artifact when the project is a pom
Modified:
maven/plugins/trunk/maven-gpg-plugin/ (props changed)
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/
apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Propchange: maven/plugins/trunk/maven-gpg-plugin/
---
---
--- svn:ignore (added)
+++ svn:ignore Fri Dec 8 07:53:20 2006
@@ -0,0 +1 @@
+target
Modified: maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/
apache/maven/plugin/gpg/GpgSignAttachedMojo.java
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-
plugin/src/main/java/org/apache/maven/plugin/gpg/
GpgSignAttachedMojo.java?view=diffrev=484646r1=484645r2=484646
===
===
--- maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/
apache/maven/plugin/gpg/GpgSignAttachedMojo.java (original)
+++ maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/
apache/maven/plugin/gpg/GpgSignAttachedMojo.java Fri Dec 8
07:53:20 2006
@@ -97,15 +97,18 @@
List signingBundles = new ArrayList();
-//
---
-
-// Project artifact
-//
---
-
+if ( !pom.equals( project.getPackaging() ) )
+{
+//
---
-
+// Project artifact
+//
---
-
-File projectArtifact = getProjectFile( project.getBuild
().getDirectory(), project.getBuild().getFinalName() );
+File projectArtifact = getProjectFile
( project.getBuild().getDirectory(), project.getBuild
().getFinalName() );
-File projectArtifactSignature =
generateSignatureForArtifact( projectArtifact );
+File projectArtifactSignature =
generateSignatureForArtifact( projectArtifact );
-signingBundles.add( new SigningBundle
( project.getArtifact().getType(), projectArtifactSignature ) );
+signingBundles.add( new SigningBundle
( project.getArtifact().getType(), projectArtifactSignature ) );
+}
//
---
-
// POM
-
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: svn commit: r484646 - in /maven/plugins/trunk/maven-gpg-plugin: ./ src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Brett Porter a écrit :
Ah, I see... sorry I misunderstood.
So - it works correctly right now? In a single pom, it signs it normally
and skips the additional signing of the non-existent attached artifact?
Yes.
If so, sorry for the noise.
np.
Emmanuel
- Brett
On 18/12/2006, at 7:29 PM, Emmanuel Venisse wrote:
My fix remove only a NPE when packaging is pom. Without that, the
plugin tried to sync artifact, but it doesn't exist when packaging is
pom.
Emmanuel
Brett Porter a écrit :
I heard the same objection from Wendy. Can we roll this change back?
/me needs to track his objections more carefully, noting this has
been released since.
- Brett
On 09/12/2006, at 11:25 AM, Brett Porter wrote:
Why not? I think signing the metadata is just as important.
- Brett
On 09/12/2006, at 2:53 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Fri Dec 8 07:53:20 2006
New Revision: 484646
URL: http://svn.apache.org/viewvc?view=revrev=484646
Log:
Don't generate signature on artifact when the project is a pom
Modified:
maven/plugins/trunk/maven-gpg-plugin/ (props changed)
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Propchange: maven/plugins/trunk/maven-gpg-plugin/
--
--- svn:ignore (added)
+++ svn:ignore Fri Dec 8 07:53:20 2006
@@ -0,0 +1 @@
+target
Modified:
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java?view=diffrev=484646r1=484645r2=484646
==
---
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
(original)
+++
maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/GpgSignAttachedMojo.java
Fri Dec 8 07:53:20 2006
@@ -97,15 +97,18 @@
List signingBundles = new ArrayList();
-//
-// Project artifact
-//
+if ( !pom.equals( project.getPackaging() ) )
+{
+//
+// Project artifact
+//
-File projectArtifact = getProjectFile(
project.getBuild().getDirectory(),
project.getBuild().getFinalName() );
+File projectArtifact = getProjectFile(
project.getBuild().getDirectory(),
project.getBuild().getFinalName() );
-File projectArtifactSignature =
generateSignatureForArtifact( projectArtifact );
+File projectArtifactSignature =
generateSignatureForArtifact( projectArtifact );
-signingBundles.add( new SigningBundle(
project.getArtifact().getType(), projectArtifactSignature ) );
+signingBundles.add( new SigningBundle(
project.getArtifact().getType(), projectArtifactSignature ) );
+}
//
// POM
-
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: [m2] New pre-package phase?
On 18/12/2006, at 7:02 PM, Kenney Westerhof wrote: If you put it that way, then it sounds fine. Except it's not generally appliccable, only for (currently) war projects (possibly ear projects too). (Also for non-java projects, resources usually aren't classpath resources - real resources like windows .res files are linked in with the dll/exe, although that is kind of a 'classpath' resource too then). Yeah, I know what you mean. It's really a relic of being ill-defined in the past so we have to stick with the current behaviour (where things like properties files wind up in the right place to be picked up as bundles, etc). What about we just change the lifecycle for the war plugin and add phases there? I think redefining the lifecycle for a packaging would be uglier (and I don't think we actually support that in the current implementation - would need to check). Aside from that, there is use for the concept for other packagings (eg, the assembly plugin). I guess, the question is whether we generalise a concept that may or may not have uses outside the war plugin (ie, pushing webResources up to POM level and adding the extra phases for them), or whether we address the use case with a pre-package phase. I'd be happy with either. I think if we have any use cases beyond the war plugin we should do the first, otherwise the second (as it is far simpler). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r482742 - in /maven/continuum/trunk/continuum-webapp/src/main/webapp: WEB-INF/jsp/navigations/DefaultTop.jsp css/tigris.css
On 06/12/2006, at 7:44 PM, Emmanuel Venisse wrote: I'd like to use the same css for all our web parts but I don't know if I'll found the time to do it. If we move to the standard xhtml template, will we keep the actual continuum page style? Yes, it should look identical. I think the one area we need to work on more consistency is tables in the CSS, but that one could be applied back to the application-skin and used in all apps. I think it would be good to create a shared module that include the header, footer, breadcrumb and css, so we'll define them at one place and we'll have consistency between our webapps. The css and images can come from the application-skin. I think the header, footer and breadcrumbs are necessarily different between apps though? - Brett
Maven properties evaluation
Hi, It looks like properties and map, as component, are not evaluated in the same way in Maven. I am setting a MavenProject.property in a Mojo to use it in another one in another phase. If I use a Map to pass this value (a String) all is correct but if I use a Properties the property is not evaluated. To add more to my confusion, if I use a Maven property (like basedir) it is correctly evaluated. I am quite at lost here. I have posted a JIRA on this subject on SURFIRE (http://jira.codehaus.org/browse/SUREFIRE-60) where I found this problem but to me this looks like a Maven or Plexus issue. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r482742 - in /maven/continuum/trunk/continuum-webapp/src/main/webapp: WEB-INF/jsp/navigations/DefaultTop.jsp css/tigris.css
Brett Porter a écrit : On 06/12/2006, at 7:44 PM, Emmanuel Venisse wrote: I'd like to use the same css for all our web parts but I don't know if I'll found the time to do it. If we move to the standard xhtml template, will we keep the actual continuum page style? Yes, it should look identical. I think the one area we need to work on more consistency is tables in the CSS, but that one could be applied back to the application-skin and used in all apps. I think it would be good to create a shared module that include the header, footer, breadcrumb and css, so we'll define them at one place and we'll have consistency between our webapps. The css and images can come from the application-skin. I think the header, footer and breadcrumbs are necessarily different between apps though? The header can be shared too, just need to have a parameter for the app logo The footer can be shared too, just need to have a parameter for the inception year The breadcrumbs can be shared too, just need to allow additional links from the app. Emmanuel
Re: svn commit: r480817 - in /maven/archiva/trunk: archiva-indexer/src/main/java/org/apache/maven/archiva/indexer/record/ archiva-reports-standard/src/main/java/org/apache/maven/archiva/reporting/ arc
Still looking for an answer on this. I keep getting told I did it wrong, but not why :) I'm also keen to avoid catching exceptions that indicate programming errors and address the cause. - Brett On 01/12/2006, at 6:55 AM, Brett Porter wrote: Like I said, a programming error. It's a bug in the discovery if it reports back something that doesn't exist, right? On 01/12/2006, at 12:02 AM, Joakim Erdfelt wrote: The fact that we tie together the discovery, indexing, and reporting is how. We shouldn't have done that. Why not? What alternate solution do you propose? - Brett
Re: continuum-webapp models
Wasn't sure how certain we were about deleting these, so just raised an issue (CONTINUUM-1063). On 14/12/2006, at 10:34 AM, Jesse McConnell wrote: no, brett' OP was asking if we could axe some of the unused stuff thats all On 12/13/06, Rahul Thakur [EMAIL PROTECTED] wrote: Hi Jesse, Just trying to understand - why do you suggest we drop the view data model (earlier email) if we could? Were you hinting that we use the domain entities directly in the view? I think we should keep separate model for the view data that only exposes that required stuff for view preparation. Rahul Jesse McConnell wrote: yes, the output in the tables wanted certain summaries of data and project group and projects bits like name, group, etc.. so those were just model pojo's for ec:table to consume jesse On 12/13/06, Rahul Thakur [EMAIL PROTECTED] wrote: I haven't looked at this but is this purely as like a 'view data' for preparing views for the webapp? Cheers, Rahul Brett Porter wrote: anyone? On 01/12/2006, at 11:29 AM, Brett Porter wrote: I see a couple of models in continuum-webapp, which seem to be partially used. Does anyone know if session-models is used any more? What about view-models - only the summary parts still seem valid? - Brett -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r484649 - /maven/scm/trunk/pom.xml
Are these tested enough to put in the right home now? (I assume we weren't debating the correct place to put them, just the timing of it). On 09/12/2006, at 3:23 PM, Jason van Zyl wrote: On 8 Dec 06, at 7:25 PM 8 Dec 06, Brett Porter wrote: Shouldn't these be in the release profile so they are activated automatically? Not until they are tested a few times. I will do a series of releases with them and Emm is doing the same. Jason.
Re: svn:externals - duplicate sandbox
The continuum sandbox is actually a different thing. My bad - fixed. - Brett On 18/12/2006, at 7:47 PM, Kenney Westerhof wrote: Hi, $ svn pg svn:externals https://svn.apache.org/repos/asf/maven/trunks archetype https://svn.apache.org/repos/asf/ maven/archetype/trunk components https://svn.apache.org/repos/asf/ maven/components/trunk core-integration-testinghttps://svn.apache.org/repos/asf/ maven/core-integration-testing/trunk maven-2.0.x https://svn.apache.org/repos/asf/ maven/components/branches/maven-2.0.x plugins https://svn.apache.org/repos/asf/ maven/plugins/trunk continuum https://svn.apache.org/repos/asf/ maven/continuum/trunk scm https://svn.apache.org/repos/asf/ maven/scm/trunk sitehttps://svn.apache.org/repos/asf/ maven/site/trunk shared https://svn.apache.org/repos/asf/ maven/shared/trunk skins https://svn.apache.org/repos/asf/ maven/skins/trunk wagon https://svn.apache.org/repos/asf/ maven/wagon/trunk surefirehttps://svn.apache.org/repos/asf/ maven/surefire/trunk doxia https://svn.apache.org/repos/asf/ maven/doxia/trunk archiva https://svn.apache.org/repos/asf/ maven/archiva/trunk jxr https://svn.apache.org/repos/asf/ maven/jxr/trunk pom https://svn.apache.org/repos/asf/ maven/pom/trunk sandbox https://svn.apache.org/repos/asf/ maven/sandbox continuum-sandbox https://svn.apache.org/repos/asf/ maven/sandbox Is there a reason there are 2 externals entries for the sandbox? It's generating unneccessary repository load and traffic and I don't see how it adds anything. -- Kenney - 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] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
Hello, The releases of your companies artifacts can't use snapshot versions and internally patched versions of the plugins needs to be made available to all developers. I solved these issues by writing my own proxy which can rewrite URLs (so even if someone configures Maven to download something from Xyz.com, it will still go to Sateh, no matter what). Plus I can blind maven (return 404 for any URL I like). This way, I can make a beta of the site plugin (which contains vital bug fixes for me) available to all developers but maven will not be able to download the snapshots of the source or compiler plugin. As a last resort, the proxy will look into a patches tree for files. The search order is: patches, allow/deny rules, rewrite rules. This allows me to fix any bugs by using my own patches, let maven see what it should (and nothing else) and force all external connections to one single maven repository. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integration Testing
Jason: Here! here! I recently joined the AppFuse bunch and being more the builder, packager, deployer-type, I'm working on AppFuse2 and the use of the archetype. Since, I've been on a large state project for Massachusetts, we have not used Maven, so my knowledge of Maven has been some small use of Maven1. I'm am so disappointed in my inability to just further or push the work on the AppFuse archetype. It's bad for me personally because I'm a senior level type but I can't just make good progress because I'm always having some trouble determining *what* I'm supposed to do to get things to work. AppFuse is difficult but Maven's even more difficult because I don't know where the knowledge home is for every plugin, mojo, etc. I don't know *how* I'm supposed to do things. It seems that Maven and the Plugin World needs a roadmap and some throttling of what gets created and what becomes public domain. Thanks Jason for your work behind a great development tool and your work in trying to slow things down. David On 12/11/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, This is in response to John's email about integration testing, some notes that I've taken while trying to clean up the integration testing, and some suggestions about where we go from here with respect to integration testing. You will see from the list below that there are many problems with the ITs ranging from integration tests for specific plugins being in there to using production dependencies, to having tons of duplicated for doing ITs. So, in response to John's email: I think we need to settle on what we're going to use and stop writing new tools. We have several invokers, several verifiers, several IT plugins, and the plugin harness. It is simply out of control. We have different methods being used in different plugins, nothing is standard and it's going to kill us. The most prevalent tool, as defective as it might be is what is being used in the ITs themselves. Stephane managed to use this successfully in some of his plugins. Then after that we have an array of usages. What should happen before we start writing more stuff is to figure out something we can use now, and how to merge what we have together instead of writing more tools. This is just to get the discussion started. I will take a first pass at enumerating the collection of tools we have and where they are used. But here are my notes from the main core ITs. Thus far as some of the ideas pertain to ITs in general like not polluting the local repo when testing .. Jason. --- - [-] Goals - [ ] An IT should be completely self-contained so that the problem can be understood by looking in one place, in one Maven project. - [ ] We should be able to create an Archetype so that users can easily create ITs for us - [+] The ITs should be in a project of their own so that we can reuse them across versions of Maven. We could actually run new versions of integration tests against old versions of Maven. Solution: the ITs are now in a separate build and it is possible to run them - [ ] We should be able to easily integrate the IT into a larger run where we can use forked or embedded execution. - [ ] We should create Archetypes for all categories of problems so that anyone can generate tests cases for us. Then there is so much that we can do in terms of automating this process of checking tests for quality along with the patches. - [ ] automate the testing of ITs submitted by users - [ ] Each IT should have its own repository if it needs resources from repository. We can't mess with a users repository when testing. - [ ] We need to have a file system based remote repository for testing - [ ] We need to standardize on integration testing in general. We have people going all over the place and it's a disaster. - [ ] We have too many IT plugins (3) - [ ] We have too many invokers (5) - [ ] We have too many verifiers (3) - [ ] The ITs should run nicely from an IDE. Solution: this does work but requires that you run mvn clean resources:testResources first as the IDE doesn't know how to set that up. Needs to be fully fixed. But it is much nicer running this stuff in your IDE. - [-] Problems with ITs - [+] Verifier jar required by the bootstrap requires a special verifier.jar there is no released version of this tool. Solution: the bootstrap now uses Ant and we've gotten rid of a lot of the complexity. - [+] The maven-core-it plugin needs to be decoupled into its separate purposes because there are currently 12 different things going on in the plugin and it would be really confusing for a new user to figure out what's going on in the
Re: [m2] New pre-package phase?
Hello, What about we just change the lifecycle for the war plugin and add phases there? Because the same problem crops up time and time again which means the current solution is part of the problem. Imagine. I'm generating a database for my tests from XML descriptions. The intended control flow should be: - Copy resources (fill in DB connection details from some existing file) - Copy resources (convert model specific XML into XML to SQL tool specific XML) - Copy resources (turn the XML into SQL) - Copy resources (load DB with SQL) - Copy resources (classpath resources for tests) - Run the tests How can I make sure in my mojo that the many copy resources are executed in the right order? The idea of lifecycle is good but only as a big framework in which you can plug other things and you need a way to specify dependencies between the other things, too. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: downloading eclipse runtime binary or RCP delta pack
Graham, On Monday 18 December 2006 04:26, Graham Leggett wrote: For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. The eclipse jars in repo1.maven.org are over a year old, and only a small subset of the eclipse jars are available. It's far safer in the long term to create a complete and up to date repo of your own. The problem is that the project Bhupendra is talking about is an open source project with developers from SEVERAL companies scattered all over the place, several of which don't have their own internal maven repositories setup. Thus, requiring this basically would require each developer to do this themselves which the whole point of maven's dependency management stuff was to avoid all that. My can't someone on the Maven team run the plugin/script and put them up on repo1 someplace? That's what I'm having a hard time understanding. People obviously want them published, what stopping them from being published? -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Integration Testing
On 18 Dec 06, at 9:18 AM 18 Dec 06, David Whitehurst wrote: Jason: Here! here! I recently joined the AppFuse bunch and being more the builder, packager, deployer-type, I'm working on AppFuse2 and the use of the archetype. Since, I've been on a large state project for Massachusetts, we have not used Maven, so my knowledge of Maven has been some small use of Maven1. I'm am so disappointed in my inability to just further or push the work on the AppFuse archetype. It's bad for me personally because I'm a senior level type but I can't just make good progress because I'm always having some trouble determining *what* I'm supposed to do to get things to work. AppFuse is difficult but Maven's even more difficult because I don't know where the knowledge home is for every plugin, mojo, etc. I don't know *how* I'm supposed to do things. It seems that Maven and the Plugin World needs a roadmap and some throttling of what gets created and what becomes public domain. Thanks Jason for your work behind a great development tool and your work in trying to slow things down. I try my best. http://www.amazon.com/Praise-Slowness-Worldwide-Movement-Challenging/ dp/006054578X Jason. David On 12/11/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, This is in response to John's email about integration testing, some notes that I've taken while trying to clean up the integration testing, and some suggestions about where we go from here with respect to integration testing. You will see from the list below that there are many problems with the ITs ranging from integration tests for specific plugins being in there to using production dependencies, to having tons of duplicated for doing ITs. So, in response to John's email: I think we need to settle on what we're going to use and stop writing new tools. We have several invokers, several verifiers, several IT plugins, and the plugin harness. It is simply out of control. We have different methods being used in different plugins, nothing is standard and it's going to kill us. The most prevalent tool, as defective as it might be is what is being used in the ITs themselves. Stephane managed to use this successfully in some of his plugins. Then after that we have an array of usages. What should happen before we start writing more stuff is to figure out something we can use now, and how to merge what we have together instead of writing more tools. This is just to get the discussion started. I will take a first pass at enumerating the collection of tools we have and where they are used. But here are my notes from the main core ITs. Thus far as some of the ideas pertain to ITs in general like not polluting the local repo when testing .. Jason. --- - [-] Goals - [ ] An IT should be completely self-contained so that the problem can be understood by looking in one place, in one Maven project. - [ ] We should be able to create an Archetype so that users can easily create ITs for us - [+] The ITs should be in a project of their own so that we can reuse them across versions of Maven. We could actually run new versions of integration tests against old versions of Maven. Solution: the ITs are now in a separate build and it is possible to run them - [ ] We should be able to easily integrate the IT into a larger run where we can use forked or embedded execution. - [ ] We should create Archetypes for all categories of problems so that anyone can generate tests cases for us. Then there is so much that we can do in terms of automating this process of checking tests for quality along with the patches. - [ ] automate the testing of ITs submitted by users - [ ] Each IT should have its own repository if it needs resources from repository. We can't mess with a users repository when testing. - [ ] We need to have a file system based remote repository for testing - [ ] We need to standardize on integration testing in general. We have people going all over the place and it's a disaster. - [ ] We have too many IT plugins (3) - [ ] We have too many invokers (5) - [ ] We have too many verifiers (3) - [ ] The ITs should run nicely from an IDE. Solution: this does work but requires that you run mvn clean resources:testResources first as the IDE doesn't know how to set that up. Needs to be fully fixed. But it is much nicer running this stuff in your IDE. - [-] Problems with ITs - [+] Verifier jar required by the bootstrap requires a special verifier.jar there is no released version of this tool. Solution: the bootstrap now uses Ant and we've gotten rid of a lot of the complexity. - [+] The maven-core-it plugin needs to be
Re: downloading eclipse runtime binary or RCP delta pack
On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote: Graham, On Monday 18 December 2006 04:26, Graham Leggett wrote: For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. The eclipse jars in repo1.maven.org are over a year old, and only a small subset of the eclipse jars are available. It's far safer in the long term to create a complete and up to date repo of your own. The problem is that the project Bhupendra is talking about is an open source project with developers from SEVERAL companies scattered all over the place, several of which don't have their own internal maven repositories setup. Thus, requiring this basically would require each developer to do this themselves which the whole point of maven's dependency management stuff was to avoid all that. My can't someone on the Maven team run the plugin/script and put them up on repo1 someplace? That's what I'm having a hard time understanding. People obviously want them published, what stopping them from being published? Seems like a good idea to me. Jason. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [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: svn commit: r484649 - /maven/scm/trunk/pom.xml
On 18 Dec 06, at 6:15 AM 18 Dec 06, Brett Porter wrote: Are these tested enough to put in the right home now? (I assume we weren't debating the correct place to put them, just the timing of it). No I'm going to do more tests with them all work and then I'll put it somewhere for everyone to use. Once the documentation is done as well. Jason. On 09/12/2006, at 3:23 PM, Jason van Zyl wrote: On 8 Dec 06, at 7:25 PM 8 Dec 06, Brett Porter wrote: Shouldn't these be in the release profile so they are activated automatically? Not until they are tested a few times. I will do a series of releases with them and Emm is doing the same. Jason.
Re: downloading eclipse runtime binary or RCP delta pack
On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote: Graham, On Monday 18 December 2006 04:26, Graham Leggett wrote: For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. The eclipse jars in repo1.maven.org are over a year old, and only a small subset of the eclipse jars are available. It's far safer in the long term to create a complete and up to date repo of your own. The problem is that the project Bhupendra is talking about is an open source project with developers from SEVERAL companies scattered all over the place, several of which don't have their own internal maven repositories setup. Thus, requiring this basically would require each developer to do this themselves which the whole point of maven's dependency management stuff was to avoid all that. My can't someone on the Maven team run the plugin/script and put them up on repo1 someplace? That's what I'm having a hard time understanding. People obviously want them published, what stopping them from being published? Seems like a good idea to me. Jason. We'd better have the POMs right the first time with regards to dependencies, because they cannot be updated. Tom -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [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]
maven 2 artifact resolution
Hi, i have to resolve the last version of an artifact given. For example, i want to know which is the last version of log4j in my repository by a maven plugin. Is there any component that resolve it? -- Lic Matias Urbieta
Re: Maven properties evaluation
zze- HUGONNET E ext RD-BIZZ a écrit : Hi, It looks like properties and map, as component, are not evaluated in the same way in Maven. I am setting a MavenProject.property in a Mojo to use it in another one in another phase. If I use a Map to pass this value (a String) all is correct but if I use a Properties the property is not evaluated. To add more to my confusion, if I use a Maven property (like basedir) it is correctly evaluated. I am quite at lost here. I have posted a JIRA on this subject on SURFIRE (http://jira.codehaus.org/browse/SUREFIRE-60) where I found this problem but to me this looks like a Maven or Plexus issue. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This is a duplicate of http://jira.codehaus.org/browse/MNG-2201. Sorry for the inconvenience. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: downloading eclipse runtime binary or RCP delta pack
On 18 Dec 06, at 10:23 AM 18 Dec 06, Tom Huybrechts wrote: On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote: Graham, On Monday 18 December 2006 04:26, Graham Leggett wrote: For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. The eclipse jars in repo1.maven.org are over a year old, and only a small subset of the eclipse jars are available. It's far safer in the long term to create a complete and up to date repo of your own. The problem is that the project Bhupendra is talking about is an open source project with developers from SEVERAL companies scattered all over the place, several of which don't have their own internal maven repositories setup. Thus, requiring this basically would require each developer to do this themselves which the whole point of maven's dependency management stuff was to avoid all that. My can't someone on the Maven team run the plugin/script and put them up on repo1 someplace? That's what I'm having a hard time understanding. People obviously want them published, what stopping them from being published? Seems like a good idea to me. Jason. We'd better have the POMs right the first time with regards to dependencies, because they cannot be updated. We can put them in a staging repository for people to use for a while and let people evaluate them. Fix over the course of a few weeks and let release them into the wild. Jason. Tom -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [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: downloading eclipse runtime binary or RCP delta pack
On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Dec 06, at 10:23 AM 18 Dec 06, Tom Huybrechts wrote: On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote: Graham, On Monday 18 December 2006 04:26, Graham Leggett wrote: For compilation purpose the win32 eclipse jars are availabe in maven ( repo1.maven.org), so compilation is not a problem. The eclipse jars in repo1.maven.org are over a year old, and only a small subset of the eclipse jars are available. It's far safer in the long term to create a complete and up to date repo of your own. The problem is that the project Bhupendra is talking about is an open source project with developers from SEVERAL companies scattered all over the place, several of which don't have their own internal maven repositories setup. Thus, requiring this basically would require each developer to do this themselves which the whole point of maven's dependency management stuff was to avoid all that. My can't someone on the Maven team run the plugin/script and put them up on repo1 someplace? That's what I'm having a hard time understanding. People obviously want them published, what stopping them from being published? Seems like a good idea to me. Jason. We'd better have the POMs right the first time with regards to dependencies, because they cannot be updated. We can put them in a staging repository for people to use for a while and let people evaluate them. Fix over the course of a few weeks and let release them into the wild. Jason. They have been in http://repo1.maven.org/eclipse for a while Tom -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [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: downloading eclipse runtime binary or RCP delta pack
On Mon, December 18, 2006 4:59 pm, Daniel Kulp wrote: My can't someone on the Maven team run the plugin/script and put them up on repo1 someplace? That's what I'm having a hard time understanding. People obviously want them published, what stopping them from being published? The problem I saw posted recently about this was that once published, the repository is cast in stone, including errors. If this was published in a separate repository, with proper caveats advertised (this is beta, this might change in future, whatever), this would fix this problem. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resolve last version of an artifact inside a plugin
Hi, i have resolve which is the last versión of a local artifact inside a plugin. is there any component that resolves it? -- Lic Matias Urbieta
Re: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
On 12/18/06, Brett Porter [EMAIL PROTECTED] wrote: Sorry to top reply, but my summarised response is: - there are valid use cases for plugins in more than one repository - Maven should always be using the repository with the newest version available. If it's not, then it's a bug. If you are using a version the last release, and the snapshot version then it should work out just fine (though I also recommend not using snapshot plugin repositories at all in this case). The gotcha might be that 1.2-INTERNAL is evaluated as 1.2 (and 1.2- SNAPSHOT) - is that the issue? What about hardcoding the plugin version in your POM? The gotcha is that the metadata merging of multiple repositories is when the artifact's repository value is set. In the next step when version resolution occurs the incorrect artifact repository value is used. Therefore Metadata merging must include the repository in the versioning information. I think I can patch it to do so, but its a large enough change that I am uncomfortable with the potential changes this will cause. If I can 1) work out a way to have multiple versions of maven installed on my machine so I can switch between them for independent development that would be tops. I need separate mvn binaries and repositories (I assume maven devs have this exact problem, how do they solve it?) 2) work out how to create appropriate unit tests to expose the problem prior to development. This may be more difficult due to the component nature of how this gets resolved. However, since I have a workaround using mvnproxy, this is going down my priority list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
versioning
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 versionScheme 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: 2.0.1-xyz 2.0.1. I think generally this is not the case. For example, the wiki guide to patching plugins states that you could patch a plugin and change it's version to 2.0-INTERNAL. In this case, 2.0 would be newer than 2.0-INTERNAL, which renders the wiki description invalid. In my sample implementation, 2.0.1-xyz is newer than 2.0.1. Though should this be required, the code is easily modified to reflect this. So, WDYT? Any additional version schemes that cannot be handled by this? If this looks ok, then my next challenge will be to support ranges. ;) [1] http://www.neonics.com/~forge/GenericArtifactVersion.java - put in maven-artifact/src/main/java/.../versioning/ Note: this one doesn't implement ArtifactVersion since we never know what the major/minor versions etc. will be. It could implement it and default to 0 if the item isn't an integer; [2] http://www.neonics.com/~forge/GenericArtifactVersionTest.java - put in
Re: versioning
I've had to comment out one assert: 2.0.1-xyz 2.0.1. I think generally this is not the case. For example, the wiki guide to patching plugins states that you could patch a plugin and change it's version to 2.0-INTERNAL. In this case, 2.0 would be newer than 2.0-INTERNAL, which renders the wiki description invalid. In my sample implementation, 2.0.1-xyz is newer than 2.0.1. To quote BBWM page 60: It is intended that the qualifier indicates a version prior to release thus 2.0.1-xyz 2.0.1 is correct. The -INTERNAL was always meant to be a qualifier. Thus: 2.0-SNAPSHOT 2.0-INTERNAL 2.0 The wiki page was attempting to create an internal release of a snapshot and it should be obsoleted by an official release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning
- 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)) The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are bit beyond how I would use things so I can't really comment. However I would expect a project to be self consistent so it doesn't really matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as 1.0alpha2 1.0alpha3 and 1.0-alpha-2 1.0-alpha-3 which the rules cater for. Everything else seems reasonable and the examples appear to make sense and parse the way I would expect things to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning
I've seen projects switch back and forth... depends on who is in power at the time and what style they like. So it would be best if mvn would be able comprehend: 1.0alpha2 1.0-alpha-3 --jason On Dec 18, 2006, at 3:41 PM, Barrie Treloar wrote: - 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)) The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are bit beyond how I would use things so I can't really comment. However I would expect a project to be self consistent so it doesn't really matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as 1.0alpha2 1.0alpha3 and 1.0-alpha-2 1.0-alpha-3 which the rules cater for. Everything else seems reasonable and the examples appear to make sense and parse the way I would expect things to work. - 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]
site plugin confusion - can we nuke -plugin-with-compat-for-2.0.4?
I'm confused about where we got to here - is it correct that the main site plugin is fine again now and this one (which should have been a branch anyway) can be nuked? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site plugin confusion - can we nuke -plugin-with-compat-for-2.0.4?
On 18 Dec 06, at 7:46 PM 18 Dec 06, Brett Porter wrote: I'm confused about where we got to here - is it correct that the main site plugin is fine again now and this one (which should have been a branch anyway) can be nuked? Trunk with the normal name is fine. I'm taking care of it and will finish it. Jason. - 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: Publishing plugin sites
I don't think a normal maven user would bother with the version of the plugin. Putting in the version of the plugin may give the user a bit too much information. However, putting the version would help the users who are using the latest features ( and are checking whether the features they want are in the plugins they are using ). Thus, a reference to indicate the version which those features are available is still necessary. I guess the @since tag on the goal parameters are enough, and a few side notes on the examples and usage section ( depending on what is presented ). Besides, if the user starts using those features, they would find out about those in the said sections, thus, the version where those features are available should be placed there as well ( making sure that the info is presented only when it is needed ). ...btw, the version of the plugin can be seen from the project-summary section. but it's not visible to common users. just my 2 cents worth. - Franz On 12/17/06, Brett Porter [EMAIL PROTECTED] wrote: Late response, but probably worth answering... I generally like this idea (and it is the default behaviour, I think) - but I think it would be too constrictive to most users. Is that a fair analysis? - Brett On 08/11/2006, at 7:54 AM, John Allen wrote: This maybe moot but this reminds me of something that bothered me a while back: The problem here is the lack of project identity (group id, artifact id, version) support in sites. A site is simply a view upon a project and yet there is no way for us to reflect which version that site was generated from while still employing maven's auto-URL generation scheme (i.e. automatic inheritance based generation of URLs). One can manually specify the url and associated deploymentManagementsite details for each project but that is lame and error prone. Consider all those nice links in the dependencies report, they should be linking to specific versions of those depended-upon projects, but without a lot of manual effort they are going to point to the 'latest' site for that dependency. I think we should have the same rigor in the site address space (URLs) as is employed in the repository address space. This would allow for automatic generation of version accurate sites (i.e. we would be able to preserve the 'old' sites). Historically 'site' may have been thought of as just a quick way for an open source project to produce an external facing web site and such a 'proper' addressing scheme would result in URLs such as: http://www.my-opensource.org/i/am/the/group/i-am-the-artifact-id/ and-im-the- version/index.html But that's easily handled with simple web server mapping techniques. Alt (and preferably) just create some good old fashioned web pages as the front door and then link to the maven generated content from there. Just my 0.02 worth Ps. We do intend visiting the core sometime soon to extend the current scheme to support full POM identity representation in the url and site schemes. I'll post patches if/when its sorted. John -Original Message- From: Franz Allan Valencia See [mailto:[EMAIL PROTECTED] Sent: 07 November 2006 13:26 To: Maven Developers List Subject: Re: Publishing plugin sites On 11/6/06, Brett Porter [EMAIL PROTECTED] wrote: Also, maybe the @since tags should be documented as well in [1]? Yes, but isn't this also included in the Maven site somewhere? hhmm..never seen it in maven2 site. but i've seen some goals documentation in maven-1.x with the 'since' column. - Franz - 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: update central repo with latest umlgraph
On 12/18/06, Jason Chaffee [EMAIL PROTECTED] wrote: Can someone please update the central repo with the latest umlgraph http://freshmeat.net/projects/umlgraph/?branch_id=48663release_id=24305 8 It's been submitted already: http://jira.codehaus.org/browse/MAVENUPLOAD-1275 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Feedback Needed on Release Reporting Tool
Hi Everyone, Been working on a tool to generate reports for release candidates and this is a mock of what it should look like: http://people.apache.org/~jtolentino/release-reports/MockReport.html We can send this generated page to the dev list when we call for a release. I appreciate any feedback so I can improve the reporting (and before I go further into implementation). Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing plugin sites
I'd like having the version number added. I don't usually know (or keep track of) when something gets released. And it's not always obvious that I'm reading a new feature... and we don't want to stop eager people in contributing documentation ALONG with their code patches right? :-) On 12/8/06, Stephane Nicoll [EMAIL PROTECTED] wrote: On 12/8/06, Wendy Smoak [EMAIL PROTECTED] wrote: Just a reminder and in case it needs more discussion: we are now publishing the latest plugin docs from svn, and not waiting for a release to do it. Can't we add the version of the plugin matching the status of the documentation? Even if we have @since tags, it would be better to clearly state the documentation is for version X.Y-SNAPSHOT. WDYT? Stéphane PS: Personnaly I forgot to add those tags to the EAR plugin and I am probably not the only one. Will fix it ASAP. Here's a link to the beginning of this thread, in case anyone missed it the first time around: http://www.nabble.com/Publishing-plugin-sites-t2584348.html Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
