Re: [VOTE] Release Apache Maven 3.0-beta-3 (take 2)
+1 (non binding) works fine with gwt-maven plugin 2010/9/2 Hervé BOUTEMY herve.bout...@free.fr +1 Hervé Le lundi 30 août 2010, Benjamin Bentmann a écrit : Hi, what's a better start for a week than a new fresh release :-) ? So here we go! Apart from another few regression fixes, this release includes Guice and Aether [0] and shall help to get some more community testing on these new components. Overall, we solved 19 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16 681 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500st atus=1 Staging repo: https://repository.apache.org/content/repositories/maven-157/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-157/org/apache/mav en/apache-maven/3.0-beta-3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin [0] http://github.com/sonatype/sonatype-aether - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-assembly-plugin 2.2-beta-X: dependencySet is now including project artifact in outputDirectory
I can't tell exactly when this occurred since we forked an internal
release of 2.2 at r487459 where we have applied patches for
* http://jira.codehaus.org/browse/MASSEMBLY-118
* http://jira.codehaus.org/browse/MASSEMBLY-166
* http://jira.codehaus.org/browse/MASSEMBLY-170
I suspect beta-1 has this new feature but I can't find it in the ChangeLog.
Our descriptor uses
dependencySets
dependencySet
outputDirectorylib/outputDirectory
unpackfalse/unpack
/dependencySet
/dependencySets
And previously the lib directory would have all the project's
dependencies copied except for the project's main artifact.
We would use
fileSets
fileSet
directorytarget/directory
outputDirectory/outputDirectory
includes
include${artifactId}-${version}.jar/include
/includes
/fileSet
/fileSets
to copy this into the root of the archive.
We are now finding that the main project artifact is also included in
the dependencySet and thus appearing in lib/.
Can anyone remember when this was changed so I can look up the
reasoning and work out what we should be doing?
I suspect we need to add an exclude...
Suggestions most welcome.
Barrie
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin 2.2-beta-X: dependencySet is now including project artifact in outputDirectory
In your dependencySet, specify the following:
useProjectArtifactfalse/useProjectArtifact
That should take care of things.
On 9/2/10 3:21 AM, Barrie Treloar wrote:
I can't tell exactly when this occurred since we forked an internal
release of 2.2 at r487459 where we have applied patches for
* http://jira.codehaus.org/browse/MASSEMBLY-118
* http://jira.codehaus.org/browse/MASSEMBLY-166
* http://jira.codehaus.org/browse/MASSEMBLY-170
I suspect beta-1 has this new feature but I can't find it in the ChangeLog.
Our descriptor uses
dependencySets
dependencySet
outputDirectorylib/outputDirectory
unpackfalse/unpack
/dependencySet
/dependencySets
And previously the lib directory would have all the project's
dependencies copied except for the project's main artifact.
We would use
fileSets
fileSet
directorytarget/directory
outputDirectory/outputDirectory
includes
include${artifactId}-${version}.jar/include
/includes
/fileSet
/fileSets
to copy this into the root of the archive.
We are now finding that the main project artifact is also included in
the dependencySet and thus appearing in lib/.
Can anyone remember when this was changed so I can look up the
reasoning and work out what we should be doing?
I suspect we need to add an exclude...
Suggestions most welcome.
Barrie
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin 2.2-beta-X: dependencySet is now including project artifact in outputDirectory
BTW, this was added for http://jira.codehaus.org/browse/MASSEMBLY-197,
in revId 549995.
-j
On 9/2/10 10:18 AM, John Casey wrote:
In your dependencySet, specify the following:
useProjectArtifactfalse/useProjectArtifact
That should take care of things.
On 9/2/10 3:21 AM, Barrie Treloar wrote:
I can't tell exactly when this occurred since we forked an internal
release of 2.2 at r487459 where we have applied patches for
* http://jira.codehaus.org/browse/MASSEMBLY-118
* http://jira.codehaus.org/browse/MASSEMBLY-166
* http://jira.codehaus.org/browse/MASSEMBLY-170
I suspect beta-1 has this new feature but I can't find it in the
ChangeLog.
Our descriptor uses
dependencySets
dependencySet
outputDirectorylib/outputDirectory
unpackfalse/unpack
/dependencySet
/dependencySets
And previously the lib directory would have all the project's
dependencies copied except for the project's main artifact.
We would use
fileSets
fileSet
directorytarget/directory
outputDirectory/outputDirectory
includes
include${artifactId}-${version}.jar/include
/includes
/fileSet
/fileSets
to copy this into the root of the archive.
We are now finding that the main project artifact is also included in
the dependencySet and thus appearing in lib/.
Can anyone remember when this was changed so I can look up the
reasoning and work out what we should be doing?
I suspect we need to add an exclude...
Suggestions most welcome.
Barrie
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven 3.0-beta-3 (take 2)
Hi, Despite a few known bugs in the code, I consider the vote has passed with the following result: +1 (binding): Benjamin Bentmann, Jason van Zyl, Brian Fox, Emmanuel Venisse, Arnaud Héritier, Oliver Lamy, Kristian Rosenvold +1 (non-binding): Paul Merlin, Stephen Connolly, Tony Chemit, Igor Fedorenko, Baptiste Mathus, Oleg Gusakov, Marc Derricutt, Jeff Jensen, I will promote the artifacts to the central repository and continue with the release. Thanks for all the feedback! Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Apache Maven 3.0-beta-3 (take 2)
Sorry, for the late response. I'm running into a few issues building the JBoss App server with beta-3. I'm currently trying to narrow down the issues enough to create small test projects/test cases. The issues seem to be related to very specific edge cases, so I don't think they are things to hold up the release anyway. But I'll try to document them in jiras and hopefully they can be fixed for the next beta. Here are two issues I tried to narrow down related to the dependency management. http://jira.codehaus.org/browse/MNG-4789 http://jira.codehaus.org/browse/MNG-4790 The order of elements on the compile classpath is different with this release, is that by design? On 09/02/2010 09:38 AM, Benjamin Bentmann wrote: Hi, Despite a few known bugs in the code, I consider the vote has passed with the following result: +1 (binding): Benjamin Bentmann, Jason van Zyl, Brian Fox, Emmanuel Venisse, Arnaud Héritier, Oliver Lamy, Kristian Rosenvold +1 (non-binding): Paul Merlin, Stephen Connolly, Tony Chemit, Igor Fedorenko, Baptiste Mathus, Oleg Gusakov, Marc Derricutt, Jeff Jensen, I will promote the artifacts to the central repository and continue with the release. Thanks for all the feedback! Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven 3.0-beta-3 Released
The Maven team is pleased to announce the release of Apache Maven 3.0-beta-3. Maven is a project comprehension and build tool, designed to simplify the process of maintaining a healthy development lifecycle for your project. You can read more here: http://maven.apache.org/ Downloads of source and binary distributions are listed in our download section: http://maven.apache.org/download.html A major goal of Maven 3.0 is to be compatible, to the extent possible, with existing plugins and projects designed for Maven 2.x. Users interested in testing this beta release should have a glance at the compatibility notes for known differences between Maven 3.0 and Maven 2.x: http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html This new beta version features a reworked repository system (Aether) and a new IoC container (based on Guice). We are already aware of a few regressions since 3.0-beta-2 due to these new components so we kindly ask users of the new beta to check our issue tracker for duplicate issues before filling new ones. The list of issues filled against the new 3.0-beta-3 can be seen via http://jira.codehaus.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+MNG+AND+affectedVersion+%3D+%223.0-beta-3%22runQuery=trueclear=true Nevertheless, we highly appreciate feedback from our users on this new release to help us track down any other potential issues. If you encounter unexpected problems while using Maven 3.0-beta-3, please feel free to contact us via the Maven developer list: http://maven.apache.org/mail-lists.html Release Notes - Maven 2 3 - Version 3.0-beta-3 ** Bug * [MNG-2686] - POM dependency scope auto-downgrades from provided to test * [MNG-4690] - Transitive dependency lost when included another dependency * [MNG-4745] - [regression] Maven does not check for plugin updates, even if forced via -U * [MNG-4755] - Version ranges cannot be resolved against mirror if a local artifact is present * [MNG-4761] - Plugin-level dependency scope causes some plugin classpaths to be incorrect * [MNG-4765] - Failing to determine java version for profile * [MNG-4767] - Regression in parsing command-line arguments including variables * [MNG-4768] - Depending on declaration order, nearest matching version does not win when version range is involved in conflict * [MNG-4769] - Regression: enabled flag for central cannot be overriden * [MNG-4771] - [regression] Plugin prefix resolution ignores enabled flags on repository * [MNG-4772] - [regression] Plugin version resolution ignores enabled flags on repository * [MNG-4773] - Stack trace printed from MavenProject.getParent * [MNG-4775] - Outdated NOTICE.txt * [MNG-4776] - NPE during build from parent but not from child * [MNG-4779] - NullPointerException thrown during dependency resolution when dependency with range occurs more than once in the dirty tree * [MNG-4781] - Can't deploy to Nexus staging repository ** Improvement * [MNG-4749] - Move from Plexus to Guice as IoC container * [MNG-4782] - Automatically dump stack trace in case of internal Maven error ** New Feature * [MNG-4756] - Aether integration Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Welcome Kristian Rosenvold to the Maven PMC
This is a little delayed, but still deserved. A few weeks ago, Kristian joined us on the Maven PMC. He's been driving a lot of interesting work in Maven 3 to support parallel builds. If you haven't tried that out yet, please do and send some feedback. Welcome Kristian! --Brian Fox Maven PMC Chair - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Kristian Rosenvold to the Maven PMC
Congrats to Kristian!! On Thu, Sep 2, 2010 at 6:19 PM, Brian Fox bri...@infinity.nu wrote: This is a little delayed, but still deserved. A few weeks ago, Kristian joined us on the Maven PMC. He's been driving a lot of interesting work in Maven 3 to support parallel builds. If you haven't tried that out yet, please do and send some feedback. Welcome Kristian! --Brian Fox Maven PMC Chair - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Setting goals for upcoming releases
Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. So far the feedback on the betas has been good but fairly limited. I think that without a clear plan, and our history with this mammoth release, people are probably reluctant to spend a lot of time testing each beta. In the past we've been successful pushing out release candidate builds and involving the user list. If we start that soonish, there should be plenty of time to uncover and fix regressions, especially if everyone pitches in. There's even time to cut another beta before we launch into the RCs if it's needed. So first of all, Benjamin, Herve, Kristian you've collectively done the majority of the work in M3 recently. Do you think the above is achievable and desirable? What does everyone else think? Secondly, For me personally, I'm going to commit to get the Maven Index code committed and to push updated releases of the dependency and enforcer plugins before ApacheCon. Anyone else want to ante up for some chunk of work and get things rolling? Thanks, Brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin 2.2-beta-X: dependencySet is now including project artifact in outputDirectory
On Thu, Sep 2, 2010 at 11:48 PM, John Casey jdca...@commonjava.org wrote: In your dependencySet, specify the following: useProjectArtifactfalse/useProjectArtifact Cheers. Did I just miss this in the documentation (other than in the configuration page)? I've had another look around the doco now that I know what to look for and can't see it. I'd like to add it to http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html since it has an example of dependencySet and exclusion. Your thoughts? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 3 goals for release questions
I didn't want to hijack the other thread with my questions after reading https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html Caching of Artifact Resolution Errors Marker files are great! Is there any documentation on what they are? The maven-eclipse-plugin has the hack I added with marker files. Standardizing on the marker file will be the first thing I do once I know what do use. Automatic Plugin Version Resolution Now that plugin versions are expected to be locked down in the pom has the documentation been updated to describe how to manage the version upgrades? For example there was a question on the list a while ago about a tool to check whether new versions of dependencies were available and to provide a report. Something like that for plugins would also be needed. The benefit of not locking them down was I got the latest releases without doing anything. The downside was the build was not reproducible and if the new plugin had bugs I would need to lock down the plugin to the previous working version. Some guidance on how to manage this lifecyle would be appreciated by less experienced build managers. Plugin Repositories Maven 3 aims at supporting a stricter separation between the compile/runtime/test dependencies Has the http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Dependency Scope been modified to define test compile and test runtime? Without something like this dependency:analyze has false positives with test scopes and a lot of the benefit of checking is lost. Is this possible and on the feature list? Cheers - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Setting goals for upcoming releases
On Fri, Sep 3, 2010 at 9:04 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. So far the feedback on the betas has been good but fairly limited. I think that without a clear plan, and our history with this mammoth Is it then time to add Try Maven 3 Beta to the front page and include some guidance documentation for those that want to try it out? Its a bit hidden at the moment. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Setting goals for upcoming releases
On Thu, Sep 2, 2010 at 8:40 PM, Barrie Treloar baerr...@gmail.com wrote: On Fri, Sep 3, 2010 at 9:04 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. So far the feedback on the betas has been good but fairly limited. I think that without a clear plan, and our history with this mammoth Is it then time to add Try Maven 3 Beta to the front page and include some guidance documentation for those that want to try it out? Its a bit hidden at the moment. Can't hurt. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Setting goals for upcoming releases
I think trying to release 3.0 sooner, and then sticking to 6 week release cycles would be a better use of time. We're going to fix anything that arises but I don't believe there will be widespread testing until 3.0 is released, and I don't believe many will pick up 3.x in large-scale production environments until 3.1. I think the faster we get 3.0 out the better. Shoot for October 1st, and then have the 3.0.1 release with fixes for the first wave of issues raised in mid-November. On Sep 2, 2010, at 7:34 PM, Brian Fox wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. So far the feedback on the betas has been good but fairly limited. I think that without a clear plan, and our history with this mammoth release, people are probably reluctant to spend a lot of time testing each beta. In the past we've been successful pushing out release candidate builds and involving the user list. If we start that soonish, there should be plenty of time to uncover and fix regressions, especially if everyone pitches in. There's even time to cut another beta before we launch into the RCs if it's needed. So first of all, Benjamin, Herve, Kristian you've collectively done the majority of the work in M3 recently. Do you think the above is achievable and desirable? What does everyone else think? Secondly, For me personally, I'm going to commit to get the Maven Index code committed and to push updated releases of the dependency and enforcer plugins before ApacheCon. Anyone else want to ante up for some chunk of work and get things rolling? Thanks, Brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: Setting goals for upcoming releases
When 3.0 is released, is 2.2 pretty much a dead branch? I have no problem with that btw :-) On Thu, Sep 2, 2010 at 7:44 PM, Jason van Zyl ja...@sonatype.com wrote: I think trying to release 3.0 sooner, and then sticking to 6 week release cycles would be a better use of time. We're going to fix anything that arises but I don't believe there will be widespread testing until 3.0 is released, and I don't believe many will pick up 3.x in large-scale production environments until 3.1. I think the faster we get 3.0 out the better. Shoot for October 1st, and then have the 3.0.1 release with fixes for the first wave of issues raised in mid-November. On Sep 2, 2010, at 7:34 PM, Brian Fox wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. So far the feedback on the betas has been good but fairly limited. I think that without a clear plan, and our history with this mammoth release, people are probably reluctant to spend a lot of time testing each beta. In the past we've been successful pushing out release candidate builds and involving the user list. If we start that soonish, there should be plenty of time to uncover and fix regressions, especially if everyone pitches in. There's even time to cut another beta before we launch into the RCs if it's needed. So first of all, Benjamin, Herve, Kristian you've collectively done the majority of the work in M3 recently. Do you think the above is achievable and desirable? What does everyone else think? Secondly, For me personally, I'm going to commit to get the Maven Index code committed and to push updated releases of the dependency and enforcer plugins before ApacheCon. Anyone else want to ante up for some chunk of work and get things rolling? Thanks, Brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Setting goals for upcoming releases
When 3.0 is released, is 2.2 pretty much a dead branch? I have no problem with that btw :-) Isn't it essentially dead now? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Setting goals for upcoming releases
Personally I'd still like to see some resolution to the problems introduced by the version range resolution change ( no more -SNAPSHOT resolution except for on the bounds ). On one hand I applaud the change from a release standpoint, but it currently causes issues for our integration build processes. Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Each time I've brought the subject up I don't seem to see any traction or replies/discussion come along, is there room to address this somehow? -- Pull me down under... On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door.
snapshot range changes in m3
Forking this discussion: On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt m...@talios.com wrote: Personally I'd still like to see some resolution to the problems introduced by the version range resolution change ( no more -SNAPSHOT resolution except for on the bounds ). On one hand I applaud the change from a release standpoint, but it currently causes issues for our integration build processes. Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Not possible for 3.0 Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky. Each time I've brought the subject up I don't seem to see any traction or replies/discussion come along, is there room to address this somehow? -- Pull me down under... On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-assembly-plugin 2.2-beta-X: dependencySet is now including project artifact in outputDirectory
On Fri, Sep 3, 2010 at 9:46 AM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Sep 2, 2010 at 11:48 PM, John Casey jdca...@commonjava.org wrote: In your dependencySet, specify the following: useProjectArtifactfalse/useProjectArtifact Cheers. Did I just miss this in the documentation (other than in the configuration page)? I've had another look around the doco now that I know what to look for and can't see it. I'd like to add it to http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html since it has an example of dependencySet and exclusion. Your thoughts? I've added to that page - since it looks like I wrote it in the first place :) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (24 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-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
http://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-4656Declarative plugins similar to jsp tags or jsf composites
http://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
http://jira.codehaus.org/browse/MNG-4713
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468
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-416 best practices: multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for properties and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
You may edit this subscription at:
http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Setting goals for upcoming releases
I think i agree with Jason on shooting maven 3.0 out to public as soon as you can, however the dev team might want fix up blocking bugs which prevent user like me from using maven 3 one of the blocking bug for me is http://jira.codehaus.org/browse/MNG-4788 Thanks -Dan On Thu, Sep 2, 2010 at 6:12 PM, Mark Derricutt m...@talios.com wrote: Personally I'd still like to see some resolution to the problems introduced by the version range resolution change ( no more -SNAPSHOT resolution except for on the bounds ). On one hand I applaud the change from a release standpoint, but it currently causes issues for our integration build processes. Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Each time I've brought the subject up I don't seem to see any traction or replies/discussion come along, is there room to address this somehow? -- Pull me down under... On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: snapshot range changes in m3
Any pointers to where in the code base I should start looking/hacking if I wanted to try and write such a patch? As I'm the main one arguing for this improvement, I'm willing to at least try and solve it :) -- Pull me down under... On Fri, Sep 3, 2010 at 1:27 PM, Brian Fox bri...@infinity.nu wrote: Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky.
Re: snapshot range changes in m3
I'm concerned by this fix too. Here are my thought for now: the fix should not have been done in VersionRange but in a version conflict resolution phase, since a range is a mathematical notion we can't alter. but I didn't have time yet to transform these thoughts in code... Regards, Hervé Le vendredi 03 septembre 2010, Brian Fox a écrit : Forking this discussion: On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt m...@talios.com wrote: Personally I'd still like to see some resolution to the problems introduced by the version range resolution change ( no more -SNAPSHOT resolution except for on the bounds ). On one hand I applaud the change from a release standpoint, but it currently causes issues for our integration build processes. Two options come to mind: 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be considered kosher for resolution Option 1 would probably require some form of POM change as I don't think the resolution part of a configurable plugin, so most likely can't be done. Not possible for 3.0 Option 2 should be fine, as when releasing an individual artifact, nothing external would be in the reactor, unless it was part of the build chain, so no extraneous -SNAPSHOTs would be considered. This should give a fairly good compromise between fixing ranges for release and not breaking existing builds. Seems logical to me, not sure how much work that is to fix, but patches would be a good way to ensure this gets in. Certainly I could see this being a problem that's worth trying to address prior to M3.0 if it's not risky. Each time I've brought the subject up I don't seem to see any traction or replies/discussion come along, is there room to address this somehow? -- Pull me down under... On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox bri...@infinity.nu wrote: Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty safely call it feature complete. I'd like to propose a few goals to get some things done. We have ApacheCon coming up the first week of November, and it would be great to set that as a target to get Maven 3.0 out the door. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
