On 08/03/2009, at 2:27 AM, Benjamin Bentmann wrote:
The solution [0] I propose additionally solves MNG-3043 and would supercede the current approach for MNG-2871. Essentially, MavenProject.replaceWithActiveArtifact() will fallback to either the main or test output directory in case no real artifact has been assembled/attached so far.
+1
If nobody has objections to this approach or sees severe dangers with it, I would like to apply this to 2.1.x and 3.x. WDYT?
Sorry for having read these in reverse. I do think it is worth us improving the documented rules + ITs for reactor resolution in 2.1.0 if it is already ready to go in. Maybe it's just waiting for the coffee to kick in, but I don't see any immediate problems with this since it's just a fallback.
(Another reference: http://markmail.org/thread/4ui3cr6fs5k7pnan) Regarding the longer term: On 08/03/2009, at 2:59 AM, Jason van Zyl wrote:
What I'm looking at in 3.x is that there can N repositories that partake in the execution of a lifecycle. I see a layering of any number of local repositories which may include the local repository as we know it, IDE workspaces and the reactor (which is a workspace of sorts).
+1 (this would also work in nicely with the objectives of http://docs.codehaus.org/display/MAVEN/Local+repository+separation)
Right now the logic for picking out plugins and artifacts while in a reactor is a mess. I'm in the middle of refactoring the plugin manager and lifecycle executor right now but when I'm finished the execution request, and therefore the session, will contain this layering of repositories. One of these implementations will be the "reactor repository". So if you can encapsulate your logic above in a component then I can just reuse that in the reactor repository. Implement whatever behavior you initially think is appropriate and once it's all in one place it's easy to adjust the rules.
+1 Cheers, Brett -- Brett Porter [email protected] http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
