Re: Test failure on trunk
Yeah - I finally got it, so I'll test your update. BTW, pretty sure others have mentioned this, but it's working nicely on my MacOS X Tiger (10.4.9) laptop. Christian. On Mar 29, 2007, at 11:08 AM, Emmanuel Venisse wrote: I added the jvm memory option to the surefire plugin because now I have this pb too :( Emmanuel Thierry Lach a écrit : I agree. I don't want to have to bump up my memory config for all projects just because of one. On 3/23/07, Andrew Williams [EMAIL PROTECTED] wrote: I think that modifying your environment or installation options is a very bad idea, especially if you are striving for truly reproducible build results. Andy On 22 Mar 2007, at 16:29, Jesse McConnell wrote: most people I know just add the following to their environment variables MAVEN_OPTS=-Xmx512m jesse On 3/22/07, Thierry Lach [EMAIL PROTECTED] wrote: Any reason why this couldn't just be added permanently? On 3/22/07, Andrew Williams [EMAIL PROTECTED] wrote: I sometimes get that problem too, when I see it I insert the following into the build section of continuum's root pom.xml plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration argLine-Xmx512m/argLine /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration forktrue/fork meminitial128m/meminitial maxmem512m/maxmem /configuration /plugin /plugins Andy On 19 Mar 2007, at 22:59, Graham Leggett wrote: Emmanuel Venisse wrote: how many memory is allocated to the build? Normally the default is enough. No idea - checked out a pristine copy of trunk as of an hour or two ago, and did an mvn install. Is there somewhere where memory allocations are set, perhaps in a pom file? Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED] christian gruber + [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023 process coach and architect + ISRÁFÍL CONSULTING SERVICES
lurking enabled for testng
I'm hanging out here now, so if there was anything to discuss wrt surefire testng support I guess it would be good for that. -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
what groupId for quartz ?
opensymphony Quartz scheduler exists on repo1.maven.org in both : http://repo1.maven.org/maven2/quartz/quartz/ and http://repo1.maven.org/maven2/opensymphony/quartz/ opensymphony groupId contains the latest 1.6.0, so it looks to be the expected groupId, but this one has no POM ( migrate from maven1 ? ) Could someone clarify this, perhaps add some POM to opensymphony/quarts, maybe with relocation to quartz ? Nico.
[ANN] Maven Clover Plugin 1.11.2 for Maven 1.x released
We are pleased to announce the Maven Clover Plugin 1.11.2 release! http://maven.apache.org/maven-1.x/plugins/clover/ The Clover plugin allows measuring test coverage using Clover (http://www.cenqua.com/clover). === Changes in this version include: Changes: o Use new clover license. Fixes MPCLOVER-58. === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-clover-plugin -Dversion=1.11.2 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-clover-plugin-1.11.2.jar Have fun! -The Maven Clover Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven JDiff Plugin 1.5.1 for Maven 1.x released
We are pleased to announce the Maven JDiff Plugin 1.5.1 release! http://maven.apache.org/maven-1.x/plugins/jdiff/ Plugin for JDiff - reports on the differences in the public API of two releases by comparing the sources of two SCM checkouts. === Changes in this version include: Fixed bugs: o Jdiff fails with svn modules. New property maven.jdiff.svn.module. Fixes MPJDIFF-9. o Jdiff doclet fails with jdk 1.4. Fixes MPJDIFF-10. o Use relative links to the javadoc. Changes: o It requires at least maven-plugin-plugin v1.7. === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jdiff-plugin -Dversion=1.5.1 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-jdiff-plugin-1.5.1.jar Have fun! -The Maven JDiff Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven PMD Plugin 1.10 for Maven 1.x released
We are pleased to announce the Maven PMD Plugin 1.10 release! http://maven.apache.org/maven-1.x/plugins/pmd/ The Maven PMD plugin is a plugin that wraps the PMD framework (http://pmd.sourceforge.net). PMD is a source checking framework that works by scanning Java source code and looks for potential problems like: unused local variables, empty catch blocks, unused parameters, empty 'if' statements, etc. === Changes in this version include: New Features: o Add Goals page. o Add an alternative jsl stylesheet that includes priority information. Thanks to James Dempsey. o Allow custom JSL stylesheet to be defined via a property. Fixes MPPMD-27. Fixed bugs: o Cannot run pmd with Strings rulesets. Fixes MPPMD-30. Changes: o Upgrade to PMD 3.9. Fixes MPPMD-29. o Update/clarify properties and add Default column to Properties page. o Update dependencies to unify them between plugins. The following dependencies are updated: jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed: saxpath. === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-pmd-plugin -Dversion=1.10 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-pmd-plugin-1.10.jar Have fun! -The Maven PMD Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Source Control Management Plugin 1.6.1 for Maven 1.x released
We are pleased to announce the Maven Source Control Management Plugin 1.6.1 release! http://maven.apache.org/maven-1.x/plugins/scm/ A plugin for SCM tasks. === Changes in this version include: Fixed bugs: o The prepare-release goal should fail if project.xml can't be edited (e.g. read only). Fixes MPSCM-63. o SCM Parse Connection output is wrong / misleading. Fixes MPSCM-89. o scm:prepare-release does not commit modified changes.xml. Fixes MPSCM-86. Changes: o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. o Upgrade plexus-container-default and plexus-component-api to version 1.0-alpha-15 and replace classworlds by plexus-classworlds 1.2-alpha-5 o Update dom4j and jelly dependencies to match the ones in maven 1.1 core. o Update dependencies to unify them between plugins. The following dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, jaxen v1.0-FCS-full to 1.1-beta-9. Add the dependency to jline for commons-jelly-tags-interaction v1.1. o Upgrade to commons-io 1.2. === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-scm-plugin -Dversion=1.6.1 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-scm-plugin-1.6.1.jar Have fun! -The Maven Source Control Management Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Site Plugin 1.7.1 for Maven 1.x released
We are pleased to announce the Maven Site Plugin 1.7.1 release! http://maven.apache.org/maven-1.x/plugins/site/ Generate web site. === Changes in this version include: Fixed bugs: o Update files modes on the remote host after deployment with rsync (you don't have to use the same rights in your local directory). o Update root directory mode on the remote host (rsync and ssh). Changes: o Update dependencies to unify them between plugins. The following dependencies are updated : commons-net v1.4.0 to v1.4.1 === To automatically install the plugin, type the following on a single line: maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-site-plugin -Dversion=1.7.1 For a manual installation, you can download the plugin here: http://www.apache.org/dyn/closer.cgi/java-repository/maven/plugins/maven-site-plugin-1.7.1.jar Have fun! -The Maven Site Plugin development team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
Max Bowsher wrote:
John Casey wrote:
Max: I'm tempted to say that we should look for decimal versions of common
octal expressions, then prefix the rest with '0' to ensure they're
interpreted as octal (unless they have 0x in front, that is).
Is that a decent solution?
I think that it is the best compromise between maintaining the same
behaviour with existing descriptors, and fixing the bug going forward
into the future.
Would this behaviour apply to all modes in the descriptor, or just
filefileMode ? (I'd lean toward the latter).
OOI, why prepend a leading zero, rather than using Integer.parseInt(x,8)
and Integer.parseInt(x,10) as appropriate? I was thinking of something
along the lines of:
HashMap commonModes = new HashMap() {{
add(
Oh, grr. I'd really like to know how Thunderbird managed to save a
previous version than was showing when I did save-to-Drafts.
Anyway, I meant:
private static HashMap commonDecimalModes = new HashMap() {{
add(420);
add(436);
add(493);
add(509);
}}
.
if ( commonDecimalModes.contains( mode ) )
return Integer.parseInt( mode, 10 );
else
return Integer.parseInt( mode, 8 );
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
Hi Max,
Max Bowsher wrote on Thursday, March 29, 2007 1:46 PM:
Max Bowsher wrote:
John Casey wrote:
Max: I'm tempted to say that we should look for decimal versions of
common octal expressions, then prefix the rest with '0' to ensure
they're interpreted as octal (unless they have 0x in front, that
is).
Is that a decent solution?
I think that it is the best compromise between maintaining the same
behaviour with existing descriptors, and fixing the bug going
forward into the future.
Would this behaviour apply to all modes in the descriptor, or just
filefileMode ? (I'd lean toward the latter).
OOI, why prepend a leading zero, rather than using
Integer.parseInt(x,8) and Integer.parseInt(x,10) as appropriate? I
was thinking of something along the lines of:
HashMap commonModes = new HashMap() {{
add(
Oh, grr. I'd really like to know how Thunderbird managed to save a
previous version than was showing when I did save-to-Drafts.
Anyway, I meant:
private static HashMap commonDecimalModes = new HashMap() {{
add(420); add(436);
add(493);
add(509);
}}
.
if ( commonDecimalModes.contains( mode ) )
return Integer.parseInt( mode, 10 );
else
return Integer.parseInt( mode, 8 );
Why not letting Java decide? It handles decimal, octal and hex values
automatically:
public Integer fromString(String str) {
long value = Long.decode(str).longValue();
if(value Integer.MIN_VALUE || value 0xl) {
throw new NumberFormatException(For input string: \ + str +
'');
}
return new Integer((int)value);
}
Note: Integer.decode(String) is not used here because it will not handle
negative hex-coded integer values. With this approach you can express -1 as
0x ...
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
Max Bowsher wrote on Thursday, March 29, 2007 3:26 PM: Jörg Schaible wrote: [snip] Note: Integer.decode(String) is not used here because it will not handle negative hex-coded integer values. With this approach you can express -1 as 0x ... The whole point here is to maximize compatibility with maven-assembly-plugin-2.1 behaviour. That's why we, not Java, should be making the decision. Furthermore, we are talking about Unix permission mode bits. Neither negative values, nor hexadecimal values, are relevant. Decimal values are only relevant to the extent of supporting existing assembly descriptors written for the buggy behaviour of maven-assembly-plugin-2.1. Yep. Noticed my misplaced comment when it was already sent. I would not like to support hex code for Unix permissions either ... sorry, for the noise. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin
I've deployed a new version from the 2.2-beta-1 tag that includes Brett's fix. However, I haven't changed anything WRT Max's message yet. Feel free to try this stuff out; I'm going to spend a few mins trying to sort out the file/dir modes stuff. -john On 3/29/07, Brett Porter [EMAIL PROTECTED] wrote: On 29/03/2007, at 4:13 PM, Stephane Nicoll wrote: IMO, we really need the assembly release. It's been way too long and it's beta. Can't we fix those things for beta-2? If John's fixed the bug I filed, then I'm happy (was just waiting for the new build to be announced so I could test it...) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
All of this will create one big inconsistency, though. Consider what happens when, way down the line, someone tries to set '511' as a real, octal mode? If they don't use '0511', they'll get 777. This is wildly counterintuitive when you consider that '777' == 777 and '0777' == 777. Also, it will only make it *less* intuitive moving forward (again, for new builds, not for legacy or tagged builds) if we ONLY apply this inconsistency to filefileMode// elements. I don't see how we can maintain the behavior of the buggy implementation from 2.1. -john On 3/29/07, Jörg Schaible [EMAIL PROTECTED] wrote: Max Bowsher wrote on Thursday, March 29, 2007 3:26 PM: Jörg Schaible wrote: [snip] Note: Integer.decode(String) is not used here because it will not handle negative hex-coded integer values. With this approach you can express -1 as 0x ... The whole point here is to maximize compatibility with maven-assembly-plugin-2.1 behaviour. That's why we, not Java, should be making the decision. Furthermore, we are talking about Unix permission mode bits. Neither negative values, nor hexadecimal values, are relevant. Decimal values are only relevant to the extent of supporting existing assembly descriptors written for the buggy behaviour of maven-assembly-plugin-2.1. Yep. Noticed my misplaced comment when it was already sent. I would not like to support hex code for Unix permissions either ... sorry, for the noise. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin (Decimal/Octal file modes issue)
On 3/29/07, John Casey [EMAIL PROTECTED] wrote: I don't see how we can maintain the behavior of the buggy implementation from 2.1. +1 Honestly if found it silly to maintain a buggy behavior. Stéphane -john On 3/29/07, Jörg Schaible [EMAIL PROTECTED] wrote: Max Bowsher wrote on Thursday, March 29, 2007 3:26 PM: Jörg Schaible wrote: [snip] Note: Integer.decode(String) is not used here because it will not handle negative hex-coded integer values. With this approach you can express -1 as 0x ... The whole point here is to maximize compatibility with maven-assembly-plugin-2.1 behaviour. That's why we, not Java, should be making the decision. Furthermore, we are talking about Unix permission mode bits. Neither negative values, nor hexadecimal values, are relevant. Decimal values are only relevant to the extent of supporting existing assembly descriptors written for the buggy behaviour of maven-assembly-plugin-2.1. Yep. Noticed my misplaced comment when it was already sent. I would not like to support hex code for Unix permissions either ... sorry, for the noise. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
This is the second attempt, after fixing: * http://jira.codehaus.org/browse/MASSEMBLY-155 * http://jira.codehaus.org/browse/MASSEMBLY-192 * [file and directory mode parsing] WRT mode parsing, everything is now parsed using Integer.parseInt( mode, 8 ). If this results in a NumberFormatException, that is wrapped in an AssemblyFormattingException that indicates that it was a file/dir mode that failed to parse. If the parse succeeds, the resulting mode int is checked for sanity. That is, cases where group|world have perms that the user doesn't, or cases where world has perms that the group doesn't (as in, user:rx, group:rwx, world: rx). This could still break builds where a mode is specified in decimal, but at least there should be some indication of what went wrong...and now they'll know that we're trying to do the right thing. Also, all of the mode parsing has been consolidated into TypeConversionUtils, with a TypeConversionUtilsTest to check my work. Finally, for MASSEMBLY-155, there is a new integration test that verifies its behavior. So, let's try this again: I wanted to call a vote to release a beta version of the new assembly plugin. There are still some outstanding issues (though not as many as jira would have you believe; they just need tests), but I think we're at around 95-99% backward compatibility and the new features seem to be working well. It's been just sitting in SVN for quite awhile now, and many people are using it directly from there. I'd like to provide better support for those people, and start getting more feedback on exactly what's still broken. The change list is pretty large, but is mainly concerned with refactoring the plugin away from the old monolithic approach to one that uses phases to handle the different descriptor sections, along with common task classes to handle behavior shared between phases. Road Map: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=12617 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1 Staging repository: http://people.apache.org/~jdcasey/stage/repohttp://people.apache.org/%7Ejdcasey/stage/repo So, let's try 72h +1/+0/-1. Please cast your votes! Here's my +1. -john
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
+1 On 3/29/07, John Casey [EMAIL PROTECTED] wrote: This is the second attempt, after fixing: * http://jira.codehaus.org/browse/MASSEMBLY-155 * http://jira.codehaus.org/browse/MASSEMBLY-192 * [file and directory mode parsing] WRT mode parsing, everything is now parsed using Integer.parseInt( mode, 8 ). If this results in a NumberFormatException, that is wrapped in an AssemblyFormattingException that indicates that it was a file/dir mode that failed to parse. If the parse succeeds, the resulting mode int is checked for sanity. That is, cases where group|world have perms that the user doesn't, or cases where world has perms that the group doesn't (as in, user:rx, group:rwx, world: rx). This could still break builds where a mode is specified in decimal, but at least there should be some indication of what went wrong...and now they'll know that we're trying to do the right thing. Also, all of the mode parsing has been consolidated into TypeConversionUtils, with a TypeConversionUtilsTest to check my work. Finally, for MASSEMBLY-155, there is a new integration test that verifies its behavior. So, let's try this again: I wanted to call a vote to release a beta version of the new assembly plugin. There are still some outstanding issues (though not as many as jira would have you believe; they just need tests), but I think we're at around 95-99% backward compatibility and the new features seem to be working well. It's been just sitting in SVN for quite awhile now, and many people are using it directly from there. I'd like to provide better support for those people, and start getting more feedback on exactly what's still broken. The change list is pretty large, but is mainly concerned with refactoring the plugin away from the old monolithic approach to one that uses phases to handle the different descriptor sections, along with common task classes to handle behavior shared between phases. Road Map: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=12617 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.2-beta-1 Staging repository: http://people.apache.org/~jdcasey/stage/repo http://people.apache.org/%7Ejdcasey/stage/repo So, let's try 72h +1/+0/-1. Please cast your votes! Here's my +1. -john -- Eric Redmond http://codehaus.org/~eredmond
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
+1 On 29 Mar 07, at 1:50 PM 29 Mar 07, John Casey wrote: This is the second attempt, after fixing: * http://jira.codehaus.org/browse/MASSEMBLY-155 * http://jira.codehaus.org/browse/MASSEMBLY-192 * [file and directory mode parsing] WRT mode parsing, everything is now parsed using Integer.parseInt ( mode, 8 ). If this results in a NumberFormatException, that is wrapped in an AssemblyFormattingException that indicates that it was a file/dir mode that failed to parse. If the parse succeeds, the resulting mode int is checked for sanity. That is, cases where group|world have perms that the user doesn't, or cases where world has perms that the group doesn't (as in, user:rx, group:rwx, world: rx). This could still break builds where a mode is specified in decimal, but at least there should be some indication of what went wrong...and now they'll know that we're trying to do the right thing. Also, all of the mode parsing has been consolidated into TypeConversionUtils, with a TypeConversionUtilsTest to check my work. Finally, for MASSEMBLY-155, there is a new integration test that verifies its behavior. So, let's try this again: I wanted to call a vote to release a beta version of the new assembly plugin. There are still some outstanding issues (though not as many as jira would have you believe; they just need tests), but I think we're at around 95-99% backward compatibility and the new features seem to be working well. It's been just sitting in SVN for quite awhile now, and many people are using it directly from there. I'd like to provide better support for those people, and start getting more feedback on exactly what's still broken. The change list is pretty large, but is mainly concerned with refactoring the plugin away from the old monolithic approach to one that uses phases to handle the different descriptor sections, along with common task classes to handle behavior shared between phases. Road Map: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11126styleName=Htmlversion=12617 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly- plugin-2.2-beta-1 Staging repository: http://people.apache.org/~jdcasey/stage/repohttp:// people.apache.org/%7Ejdcasey/stage/repo So, let's try 72h +1/+0/-1. Please cast your votes! Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Archetypes] plugin proposition
Hi,
Refactored to use almost the same behaviour as archetype-1.0-alpha-4.
The ones made are:
- goals names create and create-from-project,
- propagate on old code when resolving to an old archetype during create goal.
What is not backward compatible:
- the ${remoteRepositories} property is not used,
- the create-from-project goal doesn't use the old code.
I have uploaded a snapshot on http://snapshots.repository.codehaus.org/
and have a little updated the documentation
(http://mojo.codehaus.org/maven-archetypeng/).
Please have a look and try it.
Yet to be done :
- refactor descriptor with attributes and simplify templating
- generation and creation of multimodule
- use archetype-registry to remember old archetypes and versions
- use archetype-registry to remember the archetype repositories
Far future:
- move archetype-groups from registry to settings
- archetype packaging with site report on required
properties and sample tree of generated files
Regards,
Raphaël
So to summarise the needed actions:
1. backward compatibility of names
2. backward compatibility on old descriptor and downloading
3. backward compat on command line option (-D)
4. backward compat on behaviour (but the prompting is by default
unless called with -B)
Recommended text for 2.0.6 release notes and for email to user group.
[Note, explaination is left to Jason about full impact of MNG-1577] How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: ou can run mvn dependency:analyze on your projects and this will produce output similar to this: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0-SNAPSHOT:compi le [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be upgraded from commons-lang 1.0 to 2.3, commons-digester 1.6 to 1.7 and servlet-api 2.3 to 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. In You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recommended text for 2.0.6 release notes and for email to user group.
Cool, thanks Brian. jason. On 29 Mar 07, at 2:58 PM 29 Mar 07, Brian E. Fox wrote: [Note, explaination is left to Jason about full impact of MNG-1577] How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: ou can run mvn dependency:analyze on your projects and this will produce output similar to this: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0- beta-1:test [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0- SNAPSHOT:compi le [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be upgraded from commons-lang 1.0 to 2.3, commons-digester 1.6 to 1.7 and servlet-api 2.3 to 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. In You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze- mojo.htm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep- mgt- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - 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]
CORRECTED: Recommended text for 2.0.6 release notes and for email to user group.
Corrected text below. Thanks Max. [Note, explaination is left to Jason about full impact of MNG-1577] How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0-SNAPSHOT:compi le [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be downgraded to commons-lang 1.0 from 2.3, commons-digester 1.6 from 1.7 and servlet-api 2.3 from 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. In You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group.
souldn't the plugin be released instead of using a snapshot? On 3/29/07, Brian E. Fox [EMAIL PROTECTED] wrote: Corrected text below. Thanks Max. [Note, explaination is left to Jason about full impact of MNG-1577] How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0-SNAPSHOT:compi le [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be downgraded to commons-lang 1.0 from 2.3, commons-digester 1.6 from 1.7 and servlet-api 2.3 from 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. In You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - 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: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group.
It was released on Tuesday. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Thursday, March 29, 2007 4:23 PM To: Maven Developers List Subject: Re: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group. souldn't the plugin be released instead of using a snapshot? On 3/29/07, Brian E. Fox [EMAIL PROTECTED] wrote: Corrected text below. Thanks Max. [Note, explaination is left to Jason about full impact of MNG-1577] How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:te st [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0-SNAPSHOT:com pi le [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be downgraded to commons-lang 1.0 from 2.3, commons-digester 1.6 from 1.7 and servlet-api 2.3 from 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. In You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.h tm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mg t- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - 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
Re: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group.
then check this line: org.apache.maven.shared:maven-dependency-analyzer:jar:1.0-SNAPSHOT:com On 3/29/07, Brian E. Fox [EMAIL PROTECTED] wrote: It was released on Tuesday. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Thursday, March 29, 2007 4:23 PM To: Maven Developers List Subject: Re: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group. souldn't the plugin be released instead of using a snapshot? On 3/29/07, Brian E. Fox [EMAIL PROTECTED] wrote: Corrected text below. Thanks Max. [Note, explaination is left to Jason about full impact of MNG-1577] How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:te st [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0-SNAPSHOT:com pi le [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be downgraded to commons-lang 1.0 from 2.3, commons-digester 1.6 from 1.7 and servlet-api 2.3 from 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. In You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.h tm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mg t- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - 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.
Bug: Order of Dependencies in ClassPathElement.
Please acknowledge that this is a known bug that the order of dependencies defined in pom.xml is not respected by Maven 2. I have tried using Maven 2.0.4 / Maven 2.0.5 / Maven 2.0.6 on Windows / Linux. Thanks. -- View this message in context: http://www.nabble.com/Bug%3A-Order-of-Dependencies-in-ClassPathElement.-tf3488764s177.html#a9742408 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: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group.
How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0:compile [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be downgraded to commons-lang 1.0 from 2.3, commons-digester 1.6 from 1.7 and servlet-api 2.3 from 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence (was: We're near the release of 1.0 final)
On 29/03/2007, at 7:47 AM, John Casey wrote: I can't say that I care much one way or another, when it comes to moving all doco from the codehaus wiki to cwiki or leaving it as-is...provided the conversion is 100% successful, and cwiki is stable. The stability point is a concern for me, since I've seen some pretty ugly messes with ASF infra in the past. I asked David Blevins and from a technical perspective he recommends using cwiki. He has found it to be sufficiently stable and the volunteers responsive. Of bigger concern to me is the fact that the MAVEN space is such a mess... When we get to that point, I'd be happy to organise and document a structure for it. It's not actually as messy as it looks. One thing that is interesting is that wiki content wouldn't be affected by confluence outages, since it's exported to the static pages...and I'm not sure it's a great idea to have something like setup that between ASF and codehaus...it's only adding moving parts that can fail. Agreed. Is there a reason I should get fired up about either outcome? Because you're fired up about documentation? :) I think everyone agreed the cookbook idea was a good one before, I think this is a concrete step towards making it happen. Anyone else with 2 cents to spare? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Attach support for Maven antlib install/deploy tasks...
... is here:
http://jira.codehaus.org/browse/MANTTASKS-42
I found this issue was related:
http://jira.codehaus.org/browse/MANTTASKS-21
But the attached patches don't really have anything todo with
attaching, only appears to add support to add a type + classifier
information.
* * *
I updated the sample.build.xml to have tests for install/deploy w/
attached. Seems to work fine, I used the maven-2.0.6 tag to pick up
the 2.0.6 artifacts, so it should be compatible with the upcoming
Maven 2.0.6 release.
The test targets look like (just created a dummy file to represent
the .asc to be attached):
8
target name=test-deploy-attached depends=initTaskDefs
echo message=test file=${basedir}/target/sample-build-
test.pom.asc/
artifact:deploy file=sample-build-test.pom
pom file=sample-build-test.pom /
remoteRepository refid=deploy.repository /
attach file=${basedir}/target/sample-build-test.pom.asc
type=pom.asc/
/artifact:deploy
/target
target name=test-install-attached depends=initTaskDefs
echo message=test file=${basedir}/target/sample-build-
test.pom.asc/
artifact:install file=sample-build-test.pom
pom file=sample-build-test.pom /
localRepository refid=local.repository/
attach file=${basedir}/target/sample-build-test.pom.asc
type=pom.asc/
/artifact:install
/target
8
Please take a look. I think this will help some projects, like
Tomcat, get their Ant projects up and going with deployment to the
ASF m2 repos, which now require .asc files along with checksums.
--jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: confluence (was: We're near the release of 1.0 final)
I wish it was all in one place - Maven site. Too many don't know or don't go. If it must reside elsewhere, the link to external site docs must be very prominent. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 4:26 PM To: Maven Developers List Subject: Re: confluence (was: We're near the release of 1.0 final) [snip] Anyone else with 2 cents to spare? - 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: confluence (was: We're near the release of 1.0 final)
That's exactly what this would provide. While I don't propose moving the whole site to it, I think it makes sense as an integrated subsite. Take a look at these examples: http://incubator.apache.org/openejb/ http://incubator.apache.org/openjpa/ http://geronimo.apache.org/ - Brett On 30/03/2007, at 10:27 AM, Jeff Jensen wrote: I wish it was all in one place - Maven site. Too many don't know or don't go. If it must reside elsewhere, the link to external site docs must be very prominent. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 4:26 PM To: Maven Developers List Subject: Re: confluence (was: We're near the release of 1.0 final) [snip] Anyone else with 2 cents to spare? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group.
I added this text to the plugin site here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/prepari ng-dependencies.html -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 5:03 PM To: Maven Developers List Subject: RE: CORRECTED: Recommended text for 2.0.6 release notes and for email to user group. How to prepare your dependencies before updating to Maven 2.0.6: If you have dependencies in dependencyManagement that conflict with transitive dependencies, the fix for MNG-1577 may alter the version you get when running a build with 2.0.6. To ensure a smooth transition, there is a tool to detect these conditions. In your project, run mvn dependency:analyze (be sure to use 2.0.5 or the plugin won't detect mismatches) This will display output similar to below: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7:compile [INFO]junit:junit:jar:3.8.1:test [INFO] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven:maven-model:jar:2.0.5:compile [INFO]org.apache.maven:maven-project:jar:2.0.5:compile [INFO]org.apache.maven.shared:file-management:jar:1.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.5:compile [INFO]org.apache.maven:maven-plugin-api:jar:2.0.5:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test [INFO] org.apache.maven.shared:maven-dependency-analyzer:jar:1.0:compile [INFO] Used undeclared dependencies: [INFO]None [INFO] Unused declared dependencies: [INFO]None [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO] Dependency: commons-lang:commons-lang:jar [INFO] DepMgt : 1.0 [INFO] Resolved: 2.3 [INFO] Dependency: commons-digester:commons-digester:jar [INFO] DepMgt : 1.6 [INFO] Resolved: 1.7 [INFO] Dependency: javax.servlet:servlet-api:jar [INFO] DepMgt : 2.3 [INFO] Resolved: 2.4 [WARNING] Potential problems found in Dependency Management In the sample above, you can see that I am actually getting versions different than what I'm asking for. In 2.0.6, I would suddenly be downgraded to commons-lang 1.0 from 2.3, commons-digester 1.6 from 1.7 and servlet-api 2.3 from 2.4. Depending on the jars and your project, this may manifest as compile errors or runtime errors. When you see these mismatches, the suggested approach is to adjust your dependencyManagement section to have the version you are actually getting (in this case, 2.3,1.7 and 2.4 respectively). Then when you upgrade to 2.0.6, you will be getting the same versions in your build that you currently get in 2.0.5. You should also pay particular attention to the Used Declared dependencies because this is showing that you are using something that isn't declared. The plugin may not detect specific mismatches between dependencyManagement if the dependencies are not specifically declared. Using dependencies in your projects that are not declared is a dangerous proposition as it doesn't provide Maven with the correct information to properly choose the correct version. The recommended fix for this is to add any dependencies that analyze finds to your pom. This goal can also detect conflicts with the dependencyManagement excludes to show where files that are excluded creep back in and to show where individual poms override the dependencyManagement. These things are not directly affected by 2.0.6, but can be handy to know. Read more here: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.htm l http://maven.apache.org/plugins/maven-dependency-plugin/analyze-dep-mgt- mojo.html http://maven.apache.org/plugins/maven-dependency-plugin/usage.html (bottom of the page) After upgrading to 2.0.6, you may want to remove workarounds to MNG-1577 that you have put in place. These usually would have been the introduction of a dependency to your pom that wasn't nessessary simply to override a transitive version. If you have workarounds in your pom, they will show up as Unused declared dependencies. Note that currently the test and runtime dependencies are excluded from the usage analysis. --Brian - 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: confluence (was: We're near the release of 1.0 final)
So what are the plans for what each would contain - Maven site and wiki? Would Maven site contain only the generated tool docs (e.g. reports like Javadoc, PMD) and would the wiki contain only hand-written user docs? What I can't understand by just looking at those examples is how was all that content created? Did a mvn site run gen some and the hand created wiki pages link to it? No argument - those are nice sites. Just not understanding yet the Maven plans for wiki/site usage. My fear, obviously, is continued separate works, as some people I helped with Maven have a not happy-out-of-the-box experience, which includes scattered docs - I always have to give them multiple URLs for info and/or they keep Googling for answers. If you plan to integrate Maven site and the wiki so well like the examples you provided, then the user sees them as one source. Very nice. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 7:34 PM To: Maven Developers List Subject: Re: confluence (was: We're near the release of 1.0 final) That's exactly what this would provide. While I don't propose moving the whole site to it, I think it makes sense as an integrated subsite. Take a look at these examples: http://incubator.apache.org/openejb/ http://incubator.apache.org/openjpa/ http://geronimo.apache.org/ - Brett On 30/03/2007, at 10:27 AM, Jeff Jensen wrote: I wish it was all in one place - Maven site. Too many don't know or don't go. If it must reside elsewhere, the link to external site docs must be very prominent. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 4:26 PM To: Maven Developers List Subject: Re: confluence (was: We're near the release of 1.0 final) [snip] Anyone else with 2 cents to spare? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The Maven PMC welcomes Brian Fox
Hi all, The Maven PMC has voted to add Brian Fox to the PMC. Please join me in welcoming him! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence (was: We're near the release of 1.0 final)
On 30/03/2007, at 11:19 AM, Jeff Jensen wrote: So what are the plans for what each would contain - Maven site and wiki? Would Maven site contain only the generated tool docs (e.g. reports like Javadoc, PMD) and would the wiki contain only hand-written user docs? I'd see the current site staying as it is (although we could work on better provision of the tools stuff again). We would have cookbook subsections of the site which would be the MAVENUSER and similar spaces drawn in under the user guides section. The MAVEN space would be arranged and brought under the developer documentation section and used for design proposals. What I can't understand by just looking at those examples is how was all that content created? Did a mvn site run gen some and the hand created wiki pages link to it? It's all created in confluence, and using the autoexport plugin it regularly spits out static html. They use a template to produce the look and feel. If you hit the edit links you can see the original confluence system. No argument - those are nice sites. Just not understanding yet the Maven plans for wiki/site usage. My fear, obviously, is continued separate works, as some people I helped with Maven have a not happy-out-of- the-box experience, which includes scattered docs - I always have to give them multiple URLs for info and/or they keep Googling for answers. If you plan to integrate Maven site and the wiki so well like the examples you provided, then the user sees them as one source. Very nice. That's the theory :) Thanks for the feedback! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Maven PMC welcomes Brian Fox
Congrats :-) --jason On Mar 29, 2007, at 6:21 PM, Brett Porter wrote: Hi all, The Maven PMC has voted to add Brian Fox to the PMC. Please join me in welcoming him! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence (was: We're near the release of 1.0 final)
FYI, this is a better example of a sub-site: http://geronimo.apache.org/xbean This is from the XB space which we export into this directory under our TLD. We used to do this before we had used the GMOxSITE space for the site content, though now we use both. Soon we will be stitching together a few spaces so that *most* content we have stored in cwiki will be exported to a location under http:// geronimo.apache.org. --jason On Mar 29, 2007, at 5:33 PM, Brett Porter wrote: That's exactly what this would provide. While I don't propose moving the whole site to it, I think it makes sense as an integrated subsite. Take a look at these examples: http://incubator.apache.org/openejb/ http://incubator.apache.org/openjpa/ http://geronimo.apache.org/ - Brett On 30/03/2007, at 10:27 AM, Jeff Jensen wrote: I wish it was all in one place - Maven site. Too many don't know or don't go. If it must reside elsewhere, the link to external site docs must be very prominent. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 4:26 PM To: Maven Developers List Subject: Re: confluence (was: We're near the release of 1.0 final) [snip] Anyone else with 2 cents to spare? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2477Implement repository security improvements for verification of downloaded artifacts http://jira.codehaus.org/browse/MNG-2477 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Maven PMC welcomes Brian Fox
Congratulations Brian, great to have you aboard. :) -j On 3/29/07, Jason Dillon [EMAIL PROTECTED] wrote: Congrats :-) --jason On Mar 29, 2007, at 6:21 PM, Brett Porter wrote: Hi all, The Maven PMC has voted to add Brian Fox to the PMC. Please join me in welcoming him! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-enforcer-plugin
I reimplemented the enforcer plugin along the lines of Jason D's idea[1] and I think this is a much more extensible solution. The rules now implement a common interface in shared/maven-enforcer-rule-api and users will be able to inject their own custom rules. By defining the interface external to the plugin, the Lint idea that JVZ put out[2] should be able to invoke these rules, as will IDEs. Please take a look at the site to see how the plugin works and provide any suggestions. I still need to document how to create your own rules and inject them, but I believe everything else is covered. A snapshot of 1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is already using it) http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed, may take a while to refresh) [1] http://www.nabble.com/maven-enforcer-plugin-tf3431452s177.html#a9565974 [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545 -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 12:05 AM To: Maven Developers List Subject: maven-enforcer-plugin There is a new plugin that I'd like to get some feedback on, particularly on non-windows os's and the unit tests. The maven-enforcer-plugin picks up where prerequisites leaves off and allows control over the maven, jdk and os versions of a build. This plugin was initially conceived here: http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177 .html#a8979318 And here: http://www.nabble.com/Why-is-prerequisites-not-inherited--tf3236197s177. html#a9016296 1.0-alpha-1-SNAPSHOT is deployed and the site is here: http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so give it a little bit to completely update) If all goes well and no major issues are uncovered, then I think it's ready for staging and a vote. Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Attempt 2: Release 2.2-beta-1 of maven-assembly-plugin
John, I'm building a 100mb assembly and the build is blowing up with an OOME. I upped the limit to 128m and instead of that problem it completely hangs down the track (kill -9). I'm trying again with 256m now. If I build with 2.1 again, there are no problems. I am able to switch back and forth and get consistent results: dead with 2.2, fine with 2.1. Oddly, though, I had no such problems with 2.2 yesterday. Did anything change overnight that might leak memory? - Brett On 30/03/2007, at 3:50 AM, John Casey wrote: This is the second attempt, after fixing: * http://jira.codehaus.org/browse/MASSEMBLY-155 * http://jira.codehaus.org/browse/MASSEMBLY-192 * [file and directory mode parsing] WRT mode parsing, everything is now parsed using Integer.parseInt ( mode, 8 ). If this results in a NumberFormatException, that is wrapped in an AssemblyFormattingException that indicates that it was a file/dir mode that failed to parse. If the parse succeeds, the resulting mode int is checked for sanity. That is, cases where group|world have perms that the user doesn't, or cases where world has perms that the group doesn't (as in, user:rx, group:rwx, world: rx). This could still break builds where a mode is specified in decimal, but at least there should be some indication of what went wrong...and now they'll know that we're trying to do the right thing. Also, all of the mode parsing has been consolidated into TypeConversionUtils, with a TypeConversionUtilsTest to check my work. Finally, for MASSEMBLY-155, there is a new integration test that verifies its behavior. So, let's try this again: I wanted to call a vote to release a beta version of the new assembly plugin. There are still some outstanding issues (though not as many as jira would have you believe; they just need tests), but I think we're at around 95-99% backward compatibility and the new features seem to be working well. It's been just sitting in SVN for quite awhile now, and many people are using it directly from there. I'd like to provide better support for those people, and start getting more feedback on exactly what's still broken. The change list is pretty large, but is mainly concerned with refactoring the plugin away from the old monolithic approach to one that uses phases to handle the different descriptor sections, along with common task classes to handle behavior shared between phases. Road Map: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11126styleName=Htmlversion=12617 Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly- plugin-2.2-beta-1 Staging repository: http://people.apache.org/~jdcasey/stage/repohttp:// people.apache.org/%7Ejdcasey/stage/repo So, let's try 72h +1/+0/-1. Please cast your votes! Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
