Re: Update on ASF Release requirements
On 27/05/2009, at 3: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? Then we can do (?!.*/src/.*).*/target/.* Ew :) What if the build directory isn't target? (unlikely, I know). What if there are both src and target packages in a source tree? (not unthinkable) What if it's a pom project with no src directory and still generates a target? ok, sorry... I completely misread that regex as meaning "target where there is a source directory". So this would work ok... but I think I'd still prefer something more deterministic such as the below as it could improve the out-of-the-box source descriptor as well. Seems a little magic to me. - Brett On Mon, May 25, 2009 at 6:58 PM, Brett Porter wrote: How about an option trueexcludeBuildDirectories> that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett - 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 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? Then we can do (?!.*/src/.*).*/target/.* Ew :) What if the build directory isn't target? (unlikely, I know). What if there are both src and target packages in a source tree? (not unthinkable) What if it's a pom project with no src directory and still generates a target? Seems a little magic to me. - Brett On Mon, May 25, 2009 at 6:58 PM, Brett Porter wrote: How about an option trueexcludeBuildDirectories> that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released.
I really like the idea of breaking up unit, integration, and functional tests. This is how I would prefer to break up my tests. I had to use TestNG groups to do this effectively in the current scheme of things. Thanks for the link! Jason -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, May 26, 2009 2:14 PM To: Maven Users List Cc: Maven Developers List Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. 2009/5/26 Jason Chaffee > Yep, I concur with you a 100%. I think the solutions for this until now > (FailSafe), were highly undesirable and caused many other issues. > > It might be something the Maven folks might want to think about in the > future, adding support for integration testing in an more appropriate way > (adding the maven dev list for this reason). I know that there is already some proposals bobbing around, e.g. http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies > > > Regards, > > Jason > > > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, May 26, 2009 1:08 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > and you'd probably want an integration-test scope as well for > dependencies used for integration testing, and you'd need to add an > integrationTestSources element to the build, as well as > integrationTestResources > > that is if you want to do things properly. > > and I am not opposed to such changes. the failsafe plugin provides a > mostly clean solution *now*. I am fed up waiting for try... finally > phases (which are why failing the build in the integration-test phase > is *bad*)... I am fed up having a big mad configuration section with > multiple executions in my maven-surefire-plugin plugin, which scares > project newcomers, just the get integration tests running correctly... > I am fed up with a separate module for integration tests (of only one > module) because you only really see the failures when it comes time to > release... > > with failsafe, it's part of the standard build for that module. > > if the developers want to skip the its > > mvn package > or > mvn verify -DskipITs > > if they just run mvn install or mvn deploy then the integration tests > will have run. > > if they've bugs in unit tests > > mvn test -Dmaven.surefire.debug=... > > if they've bugs in integration tests > > mvn verify -Dmaven.failsafe.debug=... > > and all I'd added is a simple short snippet to the pom... no execution > hacks, no profile hacks > > don't get me wrong, if somebody has a better solution *pretty please > with catnip on top* show it to us *now* ;-) > > -Stephen > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 20:33, Jason Chaffee > wrote: > > > Yes, it would basically force Maven to adopt it as a standard and it > > would might mean even adding a itest-compile phase, etc. > > > > Not sure if I prefer this idea over the current protocol, but I do > > think the FailSafe plugin is very good and clever approach to > > integration tests with the way things currently work in Maven. > > > > I am just throwing it out there as idea for the sake of discussion. > > > > Jason > > > > -Original Message- > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Sent: Tuesday, May 26, 2009 12:27 PM > > To: Maven Users List > > Cc: Maven Users List > > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > > > but that looses source folder config in ide setup, and hacks with > > test- > > compile > > > > Sent from my [rhymes with myPod] ;-) > > > > On 26 May 2009, at 20:22, Jason Chaffee > > wrote: > > > >> One way around the excludes hack is to adopt a different directory > >> structure for it tests and unit tests. For example > >> > >> src/test --> unit tests > >> > >> src/itest --> integration tests > >> > >> Jason > >> > >> -Original Message- > >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > >> Sent: Tuesday, May 26, 2009 12:12 PM > >> To: Maven Users List > >> Cc: Maven Users List > >> Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > >> > >> I am not opposed to doing so. the block for me is my lack of Apache > >> commit access. > >> > >> there are valid arguments for keeping these as separate plugins > >> though, eg the none hack that people used to > >> configure surefire for multiple executions; debugging tests from an > >> IDE; skipping one type of tests, etc > >> > >> but at the end of the day, if we can find a way to combine to one > >> plugin, I'm fine with that > >> > >> Sent from my [rhymes with myPod] ;-) > >> > >> On 26 May 2009, at 19:58, Paul Benedict wrote: > >> > >>> Will there be an effort to add the integration testing features to > >>> the > >>> original? I would like to not have multiple testing plugins. > >>> > >>> On Tue, May 26, 2009 at 1:
Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released.
2009/5/26 Jason Chaffee > Yep, I concur with you a 100%. I think the solutions for this until now > (FailSafe), were highly undesirable and caused many other issues. > > It might be something the Maven folks might want to think about in the > future, adding support for integration testing in an more appropriate way > (adding the maven dev list for this reason). I know that there is already some proposals bobbing around, e.g. http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies > > > Regards, > > Jason > > > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, May 26, 2009 1:08 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > and you'd probably want an integration-test scope as well for > dependencies used for integration testing, and you'd need to add an > integrationTestSources element to the build, as well as > integrationTestResources > > that is if you want to do things properly. > > and I am not opposed to such changes. the failsafe plugin provides a > mostly clean solution *now*. I am fed up waiting for try... finally > phases (which are why failing the build in the integration-test phase > is *bad*)... I am fed up having a big mad configuration section with > multiple executions in my maven-surefire-plugin plugin, which scares > project newcomers, just the get integration tests running correctly... > I am fed up with a separate module for integration tests (of only one > module) because you only really see the failures when it comes time to > release... > > with failsafe, it's part of the standard build for that module. > > if the developers want to skip the its > > mvn package > or > mvn verify -DskipITs > > if they just run mvn install or mvn deploy then the integration tests > will have run. > > if they've bugs in unit tests > > mvn test -Dmaven.surefire.debug=... > > if they've bugs in integration tests > > mvn verify -Dmaven.failsafe.debug=... > > and all I'd added is a simple short snippet to the pom... no execution > hacks, no profile hacks > > don't get me wrong, if somebody has a better solution *pretty please > with catnip on top* show it to us *now* ;-) > > -Stephen > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 20:33, Jason Chaffee > wrote: > > > Yes, it would basically force Maven to adopt it as a standard and it > > would might mean even adding a itest-compile phase, etc. > > > > Not sure if I prefer this idea over the current protocol, but I do > > think the FailSafe plugin is very good and clever approach to > > integration tests with the way things currently work in Maven. > > > > I am just throwing it out there as idea for the sake of discussion. > > > > Jason > > > > -Original Message- > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Sent: Tuesday, May 26, 2009 12:27 PM > > To: Maven Users List > > Cc: Maven Users List > > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > > > but that looses source folder config in ide setup, and hacks with > > test- > > compile > > > > Sent from my [rhymes with myPod] ;-) > > > > On 26 May 2009, at 20:22, Jason Chaffee > > wrote: > > > >> One way around the excludes hack is to adopt a different directory > >> structure for it tests and unit tests. For example > >> > >> src/test --> unit tests > >> > >> src/itest --> integration tests > >> > >> Jason > >> > >> -Original Message- > >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > >> Sent: Tuesday, May 26, 2009 12:12 PM > >> To: Maven Users List > >> Cc: Maven Users List > >> Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > >> > >> I am not opposed to doing so. the block for me is my lack of Apache > >> commit access. > >> > >> there are valid arguments for keeping these as separate plugins > >> though, eg the none hack that people used to > >> configure surefire for multiple executions; debugging tests from an > >> IDE; skipping one type of tests, etc > >> > >> but at the end of the day, if we can find a way to combine to one > >> plugin, I'm fine with that > >> > >> Sent from my [rhymes with myPod] ;-) > >> > >> On 26 May 2009, at 19:58, Paul Benedict wrote: > >> > >>> Will there be an effort to add the integration testing features to > >>> the > >>> original? I would like to not have multiple testing plugins. > >>> > >>> On Tue, May 26, 2009 at 1:54 PM, Stephen Connolly > >>> wrote: > use surefire for unit tests > > use failsafe if you need to set up a integration test environment > and tear > it back down again after the integration tests have ran > > -Stephen > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 19:34, Wim Deblauwe > wrote: > > > Is there an explanation somewhere on when to use surefire and when > > this > > failsafe
RE: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released.
Yep, I concur with you a 100%. I think the solutions for this until now (FailSafe), were highly undesirable and caused many other issues. It might be something the Maven folks might want to think about in the future, adding support for integration testing in an more appropriate way (adding the maven dev list for this reason). Regards, Jason -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Tuesday, May 26, 2009 1:08 PM To: Maven Users List Cc: Maven Users List Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. and you'd probably want an integration-test scope as well for dependencies used for integration testing, and you'd need to add an integrationTestSources element to the build, as well as integrationTestResources that is if you want to do things properly. and I am not opposed to such changes. the failsafe plugin provides a mostly clean solution *now*. I am fed up waiting for try... finally phases (which are why failing the build in the integration-test phase is *bad*)... I am fed up having a big mad configuration section with multiple executions in my maven-surefire-plugin plugin, which scares project newcomers, just the get integration tests running correctly... I am fed up with a separate module for integration tests (of only one module) because you only really see the failures when it comes time to release... with failsafe, it's part of the standard build for that module. if the developers want to skip the its mvn package or mvn verify -DskipITs if they just run mvn install or mvn deploy then the integration tests will have run. if they've bugs in unit tests mvn test -Dmaven.surefire.debug=... if they've bugs in integration tests mvn verify -Dmaven.failsafe.debug=... and all I'd added is a simple short snippet to the pom... no execution hacks, no profile hacks don't get me wrong, if somebody has a better solution *pretty please with catnip on top* show it to us *now* ;-) -Stephen Sent from my [rhymes with myPod] ;-) On 26 May 2009, at 20:33, Jason Chaffee wrote: > Yes, it would basically force Maven to adopt it as a standard and it > would might mean even adding a itest-compile phase, etc. > > Not sure if I prefer this idea over the current protocol, but I do > think the FailSafe plugin is very good and clever approach to > integration tests with the way things currently work in Maven. > > I am just throwing it out there as idea for the sake of discussion. > > Jason > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, May 26, 2009 12:27 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > but that looses source folder config in ide setup, and hacks with > test- > compile > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 20:22, Jason Chaffee > wrote: > >> One way around the excludes hack is to adopt a different directory >> structure for it tests and unit tests. For example >> >> src/test --> unit tests >> >> src/itest --> integration tests >> >> Jason >> >> -Original Message- >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] >> Sent: Tuesday, May 26, 2009 12:12 PM >> To: Maven Users List >> Cc: Maven Users List >> Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. >> >> I am not opposed to doing so. the block for me is my lack of Apache >> commit access. >> >> there are valid arguments for keeping these as separate plugins >> though, eg the none hack that people used to >> configure surefire for multiple executions; debugging tests from an >> IDE; skipping one type of tests, etc >> >> but at the end of the day, if we can find a way to combine to one >> plugin, I'm fine with that >> >> Sent from my [rhymes with myPod] ;-) >> >> On 26 May 2009, at 19:58, Paul Benedict wrote: >> >>> Will there be an effort to add the integration testing features to >>> the >>> original? I would like to not have multiple testing plugins. >>> >>> On Tue, May 26, 2009 at 1:54 PM, Stephen Connolly >>> wrote: use surefire for unit tests use failsafe if you need to set up a integration test environment and tear it back down again after the integration tests have ran -Stephen Sent from my [rhymes with myPod] ;-) On 26 May 2009, at 19:34, Wim Deblauwe wrote: > Is there an explanation somewhere on when to use surefire and when > this > failsafe plugin? What are the main differences? > > regards, > > Wim > > 2009/5/25 Stephen Connolly > >> The Mojo team is pleased to announce the release of the Failsafe >> Maven >> Plugin, version 2.4.3-alpha-1. >> >> The Failsafe Plugin is a fork of the Maven Surefire Plugin >> designed for >> running integration tests. It has the following goals. >>
Re: Update on ASF Release requirements
We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Then we can do (?!.*/src/.*).*/target/.* On Mon, May 25, 2009 at 6:58 PM, Brett Porter wrote: > How about an option true > that uses the list of build directories from all projects in the reactor an > applies that to the fileset excludes? > > It could be either descriptor-wide, or per-fileset I guess. > > Short of that, I'd say to get it off the ground to tell projects they need > to alter the descriptor when using it to explicitly include their non-build > target directories. > > - Brett > > > On 21/05/2009, at 7:14 AM, Brian Fox wrote: > > Introducing the configurability in the descriptor itself requires more >> changes to the assembly code than I think we should tackle right now. I >> also >> think we should strive to build a descriptor that works for all projects >> to >> the extent possible. That said, I'll make a property in the plugin config >> to >> make it easier for projects to disable this execution and/or use a >> different >> descriptor of their choosing. >> Now, I solved the MASSEMBLY-405 issue, but this causes a few more problems >> we need to look into. It causes us to need something like **\target\** to >> exclude the build artifacts from the assembly, but several projects in >> maven >> use target folders in their test resources (archetype, install, deploy). >> The >> solution to this yet is still undefined. >> >> On Mon, May 18, 2009 at 11:36 AM, Ate Douma wrote: >> >> Brian Fox wrote: >>> >>> On Mon, May 18, 2009 at 8:57 AM, Ate Douma wrote: Brian Fox wrote: > > It's been a little slow going, but here's an update of where I'm at: > >> I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and >> renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has >> been >> added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor >> bundle[2] >> to be used for the asf source releases. Initially this is a copy of >> the >> default project.xml with the bz2 removed. Having it separate will give >> us >> more flexibility to make updates w/o having to re-release the plugin. >> >> The configuration for making a bundle with this setup currently looks >> like >> this: >> >> maven-assembly-plugin >> 2.2-beta-4-SNAPSHOT >> >> >> >> single >> >> validate >> >> true >> >> >> source-release >> >> >> >> >> >> >> >> org.apache >> >> apache-source-release-assembly-descriptor >> 1.0-SNAPSHOT >> >> >> >> >> Once I test and work out any kinks, this will be added to the maven >> pom >> and >> released. >> >> There is one bug that David Jenks found in the beta-3 code that needs >> to >> be >> addressed since it affects the bundle content (MASSEMBLY-405). I hope >> to >> have the bug fixed and assembly staged by tuesday, followed by the >> descriptor bundle and then the maven/shared/plugin/etc parents later >> this >> week. >> >> Hi Brian, >> > > I just created issue MASSEMBLY-409 which describes two other problems > we > encountered by using the "project" assembly for our recent Apache > Portals > releases. > It would be great if you can take that issue and the recommended > fixes/solutions into consideration for the next release too: > > http://jira.codehaus.org/browse/MASSEMBLY-409 > > > I don't see those as being problems with the approach I'm taking. The asf descriptor will be separate from the plugin so we can tweak it as needed, and projects can introduce their own descriptors instead of the default if they want. Well, yes. But with the current restrictions (no configuration >>> overrides) >>> it might result in a lot (most) ASF projects needing to provide their own >>> which makes the whole point of this "project" descriptor a bit useless >>> IMO. >>> >>> >>> > The current descriptor produces tar.gz and zip, does anyone have strong > >> feelings if this is ok or should we go with only one of them? (and >> which >> one?) >> >> Why drop .bz2 in the first place? >> > > The source archives for everything are going to significantly increase the bandwidth to mirror and disk to store millions of artifacts. We should be conservative and use the minimum, which imo is zip and bz2. We have been using .bz2, .tar.gz and .zip based distro releases always > and > AFAIK most other ASF projects too. > With this change, we'll be forced
