Tuomas Kiviaho edited a comment on Improvement MBUILDHELPER-41

It is certainly seems to be identical and I respect that this one wasn't nuked don't instantly.

I was just looking for providing detachment feature an coincidentally though of those possibilities as well, but compared to MBUILDHELPER-16 I am strongly against of having separate goals for reverted action. Too bad I'm unable to figure out what the arguments were, but I think they revolved around the bad practise concept. Since I believe this has been argued already enough I only back my case with clause stating current situation is like having malloc() without free(). It is the first impression that many get when they are first time introduced to this Mojo and I bet that any use case presented in favor of using the goals in reversed manner would be quickly turned down because there are more sane manner to deal with them. Bbut knowing that these reverse options exist would give a sort of comfort even though they'd never had to be used. Instead of having to prove myself right (sorry about the Use Case 1), I'm facing a real regression problem that can't be dealt without project level re-factoring (Use Case 2 continues in detail below).

Maven/M2E regression no longer attaches test artifacts beforehand

I am using maven bundle plugin to craft an OSGi bundle for me and I use it's unpack to provide an exploded jar under testOutputDirectory and this practice provides Hot Code Replacement when that directory is installed to OSGi Framework direct reference. This practice is similar to exploded war feature so I'm not doing anything extraordinary other than exploding test-jar as well.

Due to recent changes (I believe?) in the maven core or M2E I don't seem to be getting the testOutputDirectory as attachment with tests prior it is actually attached. I guess that it has something to do with giving more options to @requiresDependencyResolution("test") plugin directive. Maven Aether has still the capability of dealing with the output directories between (test-)compile phase and package phase so this test-jar approach is still possible.

My "brilliant" idea was to attach the test artifact before it's time to reference to exploded jar in testOutputDirectory and let that be overridden at package phase in terms of emulating the earlier behavior of Maven. Everything worked perfectly with this build helper option until I realized that attachments do not overwrite each other but instead a duplicate is created. In this case I noticed that the type would differ anyway so I'd be installing a test directory at the end if I didn't get rid of the attachment at prepare-package phase.

Therefore I patched the plugin because it dealt with the regression instantly. I only wish that the option would have been there already so that I could have hacked myself out of the situation right away without having to fork the plugin. A separate project for tests will indeed work fine in the future but this alternative provided backwards compatibility quite instantly because I was able to place it to parent pom as-is.

I've always been afraid that there would be time for reversion when I've been adding source directory that I don't want to be compiled for instance and here I had such a case.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email

Reply via email to