Re: Being careful with backward compat
I can't find or recall this - do you have a log/date? - Brett On 05/03/2007, at 7:46 AM, Brian E. Fox wrote: The lates plexus-utils blows up the testing harness too because it changes some of the core classes. I don't remember the exact compilation error, but I discussed with Brett on IRC. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 5:31 PM To: Maven Developers List Subject: Re: Being careful with backward compat On 3 Mar 07, at 4:57 PM 3 Mar 07, Arnaud HERITIER wrote: Jason, Couldn't we enforce the usage of something like jdiff to check if there's an incompatibility between releases. Yup, we could use that or Clirr as Vincent suggested. That's one part of the answer. The separate integration tests are another part and we'll get there. The plugins released need to be exercised against released and upcoming versions. It something that we already had (incompatibility of m1 plugins with m1.0.x whereas m1.1 isn't released) and which is really damaging for our community. Yes, I think Torsten's awesome minijar plugin is going to be very handy. I'm about to check into trunk some plugin configurations which will hide some common dependencies which cause problems. Plexus Utils being one of them. Jason. Arnaud On 3/3/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, The current release of the Surefire plugin is a bit a nightmare with respect to backward compatibility. The problem is incompatible changes made to plexus-utils. The most current release will work with 2.0.5 because it still uses plexus-utils 1.1 but with the upgraded plexus-utils in trunk in fork mode will make it blow up. I'm trying to fix this now as in fork mode the branch and trunk now fail because 1.1 and 1.4 of plexus utils have changes in the command line classes. I am doing some magic with Torsten's Minijar plugin on the trunk, but for the branch I don't know if we want to employ this but with plexus- utils 1.4 there now we're going screw everyone. John and Kenney chatted about it briefly but we probably want to address this quickly and in a new release of surefire. Thanks, 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] - 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: Authorization Error on Configuration page in 1.1 -
What is the snapshot you test? Thierry Lach a écrit : I'm still seeing the problem behavior. On 3/5/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: It should be fixed now, can you test it? Emmanuel Wendy Smoak a écrit : > On 3/1/07, Thierry Lach <[EMAIL PROTECTED]> wrote: >> Using current sources patched for JBoss, I can't access the configuration >> page. As the administrator, when I try to go there, I get the message >> >> Authorization Error You are not authorized to access this page. Please >> contact your administrator to be granted the appropriate permissions. > > I see this in a fresh install, when I get that message as it tries to > redirect to the General Configuration page. > > It seems to be related to the fix for CONTINUUM-1185, when it wouldn't > let you *off* the General Configuration page. > > I reopened it: http://jira.codehaus.org/browse/CONTINUUM-1185 >
Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-3 and resource bundles
+1 On 5 Mar 07, at 12:19 PM 5 Mar 07, Daniel Kulp wrote: I'd like to release the entire remote-resources set. That includes the plugin as well as the 3 resources bundles. There is a critical bug fix (MRRESOURCES-13) that has caused some problems for a couple of projects. Tags: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote- resources-plugin-1.0-alpha-3/ http://svn.apache.org/repos/asf/maven/resources/tags/apache- resource-bundles-2/ Staging area: http://people.apache.org/~dkulp/stage_remoteresources/ Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0- alpha-3 ** Bug * [MRRESOURCES-13] - If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length ** Improvement * [MRRESOURCES-12] - It should be possible to use something other than "project.name" for the header Also included is updated the resource-bundle poms to use the new release tool set to support staged releases, gpg signing, etc I'm +1 to everything. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-gpg-plugin 1.0-alpha-3
Did you get someone to try it on a MAC? If so then +1 On 5 Mar 07, at 11:23 AM 5 Mar 07, Daniel Kulp wrote: I'd like to release maven-gpg-plugin version 1.0-alpha-3 to address some issues in the previous release. Release Notes - Maven 2.x GPG Plugin - Version 1.0-alpha-3 ** Improvement * [MGPG-1] - Prompt for pass phrase if it is not supplied * [MGPG-2] - Allow the selection of a particular signature Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-gpg- plugin-1.0-alpha-3/ Staged at: http://people.apache.org/~dkulp/stage_gpg/ Here's my +1. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote-result] archetype was: svn commit: r514184 - /maven/sandbox/trunk/archetype/
Hi, To answer quickly, It is a revolution (little). The code is at the mojo sandbox for now (mojo-sandbox/maven-archetypeng). I just uploaded a first snapshot at the mojo's snapshot repository I sent a mail on [EMAIL PROTECTED] to start havign some feedback. Please have try on it and review the code. mvn archetypeng:generate I am sorry but documentation is not yet written. Will be happy to have the code reach the apache foundation. Best regards Raphaël Jason van Zyl-2 wrote: > > > On 4 Mar 07, at 12:50 PM 4 Mar 07, Brett Porter wrote: > >> On 04/03/2007, at 7:26 AM, Jason van Zyl wrote: >> >>> You might want to sync up with raphael over in mojo where he's >>> taking a swing at a new version of archetype. >> >> Raphael - can you tell us what is happening over here? (Pretty sure >> you're still subscribed). Wendy's asked me to look at something, >> and I'd be happy to, but I don't want to later find out the work is >> irrelevant if I do it here. >> >> My 2 questions would be: >> a) is this an evolution or a revolution? ie, would rapid >> application of patches here be appropriate, or is it a >> compatibility-breaking attempt at making it work from scratch? >> b) is the intent to bring it back here when it's done? >> >> Personally, I find this a little weird. If it ever intends to come >> back here we should be discussing it here now. > > The intention is if he's happy with it, and can be slotted in then > great. He's not even finished but working and might want to offer > something. I suggested Wendy look at and decide what she think is > better to hack on. If it works I am happy to suggest it be moved here. > >> If it's not, then we might as well carry on as is, right? I just >> need to know which it is so I don't waste any time. >> >>> He doesn't have access at Apache so he's doing it at Mojo. >> >> That's lame. > > It's not lame, it's what we have always been doing. He's > experimenting, he wanted somewhere to put it and he has access. I > don't see how that is lame. > >> If it's something we want here, we should find a way to do it. I'd >> elect a committer based on past work and ability to state what he >> was going to do clearly here. Or something else, including using >> mojo as a scratch space, as long as everyone clearly understands >> what's going on. > > What he's working on is a prototype. He's trying to create a > replacement, and there's nothing wrong with him making the prototype > there. I pointed it out to Wendy so she knew. No one has touched the > code in quite a while, he's interested in working on it. He's got > access, he started right away, let him run with it. Absolutely > nothing wrong with that. I have no problem with him being a committer > either but while he wants to hack away let him work on it where he can. > > 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] > > > -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r514184maven-sandbox-trunk-archetype--tf3342776s177.html#a9321972 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: forceVersion for maven-install-plugin?
No comments? Is there another way to get specific 'testing' versions
of artifacts installed into the local repo before the install phase?
--jason
On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Any comments on adding a 'forceVersion' param to the maven-install-
plugin, which will for all artifacts (including attached) to be
installed with the given version?
I'm thinking this would be really helpful for testing maven plugins,
so that in the pre-integration-test phase, one could use the m-
install-p to force all artifacts to be installed with a 'testing'
version, then in the 'integration-test' phase run the m-invoker-p to
execute a set of maven projects to test/validate the plugin works as
expected, and then once that passes, the normal m-install-p execution
will install the real versions of the artifacts into the repository.
This would allow the src/it/**/pom.xml files to use testing for all of the plugin artifacts, and would prevent broken
artifacts (which don't pass tests) from making it into the local repo
cache (and thus available to other projects).
For example:
8<
org.apache.maven.plugins
maven-install-plugin
pre-integration-test
run
testing
org.apache.maven.plugins
maven-invoker-plugin
integration-test
run
${pom.basedir}/src/
it
**/pom.xml
>8
I've been digging around trying to figure out how to test my
plugins... so far I have not found a single example that just works
out of the box... I've gotten the groovy-maven-plugin ( http://
svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/groovy-maven-plugin/ )
to work *almost* as I'd like... the only exception is that right now
I have to hard-code the version of the plugin being tested in each
src/it/**/pom.xml... which I would really like to avoid.
I've seen a few other plugins use the maven-plugin-management-
plugin... but I've no idea what it does... same thing with maven-plug-
it-plugin... both look like they might do something along the lines
to allow src/it/**/pom.xml to not need hardcoded plugin versions...
but I really can't tell.
Anyways... I think simply adding a 'forceVersion' to the maven-
install-plugin should solve this... and not introduce more plugins to
support/maintain.
--jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apache parent pom 4
Result: +1: 7 going for it On 3/2/07, Andrew Williams <[EMAIL PROTECTED]> wrote: +1 On 1 Mar 2007, at 17:22, Carlos Sanchez wrote: > anything pending to do in the apache pom? there are some mistakes in > the version 3 like organization name that propagates to all apache > projects. > > -- > 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] > - 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: Authorization Error on Configuration page in 1.1 -
I'm still seeing the problem behavior. On 3/5/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: It should be fixed now, can you test it? Emmanuel Wendy Smoak a écrit : > On 3/1/07, Thierry Lach <[EMAIL PROTECTED]> wrote: >> Using current sources patched for JBoss, I can't access the configuration >> page. As the administrator, when I try to go there, I get the message >> >> Authorization Error You are not authorized to access this page. Please >> contact your administrator to be granted the appropriate permissions. > > I see this in a fresh install, when I get that message as it tries to > redirect to the General Configuration page. > > It seems to be related to the fix for CONTINUUM-1185, when it wouldn't > let you *off* the General Configuration page. > > I reopened it: http://jira.codehaus.org/browse/CONTINUUM-1185 >
Re: [VOTE] Release maven-model-converter 2.1
+1 Arnaud On 3/5/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: +1 Emmanuel Dennis Lundberg a écrit : > Hi, > > I'd like to release maven-model-converter. The last release was 2.0.4. > Back then it resided in maven components. It has now moved to maven shared. > > This release is a preparation for a release of the maven-one-plugin. > > The issues that have been resolved can be seen in JIRA: > http://jira.codehaus.org/browse/MNG-2320 > http://jira.codehaus.org/browse/MNG-2327 > http://jira.codehaus.org/browse/MNG-2332 > http://jira.codehaus.org/browse/MNG-2335 > http://jira.codehaus.org/browse/MNG-2336 > http://jira.codehaus.org/browse/MNG-2338 > > To summarize the changes, two types of plexus-components have been > added: PluginRelocators and PluginConfigurationConverters. These help by > converting plugin dependencies and their configuration. > > Revision: 514217 > > A SNAPSHOT has been deployed to our snapshot-repository. > > > The vote will be open for 72 hours. > > > Here is my +1 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-shared-components pom 7
+1 Arnaud On 3/5/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: +1 Dan On Sunday 04 March 2007 18:54, Dennis Lundberg wrote: > Hi > > The maven-shared-components pom needs to be released so that the shared > components can take advantage of the new release tool chain. > > Revision: 514495 > > A SNAPSHOT has been deployed to our snapshot-repository. > > The vote will be open for 72 hours. > > > Here is my +1 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-gpg-plugin 1.0-alpha-3
+1 Arnaud On 3/5/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: +1 Stéphane On 3/5/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > I'd like to release maven-gpg-plugin version 1.0-alpha-3 to address some > issues in the previous release. > > Release Notes - Maven 2.x GPG Plugin - Version 1.0-alpha-3 > ** Improvement > * [MGPG-1] - Prompt for pass phrase if it is not supplied > * [MGPG-2] - Allow the selection of a particular signature > > Tag: > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-gpg-plugin-1.0-alpha-3/ > > Staged at: > http://people.apache.org/~dkulp/stage_gpg/ > > > > Here's my +1. > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727C: 508-380-7194 > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-3 and resource bundles
+1 Arnaud On 3/5/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: I'd like to release the entire remote-resources set. That includes the plugin as well as the 3 resources bundles. There is a critical bug fix (MRRESOURCES-13) that has caused some problems for a couple of projects. Tags: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-3/ http://svn.apache.org/repos/asf/maven/resources/tags/apache-resource-bundles-2/ Staging area: http://people.apache.org/~dkulp/stage_remoteresources/ Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-3 ** Bug * [MRRESOURCES-13] - If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length ** Improvement * [MRRESOURCES-12] - It should be possible to use something other than "project.name" for the header Also included is updated the resource-bundle poms to use the new release tool set to support staged releases, gpg signing, etc I'm +1 to everything. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authorization Error on Configuration page in 1.1 -
It should be fixed now, can you test it? Emmanuel Wendy Smoak a écrit : On 3/1/07, Thierry Lach <[EMAIL PROTECTED]> wrote: Using current sources patched for JBoss, I can't access the configuration page. As the administrator, when I try to go there, I get the message Authorization Error You are not authorized to access this page. Please contact your administrator to be granted the appropriate permissions. I see this in a fresh install, when I get that message as it tries to redirect to the General Configuration page. It seems to be related to the fix for CONTINUUM-1185, when it wouldn't let you *off* the General Configuration page. I reopened it: http://jira.codehaus.org/browse/CONTINUUM-1185
Re: svn commit: r514852 - /maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/admin/ConfigurationAction.java
already fixed, but thanks :) Brett Porter a écrit : On 05/03/2007, at 12:25 PM, [EMAIL PROTECTED] wrote: +getLogger().info( "1"); SecureActionBundle bundle = new SecureActionBundle(); bundle.setRequiresAuthentication( true ); bundle.addRequiredAuthorization( ContinuumRoleConstants.CONTINUUM_MANAGE_CONFIGURATION, Resource.GLOBAL ); +getLogger().info( "2"); oops?
Re: svn commit: r514852 - /maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/admin/ConfigurationAction.java
On 05/03/2007, at 12:25 PM, [EMAIL PROTECTED] wrote: +getLogger().info( "1"); SecureActionBundle bundle = new SecureActionBundle(); bundle.setRequiresAuthentication( true ); bundle.addRequiredAuthorization ( ContinuumRoleConstants.CONTINUUM_MANAGE_CONFIGURATION, Resource.GLOBAL ); +getLogger().info( "2"); oops?
[VOTE] maven-remote-resources-plugin 1.0-alpha-3 and resource bundles
I'd like to release the entire remote-resources set. That includes the plugin as well as the 3 resources bundles. There is a critical bug fix (MRRESOURCES-13) that has caused some problems for a couple of projects. Tags: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-3/ http://svn.apache.org/repos/asf/maven/resources/tags/apache-resource-bundles-2/ Staging area: http://people.apache.org/~dkulp/stage_remoteresources/ Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-3 ** Bug * [MRRESOURCES-13] - If remote resources is run twice (like in a forked lifecycle) the resources are all 0 length ** Improvement * [MRRESOURCES-12] - It should be possible to use something other than "project.name" for the header Also included is updated the resource-bundle poms to use the new release tool set to support staged releases, gpg signing, etc I'm +1 to everything. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-gpg-plugin 1.0-alpha-3
+1 Stéphane On 3/5/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: I'd like to release maven-gpg-plugin version 1.0-alpha-3 to address some issues in the previous release. Release Notes - Maven 2.x GPG Plugin - Version 1.0-alpha-3 ** Improvement * [MGPG-1] - Prompt for pass phrase if it is not supplied * [MGPG-2] - Allow the selection of a particular signature Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-gpg-plugin-1.0-alpha-3/ Staged at: http://people.apache.org/~dkulp/stage_gpg/ Here's my +1. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - 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]
Debian package of Maven 2.0.5
Hi all! I would like to bring the binary build package of Maven 2.0.5 built by Michael Koch to your attention. I just installed it on Ubuntu Edgy and ran my builds and all works fine. http://gnu.wildebeest.org/diary-man-di/?p=35 I can recommend using it. Manfred -- View this message in context: http://www.nabble.com/Debian-package-of-Maven-2.0.5-tf3351102s177.html#a9318575 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release maven-gpg-plugin 1.0-alpha-3
I'd like to release maven-gpg-plugin version 1.0-alpha-3 to address some issues in the previous release. Release Notes - Maven 2.x GPG Plugin - Version 1.0-alpha-3 ** Improvement * [MGPG-1] - Prompt for pass phrase if it is not supplied * [MGPG-2] - Allow the selection of a particular signature Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-gpg-plugin-1.0-alpha-3/ Staged at: http://people.apache.org/~dkulp/stage_gpg/ Here's my +1. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Being careful with backward compat
The lates plexus-utils blows up the testing harness too because it changes some of the core classes. I don't remember the exact compilation error, but I discussed with Brett on IRC. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Saturday, March 03, 2007 5:31 PM To: Maven Developers List Subject: Re: Being careful with backward compat On 3 Mar 07, at 4:57 PM 3 Mar 07, Arnaud HERITIER wrote: > Jason, > > Couldn't we enforce the usage of something like jdiff to check if > there's an incompatibility between releases. Yup, we could use that or Clirr as Vincent suggested. That's one part of the answer. The separate integration tests are another part and we'll get there. The plugins released need to be exercised against released and upcoming versions. > It something that we already had (incompatibility of m1 plugins with > m1.0.x whereas m1.1 isn't released) and which is really damaging for > our community. Yes, I think Torsten's awesome minijar plugin is going to be very handy. I'm about to check into trunk some plugin configurations which will hide some common dependencies which cause problems. Plexus Utils being one of them. Jason. > > Arnaud > > On 3/3/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> The current release of the Surefire plugin is a bit a nightmare with >> respect to backward compatibility. The problem is incompatible >> changes made to plexus-utils. The most current release will work with >> 2.0.5 because it still uses plexus-utils 1.1 but with the upgraded >> plexus-utils in trunk in fork mode will make it blow up. I'm trying >> to fix this now as in fork mode the branch and trunk now fail because >> 1.1 and 1.4 of plexus utils have changes in the command line classes. >> I am doing some magic with Torsten's Minijar plugin on the trunk, but >> for the branch I don't know if we want to employ this but with >> plexus- >> utils 1.4 there now we're going screw everyone. John and Kenney >> chatted about it briefly but we probably want to address this quickly >> and in a new release of surefire. >> >> Thanks, >> >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why not DocBook?
On 3/5/07, Brendon Matheson <[EMAIL PROTECTED]> wrote: I've always wondered why content for the Maven site plugin isn't defined as DocBook articles. It always struck me that xdoc's grammar is similar to the core parts of DocBook, and being a standard might make DocBook more attractive to some people. There are at least two docbook plugins for Maven... * http://docs.codehaus.org/display/MAVENUSER/Docbkx+Maven+Plugin * http://maven-plugins.sourceforge.net/maven-sdocbook-plugin/index.html I suppose there's no reason we couldn't have support for src/site/docbook alongside src/site/apt and src/site/xdoc, if someone wanted to put the time into it. That is, for the site plugin to automatically recognize src/site/docbook/index.xml and use that to generate the index page for the project, as it would do with src/site/apt/index.apt. Or did you have something else in mind? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why not DocBook?
Hi all, I've always wondered why content for the Maven site plugin isn't defined as DocBook articles. It always struck me that xdoc's grammar is similar to the core parts of DocBook, and being a standard might make DocBook more attractive to some people. Cheers, brnzn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-shared-components pom 7
+1 Dan On Sunday 04 March 2007 18:54, Dennis Lundberg wrote: > Hi > > The maven-shared-components pom needs to be released so that the shared > components can take advantage of the new release tool chain. > > Revision: 514495 > > A SNAPSHOT has been deployed to our snapshot-repository. > > The vote will be open for 72 hours. > > > Here is my +1 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven's ArtifactMetadataSource's bad role-hint
OK, that is done. The change should not affect anything not using plexus-container- default < alpha-19-SNAPSHOT, which includes the core maven build atm, as I have not upgraded it. Want more testing done first :) Andy On 5 Mar 2007, at 01:56, Brett Porter wrote: I agree - it's going to enable plugins that reference it successfully by role alone now to continue working. However, something may reference it directly by the maven role- hint: I suggest a subclass with not modifications except the alternate role-hint be made (and deprecated) for that case. - Brett On 04/03/2007, at 3:18 AM, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". The latest plexus code (will shortly...) be more strict on hints and no longer allow components to grab "whatever is configured", if a hint exists it must be honoured (but "default" is the, erm, default). This means that if switched to "default" then plugins could continue to use it as now without stating which hint they want. Andy - 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: Maven's ArtifactMetadataSource's bad role-hint
Yes, it does add "default". I think Jason was referring to the use of CDC irrespective if whether hints were in or not. After all, CDC does not need a hint at all, and the container will fill the blanks at runtime. Andy On 5 Mar 2007, at 08:56, Trygve Laugstøl wrote: Jason van Zyl wrote: On 4 Mar 07, at 3:18 AM 4 Mar 07, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". I think that's fine, but we should also annotating all the plexus components and I think we can make this work with the bootstrap in much the same way we get modello to work. This will save much aggravation, it will then all be generated and adjustments to the CDC where required will make this much less painful. I'd rather not change all the source code. IMO the container should just add "default" as the role hint. As far as I can this will be required to keep compatibility with existing components. -- Trygve - 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's ArtifactMetadataSource's bad role-hint
Jason van Zyl wrote: On 4 Mar 07, at 3:18 AM 4 Mar 07, Andrew Williams wrote: Are there an objections, or reasons not to change the role-hint of MavenMetadataSource in maven-project from "maven" to "default". I think that's fine, but we should also annotating all the plexus components and I think we can make this work with the bootstrap in much the same way we get modello to work. This will save much aggravation, it will then all be generated and adjustments to the CDC where required will make this much less painful. I'd rather not change all the source code. IMO the container should just add "default" as the role hint. As far as I can this will be required to keep compatibility with existing components. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Trying to use standard versioning
+1 with the same remark about not having the trailing .0 on the first release. Brett Porter wrote: +1 (I was going to do that with the 2.3 release, except that it had had junit4 support added). Aesthetically, I prefer to drop the trailing 0 on a first point release, but don't mind either way as long as we're consistent. - Brett On 02/03/2007, at 10:20 AM, Jason van Zyl wrote: Hi, The impetus for this is wanting to release the surefire plugin that has a tiny bug in it. We are versioning our Maven release major.minor.micro so why don't we do the same with our plugin and treat everything like we're going to do small incremental releases like we should be doing. I would like to change all the versions on plugin to follow the major.minor.micro format starting with the surefire plugin. Thanks, 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Trying to use standard versioning
Kenney Westerhof wrote: +1, as long as it's done like this: - use major.minor on trunk - major.[minor+1] is either api breaking or has new features - bugfixes should be major.minor.micro, from a maintenance branch for major.minor. Minor releases can't break APIs, we agreed on that a long time ago. Minor releases can only add functionality. so -0 on bugfix versions in the poms on trunk. I don't understand why you don't want to keep the mainline work on trunk? When 2.1 is release should we branch it into /branches/2.1.x immediately and leave trunk/ dead for 6 months? -- Trygve -- Kenney Jason van Zyl wrote: Hi, The impetus for this is wanting to release the surefire plugin that has a tiny bug in it. We are versioning our Maven release major.minor.micro so why don't we do the same with our plugin and treat everything like we're going to do small incremental releases like we should be doing. I would like to change all the versions on plugin to follow the major.minor.micro format starting with the surefire plugin. Thanks, 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-shared-components pom 7
+1 Stéphane On 3/5/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi The maven-shared-components pom needs to be released so that the shared components can take advantage of the new release tool chain. Revision: 514495 A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-shared-components pom 7
+1 Emmanuel Dennis Lundberg a écrit : Hi The maven-shared-components pom needs to be released so that the shared components can take advantage of the new release tool chain. Revision: 514495 A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-model-converter 2.1
+1 Emmanuel Dennis Lundberg a écrit : Hi, I'd like to release maven-model-converter. The last release was 2.0.4. Back then it resided in maven components. It has now moved to maven shared. This release is a preparation for a release of the maven-one-plugin. The issues that have been resolved can be seen in JIRA: http://jira.codehaus.org/browse/MNG-2320 http://jira.codehaus.org/browse/MNG-2327 http://jira.codehaus.org/browse/MNG-2332 http://jira.codehaus.org/browse/MNG-2335 http://jira.codehaus.org/browse/MNG-2336 http://jira.codehaus.org/browse/MNG-2338 To summarize the changes, two types of plexus-components have been added: PluginRelocators and PluginConfigurationConverters. These help by converting plugin dependencies and their configuration. Revision: 514217 A SNAPSHOT has been deployed to our snapshot-repository. The vote will be open for 72 hours. Here is my +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
