Re: Invoker vs. Verifier?
I created a few integration-tests for the jar-plugin using the Maven Embedder as described in http://maven.apache.org/developers/committer-testing-plugins.html under both maven-it-plugin and maven-plugin-test-plugin (I didn't use any testing plugins, just the install-plugin). Add the Embedder to your list of testing utilities. I think a lot of things could be improved in the testing strategies. The bugs that I fixed in the jar-plugin took me less than an hour to complete, but creating the testcases to me about three days before I finally found the above mentioned page. Maybe I've missunderstood something completely, but as far as I understand some tests are auctually testing the result from the previous build? /Johan 2007/12/12, Brian E. Fox <[EMAIL PROTECTED]>: > You forgot the maven-plugin-testing-harness ;-) > > > > -Original Message- > From: Dan Fabulich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 11, 2007 9:07 PM > To: Maven Developers List > Subject: Re: Invoker vs. Verifier? > > John Casey wrote: > > > What you're seeing as overlap is a mixture of concerns in the invoker > > plugin. The verifications beanshell really needs to be migrated out to > > > some sort of proper integration-testing plugin (or, even better, a > > plugin that unites invoker and verifier under a common > > configuration...then extend the verifier with the invoker's beanshell > > functionality). Regardless, the invoker plugin can be used for any > sort > > of scenario where you need to fork a new maven process. I've > personally > > used it to proxy secondary builds in some sticky client use cases. You > > > don't have to use the beanshell script to verify the build, it's just > an > > [admittedly confusing] option. > > As I've remarked before, I find it weird that various Maven developers > have gone and written _plugins_ to do Maven integration testing. > > Integration tests are just tests; we know how to write/run tests using > real test frameworks like JUnit and TestNG. Those frameworks are pretty > > cool; you can do stuff like rerun failures-only, graph results over > time, > write data-driven tests, etc. You can even use them to write tests in > scripting languages like Groovy, BeanShell, etc. All that AND you get > excellent IDE integration. > > More generally, while I certainly see the value of a > maven-invoker-plugin, > I don't expect that you'd want that to be the "normal" way people would > write Maven integration tests. > > Right now there are four things: maven-verifier, maven-verifier-plugin > (no > relation!), maven-invoker, and maven-invoker-plugin. > > I think I'd like to advocate ripping out the bulk of maven-verifier and > make it depend entirely on maven-invoker. Since maven-verifier is so > confusingly named, I think I'd want to take the good bits out and put > them > in maven-integration-test-helper (which is what maven-verifier really > is, > anyway). > > More controversially (?) I'd like to deprecate the idea of writing > *tests* > using the maven-invoker-plugin, instead preferring to write them in Java > > (or BeanShell, I'm easy!) running them using a "real" test framework. > maven-invoker-plugin should still be used for spawning sub-builds in > those > delightful cases where that's necessary. > > Thoughts? > > -Dan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Johan Kindgren Acrend AB Phone: +46 (0) 733-58 36 60 E-mail: [EMAIL PROTECTED] www.acrend.se - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invoker vs. Verifier?
You forgot the maven-plugin-testing-harness ;-) -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 9:07 PM To: Maven Developers List Subject: Re: Invoker vs. Verifier? John Casey wrote: > What you're seeing as overlap is a mixture of concerns in the invoker > plugin. The verifications beanshell really needs to be migrated out to > some sort of proper integration-testing plugin (or, even better, a > plugin that unites invoker and verifier under a common > configuration...then extend the verifier with the invoker's beanshell > functionality). Regardless, the invoker plugin can be used for any sort > of scenario where you need to fork a new maven process. I've personally > used it to proxy secondary builds in some sticky client use cases. You > don't have to use the beanshell script to verify the build, it's just an > [admittedly confusing] option. As I've remarked before, I find it weird that various Maven developers have gone and written _plugins_ to do Maven integration testing. Integration tests are just tests; we know how to write/run tests using real test frameworks like JUnit and TestNG. Those frameworks are pretty cool; you can do stuff like rerun failures-only, graph results over time, write data-driven tests, etc. You can even use them to write tests in scripting languages like Groovy, BeanShell, etc. All that AND you get excellent IDE integration. More generally, while I certainly see the value of a maven-invoker-plugin, I don't expect that you'd want that to be the "normal" way people would write Maven integration tests. Right now there are four things: maven-verifier, maven-verifier-plugin (no relation!), maven-invoker, and maven-invoker-plugin. I think I'd like to advocate ripping out the bulk of maven-verifier and make it depend entirely on maven-invoker. Since maven-verifier is so confusingly named, I think I'd want to take the good bits out and put them in maven-integration-test-helper (which is what maven-verifier really is, anyway). More controversially (?) I'd like to deprecate the idea of writing *tests* using the maven-invoker-plugin, instead preferring to write them in Java (or BeanShell, I'm easy!) running them using a "real" test framework. maven-invoker-plugin should still be used for spawning sub-builds in those delightful cases where that's necessary. Thoughts? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoker vs. Verifier?
John Casey wrote: What you're seeing as overlap is a mixture of concerns in the invoker plugin. The verifications beanshell really needs to be migrated out to some sort of proper integration-testing plugin (or, even better, a plugin that unites invoker and verifier under a common configuration...then extend the verifier with the invoker's beanshell functionality). Regardless, the invoker plugin can be used for any sort of scenario where you need to fork a new maven process. I've personally used it to proxy secondary builds in some sticky client use cases. You don't have to use the beanshell script to verify the build, it's just an [admittedly confusing] option. As I've remarked before, I find it weird that various Maven developers have gone and written _plugins_ to do Maven integration testing. Integration tests are just tests; we know how to write/run tests using real test frameworks like JUnit and TestNG. Those frameworks are pretty cool; you can do stuff like rerun failures-only, graph results over time, write data-driven tests, etc. You can even use them to write tests in scripting languages like Groovy, BeanShell, etc. All that AND you get excellent IDE integration. More generally, while I certainly see the value of a maven-invoker-plugin, I don't expect that you'd want that to be the "normal" way people would write Maven integration tests. Right now there are four things: maven-verifier, maven-verifier-plugin (no relation!), maven-invoker, and maven-invoker-plugin. I think I'd like to advocate ripping out the bulk of maven-verifier and make it depend entirely on maven-invoker. Since maven-verifier is so confusingly named, I think I'd want to take the good bits out and put them in maven-integration-test-helper (which is what maven-verifier really is, anyway). More controversially (?) I'd like to deprecate the idea of writing *tests* using the maven-invoker-plugin, instead preferring to write them in Java (or BeanShell, I'm easy!) running them using a "real" test framework. maven-invoker-plugin should still be used for spawning sub-builds in those delightful cases where that's necessary. Thoughts? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release Maven Invoker 2.0.7
+1 Thanks for heading this up. I've been using snapshots of the invoker for some time now, and it seems completely stable for my purposes. -john On Dec 11, 2007, at 5:49 PM, [EMAIL PROTECTED] wrote: Hi, In the preparation of the Maven Invoker Plugin release, I would like to release maven-invoker:2.0.7 The last release was done around one year ago. Staging repo : http://people.apache.org/~olamy/staging-repo/ Vote open for 72 hours. Here my +1 (non binding). [ ] +1 [ ] +0 [ ] -1 -- Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: Invoker vs. Verifier?
What you're seeing as overlap is a mixture of concerns in the invoker plugin. The verifications beanshell really needs to be migrated out to some sort of proper integration-testing plugin (or, even better, a plugin that unites invoker and verifier under a common configuration...then extend the verifier with the invoker's beanshell functionality). Regardless, the invoker plugin can be used for any sort of scenario where you need to fork a new maven process. I've personally used it to proxy secondary builds in some sticky client use cases. You don't have to use the beanshell script to verify the build, it's just an [admittedly confusing] option. -john On Dec 11, 2007, at 6:28 PM, Dan Fabulich wrote: Forgive me if I'm picking at a sore spot, but can someone help me understand the difference/overlap between maven-invoker and maven- verifier? As I understand it, they both do roughly the same thing, except one of them is a Maven plugin where you write your test in a goals.txt file + beanshell, and the other is meant to be run programmatically from a JUnit test. Is that essentially correct? (Whereas maven-verifier-plugin is another beast entirely, simply checking for the presence/absence of certian files.) Am I right in thinking that, despite their substantial overlap, maven-verifier and maven-invoker share no code? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Invoker vs. Verifier?
Forgive me if I'm picking at a sore spot, but can someone help me understand the difference/overlap between maven-invoker and maven-verifier? As I understand it, they both do roughly the same thing, except one of them is a Maven plugin where you write your test in a goals.txt file + beanshell, and the other is meant to be run programmatically from a JUnit test. Is that essentially correct? (Whereas maven-verifier-plugin is another beast entirely, simply checking for the presence/absence of certian files.) Am I right in thinking that, despite their substantial overlap, maven-verifier and maven-invoker share no code? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote] Release Maven Invoker 2.0.7
Hi, In the preparation of the Maven Invoker Plugin release, I would like to release maven-invoker:2.0.7 The last release was done around one year ago. Staging repo : http://people.apache.org/~olamy/staging-repo/ Vote open for 72 hours. Here my +1 (non binding). [ ] +1 [ ] +0 [ ] -1 -- Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] maven-remote-resources-plugin 1.0-beta-2
Oops. Forgot to add [RESULT] to the Subject line. Dan On Tuesday 11 December 2007, Daniel Kulp wrote: > OK. Finally have the votes to do the release. :-) > > We have 6 +1 votes and no other votes: > PMC +1: jvanzyl, brianf, ltheussl > Non-PMC +1: dkulp, olamy, jdillon > > Thus, this vote passes. I'll get the artifacts moved into the sync > repo. > > Thanks! > Dan > > On Wednesday 05 December 2007, Daniel Kulp wrote: > > I'd like to release version 1.0-beta-2 of the > > maven-remote-resources-plugin. The only change between this and > > 1.0-beta-1 is to fix the fact that 1.0-beta-1 would not work with > > JDK 1.4 due to it overriding a method that was final in 1.4, but not > > in 1.5. > > > > > > Staging area: > > http://people.apache.org/~dkulp/stage_rr/ > > > > Tag: > > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-reso > >ur ces-plugin-1.0-beta-2/ > > > > > > Vote open for 72 hours. > > > > Here is my +1 > > > > [ ] +1 > > [ ] +0 > > [ ] -1 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] maven-remote-resources-plugin 1.0-beta-2
OK. Finally have the votes to do the release. :-) We have 6 +1 votes and no other votes: PMC +1: jvanzyl, brianf, ltheussl Non-PMC +1: dkulp, olamy, jdillon Thus, this vote passes. I'll get the artifacts moved into the sync repo. Thanks! Dan On Wednesday 05 December 2007, Daniel Kulp wrote: > I'd like to release version 1.0-beta-2 of the > maven-remote-resources-plugin. The only change between this and > 1.0-beta-1 is to fix the fact that 1.0-beta-1 would not work with JDK > 1.4 due to it overriding a method that was final in 1.4, but not in > 1.5. > > > Staging area: > http://people.apache.org/~dkulp/stage_rr/ > > Tag: > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resour >ces-plugin-1.0-beta-2/ > > > Vote open for 72 hours. > > Here is my +1 > > [ ] +1 > [ ] +0 > [ ] -1 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven binary assemblies on central?
On 11 Dec 07, at 12:42 PM 11 Dec 07, Dan Fabulich wrote: As you've all heard endlessly by now, we're running a lot of integration tests in the new Surefire 2.4; these integration tests are currently designed to just fork/run the current version of Maven (discovered from the M2_HOME env var or an optional system property) on a set of checked-in projects. It would be cool to have the integration tests be able to automatically run older released versions of Maven, grabbing their distribution zips off of central, and then extract/run them on-the- fly. Poking around on central, I see that 2.0.8 has a bin-zip in maven- core/2.0.8, but 2.0.7 doesn't; 2.0.6 does, but 2.0.5 and 2.0.4 don't. Is the bin-zip for 2.0.7 somewhere else on central, or is it only available on archive.apache.org? We are discouraged from putting the assemblies in the repository by the board so that people use the standard channels to download ASF software. The release distributions are not supposed to be in the repository. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven binary assemblies on central?
+1 to put the assembly up on the central. I currently deploy the assemblies ( maven, tomcat, etc ) to my internal repo for automation purposes -D On Dec 11, 2007 12:42 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > As you've all heard endlessly by now, we're running a lot of integration > tests in the new Surefire 2.4; these integration tests are currently > designed to just fork/run the current version of Maven (discovered from > the M2_HOME env var or an optional system property) on a set of checked-in > projects. > > It would be cool to have the integration tests be able to automatically > run older released versions of Maven, grabbing their distribution zips off > of central, and then extract/run them on-the-fly. > > Poking around on central, I see that 2.0.8 has a bin-zip in > maven-core/2.0.8, but 2.0.7 doesn't; 2.0.6 does, but 2.0.5 and 2.0.4 > don't. Is the bin-zip for 2.0.7 somewhere else on central, or is it only > available on archive.apache.org? > > -Dan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven binary assemblies on central?
As you've all heard endlessly by now, we're running a lot of integration tests in the new Surefire 2.4; these integration tests are currently designed to just fork/run the current version of Maven (discovered from the M2_HOME env var or an optional system property) on a set of checked-in projects. It would be cool to have the integration tests be able to automatically run older released versions of Maven, grabbing their distribution zips off of central, and then extract/run them on-the-fly. Poking around on central, I see that 2.0.8 has a bin-zip in maven-core/2.0.8, but 2.0.7 doesn't; 2.0.6 does, but 2.0.5 and 2.0.4 don't. Is the bin-zip for 2.0.7 somewhere else on central, or is it only available on archive.apache.org? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Brian E. Fox wrote: It would be cool if you could try the new candidate on 2.0.x also. I had trouble with it excluding tons of stuff when I did 2.0.8. I can try it later today if you can't. Built a 2.0.9 snapshot and try it out on a sample projects. No problems encountered. So it does look promising. I would stage an alpha-15 release and let people loose on it. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Daniel Kulp wrote: OK. I fixed one more issue with it. Can you give it another try. :-) Getting closer. Yup, looks good to me. I've closed MSHADE-5 again. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
It would be cool if you could try the new candidate on 2.0.x also. I had trouble with it excluding tons of stuff when I did 2.0.8. I can try it later today if you can't. -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 11:51 AM To: dev@maven.apache.org Cc: Dan Fabulich Subject: Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox OK. I fixed one more issue with it. Can you give it another try. :-) Getting closer. Dan On Tuesday 11 December 2007, Dan Fabulich wrote: > Fixed on my end (I think... this bug is finicky); try it on your end > to make sure I didn't break anything further? > > -Dan > > Dan Fabulich wrote: > > Daniel Kulp wrote: > >> I changed the rename logic to do a whole bunch of fallback things > >> if the first rename fails. It first will try a gc to see if any > >> Streams that are holding it locked can be cleaned up. If that > >> still fails, then it will just copy the new file over the old file. > >> Not ideal, but it should hopefully work. > > > > Seems like this strategy might have worked, but now it's buggy. > > When I ran it just now it failed to install the jar, because it > > wasn't there at all... All I had was > > original-surefire-api-2.4-SNAPSHOT-shaded.jar and > > surefire-api-2.4-SNAPSHOT-shaded.jar; install failed because I was > > missing plain old surefire-api-2.4-SNAPSHOT.jar. > > > > I'll try to poke around with it a bit today. > > > > -Dan > > > > > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
OK. I fixed one more issue with it. Can you give it another try. :-) Getting closer. Dan On Tuesday 11 December 2007, Dan Fabulich wrote: > Fixed on my end (I think... this bug is finicky); try it on your end > to make sure I didn't break anything further? > > -Dan > > Dan Fabulich wrote: > > Daniel Kulp wrote: > >> I changed the rename logic to do a whole bunch of fallback things > >> if the first rename fails. It first will try a gc to see if any > >> Streams that are holding it locked can be cleaned up. If that > >> still fails, then it will just copy the new file over the old file. > >> Not ideal, but it should hopefully work. > > > > Seems like this strategy might have worked, but now it's buggy. > > When I ran it just now it failed to install the jar, because it > > wasn't there at all... All I had was > > original-surefire-api-2.4-SNAPSHOT-shaded.jar and > > surefire-api-2.4-SNAPSHOT-shaded.jar; install failed because I was > > missing plain old surefire-api-2.4-SNAPSHOT.jar. > > > > I'll try to poke around with it a bit today. > > > > -Dan > > > > > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Fixed on my end (I think... this bug is finicky); try it on your end to make sure I didn't break anything further? -Dan Dan Fabulich wrote: Daniel Kulp wrote: I changed the rename logic to do a whole bunch of fallback things if the first rename fails. It first will try a gc to see if any Streams that are holding it locked can be cleaned up. If that still fails, then it will just copy the new file over the old file. Not ideal, but it should hopefully work. Seems like this strategy might have worked, but now it's buggy. When I ran it just now it failed to install the jar, because it wasn't there at all... All I had was original-surefire-api-2.4-SNAPSHOT-shaded.jar and surefire-api-2.4-SNAPSHOT-shaded.jar; install failed because I was missing plain old surefire-api-2.4-SNAPSHOT.jar. I'll try to poke around with it a bit today. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Mauro Talevi wrote: I've commented on MSHADE-7 - as far as I can tell, feature is already implemented, via shadedArtifact attachment. Please try out the configuration in: MSHADE-7 is a very different feature from shadedArtifactAttached. MSHADE-7 suggests that the generated classes just get dumped in with the regular classes, so I can just write my code directly against the shaded packages. In that case, there would be no separate shaded artifact; the main artifact would be the only artifact, and no need to replace. shadedArtifactAttached appends a new artifact with -shaded classifier, which isn't as helpful because the non-shaded artifact is usually trash. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Daniel Kulp wrote: I changed the rename logic to do a whole bunch of fallback things if the first rename fails. It first will try a gc to see if any Streams that are holding it locked can be cleaned up. If that still fails, then it will just copy the new file over the old file. Not ideal, but it should hopefully work. Seems like this strategy might have worked, but now it's buggy. When I ran it just now it failed to install the jar, because it wasn't there at all... All I had was original-surefire-api-2.4-SNAPSHOT-shaded.jar and surefire-api-2.4-SNAPSHOT-shaded.jar; install failed because I was missing plain old surefire-api-2.4-SNAPSHOT.jar. I'll try to poke around with it a bit today. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Dan, Can you try a deploy with 1.0-alpha-15-SNAPSHOT? I changed the rename logic to do a whole bunch of fallback things if the first rename fails. It first will try a gc to see if any Streams that are holding it locked can be cleaned up. If that still fails, then it will just copy the new file over the old file. Not ideal, but it should hopefully work. Dan On Tuesday 11 December 2007, Dan Fabulich wrote: > Uh, actually, I need to turn my vote to a -1. :-( I just discovered > that I'm being bitten by MSHADE-5 (and MSHADE-6) every time I go to > deploy the Surefire 2.4-SNAPSHOT. As a result, I deployed a corrupted > SNAPSHOT... yuck! > > I just fixed MSHADE-6 in the sandbox, which would have at least > prevented me from deploying a defective binary. I still don't see a > great way to resolve MSHADE-5 except to pursue a strategy like the one > described in MSHADE-7 (perhaps, as dkulp suggested, as an option). > > I'm going to go try to do the deploy directly from people.apache.org > now. > > :-( > > -Dan > > Dan Fabulich wrote: > > +1. This works with the latest Surefire trunk. (It's a pity > > MSHADE-9 is still broken, but I think it's OK for another alpha; we > > should fix it for beta-1.) > > > > -Dan > > > > Mauro Talevi wrote: > >> As version 1.0-alpha-14 has been staged for release, I'd like to > >> call a vote for its release and the move out of the sandbox and to > >> version 1.0-beta-1-SNAPSHOT. > >> > >> > >> Staging area: > >> http://people.apache.org/~mauro/staging-repo/ > >> > >> Tag: > >> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plug > >>in-1.0-alpha-14/ > >> > >> Vote open for 72 hours. > >> > >> Here is my +1 > >> > >> [ ] +1 > >> [ ] +0 > >> [ ] -1 > >> > >> > >> > >> --- > >>-- To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >- To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Maven Ant Tasks 2.0.8 (take 2)
+1 Hervé BOUTEMY wrote: Hi, Following Maven release, I'd like to release (again) Maven Ant Tasks 2.0.8. Problem with dependencies order has been fixed. We solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=Html&version=13618 The tasks can be downloaded from: http://people.apache.org/~hboutemy/staging-repo/org/apache/maven/maven-ant-tasks/2.0.8/maven-ant-tasks-2.0.8.jar Staging repo: http://people.apache.org/~hboutemy/staging-repo/ Tag: http://svn.apache.org/viewvc/maven/ant-tasks/tags/maven-ant-tasks-2.0.8/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Dan Fabulich wrote: Uh, actually, I need to turn my vote to a -1. :-( I just discovered that I'm being bitten by MSHADE-5 (and MSHADE-6) every time I go to deploy the Surefire 2.4-SNAPSHOT. As a result, I deployed a corrupted SNAPSHOT... yuck! I just fixed MSHADE-6 in the sandbox, which would have at least prevented me from deploying a defective binary. I still don't see a great way to resolve MSHADE-5 except to pursue a strategy like the one described in MSHADE-7 (perhaps, as dkulp suggested, as an option). I'm going to go try to do the deploy directly from people.apache.org now. :-( Dan, I would seem to me MSHADE-5 is connected to Windows' less-than-optimal filesystem management, I've never seen it on Unix. The fact that it occurs only occasionally is a telling sign. I've commented on MSHADE-7 - as far as I can tell, feature is already implemented, via shadedArtifact attachment. Please try out the configuration in: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0-alpha-14/src/test/projects/shaded-attached-project/pom.xml Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire 2.4-20071210.231259-19 is broken?
Dan Fabulich wrote: Marat Radchenko wrote: Exception in thread "main" java.lang.NoClassDefFoundError: Yes, it sure is! I've been bitten hard by MSHADE-5, which I just re-opened. OK, I've done the deploy from a Linux box to avoid MSHADE-5. The currently deployed snapshot should work a lot better now. Be sure to clear out org/apache/maven/surefire from your local repository; the evil was actually in surefire-api and surefire-booter. Getting the latest maven-surefire-plugin while using old surefire-api and surefire-booter won't fix the problem. (Whew! How embarrassing!) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changed vote Re: [Vote] maven-shade-plugin release 1.0-alpha-14 and move out of sandbox
Uh, actually, I need to turn my vote to a -1. :-( I just discovered that I'm being bitten by MSHADE-5 (and MSHADE-6) every time I go to deploy the Surefire 2.4-SNAPSHOT. As a result, I deployed a corrupted SNAPSHOT... yuck! I just fixed MSHADE-6 in the sandbox, which would have at least prevented me from deploying a defective binary. I still don't see a great way to resolve MSHADE-5 except to pursue a strategy like the one described in MSHADE-7 (perhaps, as dkulp suggested, as an option). I'm going to go try to do the deploy directly from people.apache.org now. :-( -Dan Dan Fabulich wrote: +1. This works with the latest Surefire trunk. (It's a pity MSHADE-9 is still broken, but I think it's OK for another alpha; we should fix it for beta-1.) -Dan Mauro Talevi wrote: As version 1.0-alpha-14 has been staged for release, I'd like to call a vote for its release and the move out of the sandbox and to version 1.0-beta-1-SNAPSHOT. Staging area: http://people.apache.org/~mauro/staging-repo/ Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0-alpha-14/ Vote open for 72 hours. Here is my +1 [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
