[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (28 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-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 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-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 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-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-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-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-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-868 Use uniform format for and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 You may edit this subscription at: http://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Fri, Jun 12, 2009 at 12:11 AM, John Casey wrote: > I had to include these files for the recent maven-assembly-plugin release. > It was fairly simple, just take a look at this: > > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/assembly/source-release.xml Be aware than under Maven 2.0.9 and windows that I had to use hard coded paths. Interpolated values did not get replaced correctly (i.e. the paths were \a\windows\path instead of a Java path and therefore replacements are failing) See http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/assemble/source-release.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Jun 11, 2009, at 9:56 AM, David Jencks wrote: On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencks wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - > Maybe you could point to some documentation that makes your point > that the Apache svn repository is itself a distribution subject to > LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. And one more thing :-D Also, in general the LICENSE and NOTICE files apply to what's actually in the artifact. So for the source-archive it's for the actual source code in svn and shouldn't include any stuff for other code that may get into binary artifacts by shading, unpacking, copying, generating, including, etc etc. that the binary artifact legal files have to talk about. I think it would be too confusing to try to generate separate files for the source and binary artifacts. thanks david jencks thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey > wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter > wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-
Re: Update on ASF Release requirements
Well, I'm not sure what to say about that. I guess I could say if it's not on the release docs, it's not policy? It's a little frustrating to constantly chase a standard that isn't documented and which there are many opinions of. I'll solve this particular problem of the source release for now. I haven't built up the motivation to open yet another open ended discussion to get something agreed upon after the last fiasco to be honest. On Thu, Jun 11, 2009 at 12:56 PM, David Jencks wrote: > > On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: > >> On Thu, Jun 11, 2009 at 4:22 AM, David Jencks >> wrote: >>> >>> On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: >>> Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. >>> >>> I don't have the quote handy but Roy stated pretty clearly that expected >>> checkout roots are sufficiently distribution-like to be required to have >>> LICENSE and NOTICE files in svn. >>> >> >> I don't recall anything like that, in fact I understood the opposite, >> that the svn roots are not sufficient to be source releases. If that's >> the case, they can't be considered distributions and thus don't fall >> under the license and notice requirements. > > There's a very long thread in jan 2008 I'm not a master of mail archives > but it's here > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread > > LICENSE and NOTICE files and SVN > > and a particularly relevant post > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e > > - >> Maybe you could point to some documentation that makes your point >> that the Apache svn repository is itself a distribution subject to >> LICENSE and NOTICE requirements. > > The NOTICE file exists to fulfill our obligations under our license > and the licenses of any third-party code that we redistribute. > We try to be as proactive about that as possible. The NOTICE is > in subversion because the board added a notice that all of our > projects must carry. It needs to be in subversion when a > third-party something that requires such a notice is also within > subversion. Finally, each release package's NOTICE must reflect > all of the required notices of all of the parts within that package. > - > > Given this I think it's more in line with apache policy to fail if the > LICENSE/NOTICE files are missing than to try to guess at what should be in > and add them. > > thanks > david jencks > >> >> >>> So I think that verifying that the LICENSE and NOTICE files are there is >>> enough, you don't need to add them. >>> >>> thanks >>> david jencks >>> I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: > > Just to bring the thread back up in light of the recent discussions of > plugin releases: > John has taken over the assembly release that contains the fix I put in > for > the ASF stuff. I've been travelling a lot the past two weeks and > haven't > progressed much on the poms. Tomorrow or monday I should have time to > take > the latest assembly stage and get the apache assembly descriptor and > all > the > poms updated and tested out. > Note that the work we are doing here is to make it easier to define > this > for > all maven (and later asf) projects and be inherited correctly. This > does > not > mean that all pending releases must be blocked waiting for these > changes. > You can make a source release quite easily with the existing plugin > versions. > It's also worth nothing that now we know about the requirement, we must > have > a source release, ignoring the requirement simply because we didn't > know > it > was a requirement in the past isn't an option. > > On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: >> >> >> On Wed, May 27, 2009 at 12:25 PM, John Casey >> wrote: >>> >>> >>> Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter wrote: > On 26/05/2009, at 11:11 PM, Brian Fox wrote: > > We're fixing the directoryscanner to allow regular expressions in > addition >> >> to the ant syntax. >> > Cool, but that's another release in the chain, right? > It's already to go, John is staging it now. >>> >>> *Ahem* I'm still troubleshooting an IT issue dealing with these >>> regexes, >>> so once that's
Re: svn commit: r781123 - in /maven/components/trunk/maven-model-builder/src/main/java/org/apache/maven/model/interpolation: BuildTimestampValueSource.java PathTranslatingPostProcessor.java
On 11-Jun-09, at 6:47 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
I just did this to the request before processing:
request.getProperties().put( "${build.timestamp}", new
SimpleDateFormat( "MMdd-
hhmm" ).format( request.getStartTime() ) );
The problem with this approach is that the format should be
customizable by a project property.
You missed the second part of my message. I agree with you.
"some declarative way to insert properties without having to create
new classes would be nice"
Benjamin
-
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
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
--
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencks wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - > Maybe you could point to some documentation that makes your point > that the Apache svn repository is itself a distribution subject to > LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey > wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr
Re: svn commit: r783525 - /maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java
On 11-Jun-09, at 8:53 AM, Lukas Theussl wrote: Hi Olivier, How does this relate to MNG-3402? This doesn't relate to anything in 3.x because it's not going to be an issue because no doxia classes will be distributed with 3.x. Not sure what you guys are planning for 3.x. Just wondering because we had a lot of discussions about this issue in the past wrt Doxia release plan [1], and from other peoples' comments I always got the impression that it will lead to trouble... even though I never noticed anything myself. -Lukas [1] http://www.nabble.com/MNG-3402-tt17207692.html ol...@apache.org wrote: Author: olamy Date: Wed Jun 10 21:30:40 2009 New Revision: 783525 URL: http://svn.apache.org/viewvc?rev=783525&view=rev Log: don't filter doxia-sink-api. users will be still able to run : mvn site:site Modified: maven/components/trunk/maven-core/src/main/java/org/apache/maven/ DefaultArtifactFilterManager.java Modified: maven/components/trunk/maven-core/src/main/java/org/ apache/maven/DefaultArtifactFilterManager.java URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java?rev=783525&r1=783524&r2=783525&view=diff = = = = = = = = = = --- maven/components/trunk/maven-core/src/main/java/org/apache/ maven/DefaultArtifactFilterManager.java (original) +++ maven/components/trunk/maven-core/src/main/java/org/apache/ maven/DefaultArtifactFilterManager.java Wed Jun 10 21:30:40 2009 @@ -54,7 +54,7 @@ artifacts.add( "classworlds" ); artifacts.add( "plexus-classworlds" ); artifacts.add( "commons-cli" ); -artifacts.add( "doxia-sink-api" ); +//artifacts.add( "doxia-sink-api" ); artifacts.add( "jsch" ); artifacts.add( "maven-artifact" ); artifacts.add( "maven-artifact-manager" ); - 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 http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r783525 - /maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java
There's nothing Doxia specific in the core, that was just a lingering element in the POM. Plan in a nutshell is that the entire existing reporting mechanism will be encapsulated in the site plugin and I will provide any hooks in the lifecycle to make it work. The mixture of reports and plugins caused such a massive amount of pollution it made it impossible to generalize the plugin manager. It was just a huge mess. Everything has to be extensible including reporting and it can all be bundled up in a plugin. One of the requirements for the release of 3.0 is to have the infrastructure to support the current reporting system as a plugin. I can make a first pass at the plugin and then you guys can pick it up. On 11-Jun-09, at 8:53 AM, Lukas Theussl wrote: Hi Olivier, How does this relate to MNG-3402? Just wondering because we had a lot of discussions about this issue in the past wrt Doxia release plan [1], and from other peoples' comments I always got the impression that it will lead to trouble... even though I never noticed anything myself. -Lukas [1] http://www.nabble.com/MNG-3402-tt17207692.html ol...@apache.org wrote: Author: olamy Date: Wed Jun 10 21:30:40 2009 New Revision: 783525 URL: http://svn.apache.org/viewvc?rev=783525&view=rev Log: don't filter doxia-sink-api. users will be still able to run : mvn site:site Modified: maven/components/trunk/maven-core/src/main/java/org/apache/maven/ DefaultArtifactFilterManager.java Modified: maven/components/trunk/maven-core/src/main/java/org/ apache/maven/DefaultArtifactFilterManager.java URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java?rev=783525&r1=783524&r2=783525&view=diff = = = = = = = = = = --- maven/components/trunk/maven-core/src/main/java/org/apache/ maven/DefaultArtifactFilterManager.java (original) +++ maven/components/trunk/maven-core/src/main/java/org/apache/ maven/DefaultArtifactFilterManager.java Wed Jun 10 21:30:40 2009 @@ -54,7 +54,7 @@ artifacts.add( "classworlds" ); artifacts.add( "plexus-classworlds" ); artifacts.add( "commons-cli" ); -artifacts.add( "doxia-sink-api" ); +//artifacts.add( "doxia-sink-api" ); artifacts.add( "jsch" ); artifacts.add( "maven-artifact" ); artifacts.add( "maven-artifact-manager" ); - 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 http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r781123 - in /maven/components/trunk/maven-model-builder/src/main/java/org/apache/maven/model/interpolation: BuildTimestampValueSource.java PathTranslatingPostProcessor.java
Jason van Zyl wrote:
I just did this to the request before processing:
request.getProperties().put( "${build.timestamp}", new
SimpleDateFormat( "MMdd-hhmm" ).format( request.getStartTime() ) );
The problem with this approach is that the format should be customizable
by a project property.
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
I had to include these files for the recent maven-assembly-plugin release. It was fairly simple, just take a look at this: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/assembly/source-release.xml -john Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Release Plugin Bug MRELEASE-449
I created a bug report in JIRA on June 1 against the release plugin which included a failing simple test case and a patch with a unit test and code change to resolve the bug. I was wondering if a committer could take a look at it. http://jira.codehaus.org/browse/MRELEASE-449 Thanks. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Multi module project using maven-release-plugin
Hi All, I'm a bit new to the whole maven thing so bare with me please. I'm having issues with the release plugin. I can release my "core" library's with out any problems but I'm struggling with the multi module project. 1. When I do a prepare for my project, the web module fails saying it cant get the EJB module from my remote repository. -> I understand it fails because the previous step of building the EJB module doesn't actually install it in my local/remote rep. But why doesn't it, or how do I get it resolved internally. I would think the release plugin should do this. The work around is to manually release every module, but that sort of seems like a waist. 2. I'm getting this error when building my project (on parent and web module level) [WARNING] POM for 'cib.ibot:PLAUTO-EJB:pom:1.0-SNAPSHOT:provided' is invalid. Its dependencies (if any) will NOT be available to the current build. -> This is my EJB module, everything still works fine, but the ear plugin seems to ignore my dependencies. So my ear contains nothing in the lib folder, I have to manually add a dependency on all my dependencies from the EJB pom. Any ideas? My structure is : CoreLib -src -... -pom.xml Project1 -pom.xml (Parent) -EJB -src -... -pom.xml -WAR -src -... -pom.xml -EAR -src -... -pom.xml Thanks Derick _ Standard Bank email Disclaimer and confidentiality note This e-mail, its attachments and any rights attaching hereto are, unless the content clearly indicates otherwise, the property of Standard Bank Group Limited and its subsidiaries. It is confidential, private and intended for only the addressee. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail immediately. Do not disclose or use it in any way. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of Standard Bank Group. Standard Bank Group accepts no liability for any loss or damages howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. Standard Bank Group does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS). For information about the Standard Bank Group visit our website http://www.standardbank.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Thu, Jun 11, 2009 at 4:22 AM, David Jencks wrote: > > On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: > >> Update: >> The new assembly plugin and the regex in the source bundle seem to be >> working great. I have just one thing to resolve that I had previously >> overlooked: The source archive must also contain license and notice >> files, even if svn doesn't. > > I don't have the quote handy but Roy stated pretty clearly that expected > checkout roots are sufficiently distribution-like to be required to have > LICENSE and NOTICE files in svn. > I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. > So I think that verifying that the LICENSE and NOTICE files are there is > enough, you don't need to add them. > > thanks > david jencks > >> I need to understand better the default >> resource bundle processing and how to pull the right pieces together >> into the assembly. Otherwise we are pretty close to getting all this >> staged and released. >> >> --Brian >> >> On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: >>> >>> Just to bring the thread back up in light of the recent discussions of >>> plugin releases: >>> John has taken over the assembly release that contains the fix I put in >>> for >>> the ASF stuff. I've been travelling a lot the past two weeks and haven't >>> progressed much on the poms. Tomorrow or monday I should have time to >>> take >>> the latest assembly stage and get the apache assembly descriptor and all >>> the >>> poms updated and tested out. >>> Note that the work we are doing here is to make it easier to define this >>> for >>> all maven (and later asf) projects and be inherited correctly. This does >>> not >>> mean that all pending releases must be blocked waiting for these changes. >>> You can make a source release quite easily with the existing plugin >>> versions. >>> It's also worth nothing that now we know about the requirement, we must >>> have >>> a source release, ignoring the requirement simply because we didn't know >>> it >>> was a requirement in the past isn't an option. >>> >>> On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey wrote: > > > Brian Fox wrote: >> >> On Tue, May 26, 2009 at 10:18 PM, Brett Porter >> wrote: >> >>> On 26/05/2009, at 11:11 PM, Brian Fox wrote: >>> >>> We're fixing the directoryscanner to allow regular expressions in >>> addition to the ant syntax. >>> Cool, but that's another release in the chain, right? >>> >> >> It's already to go, John is staging it now. > > *Ahem* I'm still troubleshooting an IT issue dealing with these > regexes, > so once that's done I'll stage the release. Just didn't want anyone > thinking > they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) > > -john > > > - > 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 >> > > - > 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: Update on ASF Release requirements
On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r783525 - /maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java
Just in case, are you aware of these: http://maven.apache.org/doxia/whatsnew-1.1.html#Binary_Incompatibility http://maven.apache.org/doxia/developers/maven-integration.html maybe it helps... -Lukas Olivier Lamy wrote: Hi, It looks related sure :-). I didn't notice the existing jira entry. I'm currently made some tests with current trunk on some projects (company ones and oss ones) to test backward compatibility/ And I have noticed I couldn't run anymore : mvn site:site (just generate the site works now all reporting looks to be an other story :-) ). -- Olivier 2009/6/11 Lukas Theussl : Hi Olivier, How does this relate to MNG-3402? Just wondering because we had a lot of discussions about this issue in the past wrt Doxia release plan [1], and from other peoples' comments I always got the impression that it will lead to trouble... even though I never noticed anything myself. -Lukas [1] http://www.nabble.com/MNG-3402-tt17207692.html ol...@apache.org wrote: Author: olamy Date: Wed Jun 10 21:30:40 2009 New Revision: 783525 URL: http://svn.apache.org/viewvc?rev=783525&view=rev Log: don't filter doxia-sink-api. users will be still able to run : mvn site:site Modified: maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java Modified: maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java URL: http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java?rev=783525&r1=783524&r2=783525&view=diff == --- maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java (original) +++ maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java Wed Jun 10 21:30:40 2009 @@ -54,7 +54,7 @@ artifacts.add( "classworlds" ); artifacts.add( "plexus-classworlds" ); artifacts.add( "commons-cli" ); -artifacts.add( "doxia-sink-api" ); +//artifacts.add( "doxia-sink-api" ); artifacts.add( "jsch" ); artifacts.add( "maven-artifact" ); artifacts.add( "maven-artifact-manager" ); - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r783525 - /maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java
Hi, It looks related sure :-). I didn't notice the existing jira entry. I'm currently made some tests with current trunk on some projects (company ones and oss ones) to test backward compatibility/ And I have noticed I couldn't run anymore : mvn site:site (just generate the site works now all reporting looks to be an other story :-) ). -- Olivier 2009/6/11 Lukas Theussl : > > Hi Olivier, > > How does this relate to MNG-3402? > > Just wondering because we had a lot of discussions about this issue in the > past wrt Doxia release plan [1], and from other peoples' comments I always > got the impression that it will lead to trouble... even though I never > noticed anything myself. > > -Lukas > > [1] http://www.nabble.com/MNG-3402-tt17207692.html > > > > ol...@apache.org wrote: >> >> Author: olamy >> Date: Wed Jun 10 21:30:40 2009 >> New Revision: 783525 >> >> URL: http://svn.apache.org/viewvc?rev=783525&view=rev >> Log: >> don't filter doxia-sink-api. users will be still able to run : mvn >> site:site >> >> >> Modified: >> >> maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java >> >> Modified: >> maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java >> URL: >> http://svn.apache.org/viewvc/maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java?rev=783525&r1=783524&r2=783525&view=diff >> >> == >> --- >> maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java >> (original) >> +++ >> maven/components/trunk/maven-core/src/main/java/org/apache/maven/DefaultArtifactFilterManager.java >> Wed Jun 10 21:30:40 2009 >> @@ -54,7 +54,7 @@ >> artifacts.add( "classworlds" ); >> artifacts.add( "plexus-classworlds" ); >> artifacts.add( "commons-cli" ); >> - artifacts.add( "doxia-sink-api" ); >> + //artifacts.add( "doxia-sink-api" ); >> artifacts.add( "jsch" ); >> artifacts.add( "maven-artifact" ); >> artifacts.add( "maven-artifact-manager" ); >> >> >> > > - > 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
