[ http://jira.codehaus.org/browse/MRELEASE-151?page=comments#action_72613 ] James Carpenter commented on MRELEASE-151: ------------------------------------------
Relevant discussion on #maven IRC channel: [15:15] nawkboy: The core issue being that whenever maven tries to satisfy the @requiresDependencyResolution it isn't smart enough to look in modules which don't share the same parent pom. [15:16] nawkboy: (It wouldn't surprise me that when building on the command line I get around the problem at first by running mvn -o install. Then the second time I have the snapshot. :) ) [15:16] jdcasey: nawkboy: actually, I don't think that's it [15:17] jdcasey: I think this is something that the assembly plugin has trouble with, too... [15:17] nawkboy: I know this seems to happen before I hit the execute method of the PrepareReleaseMojo. [15:17] nawkboy: (I ran the plugin in my debugger, and never got to the evil line.) [15:17] jdcasey: not sure, but I'm thinking that since it's subbing in the projects for artifacts it would normally resolve externally, these project artifacts aren't resolved (or resolvable, since it didn't run to package phase) [15:18] jdcasey: hang on [15:18] jdcasey: yup, you're going to have to run at least: [15:18] jdcasey: mvn package release:prepare [15:19] jdcasey: ideally, the prepare-release mojo would spawn a forked execution to run to the package phase, to ensure that project-artifacts are resolvable before continuing [15:19] jdcasey: it's an aggregator mojo, which is why this is a problem...at least partially [15:20] jdcasey: nawkboy: let me guess...you got stuck somewhere just inside executeMojo(..) in the plugin manager? [15:20] nawkboy: Can you explain in slightly more detail? I'm only half way understanding the explaination, because I don't completely understand all of the core maven details. I have written and/or modified several plugins but havn't gotten that deep into maven so far. [15:20] jdcasey: ok, so here's the deal...get comfortable ;) [15:20] nawkboy: I think I will. Can quickly give you the line I stick on if needed. (will take about 3min) [15:20] jdcasey: when maven starts up, it will resolve inter-project dependencies that exist among modules [15:21] jdcasey: you'll have to run the build at least to the package phase just before the prepare mojo is called [15:21] jdcasey: so... [15:22] jdcasey: it places a project reference in the MavenProject instances to account for these interdependencies, in the form of an "active" artifact. [15:22] jdcasey: that artifact is "resolved" when the project produces a jar, or whatever artifact is produced by the package phase [15:23] jdcasey: when a mojo requires dependency resolution, these "active" artifacts are a part of that resolution process...if their corresponding projects haven't produced a binary yet, they aren't resolved within the build, and maven looks for them externally (in the repo) [15:23] *** tom has joined #maven. [15:23] jdcasey: since the prepare mojo doesn't require execution to the package phase, the project interdependencies aren't resolved to artifacts, and maven tries to look on the repo for them [15:24] jdcasey: it's part of a sticky problem we're going to try to resolve for 2.1 [15:24] jdcasey: actually, come to think of it, this isn't unique to aggregator mojos [15:24] jdcasey: it's more a side-effect of running a mojo outside of the normal build lifecycle [15:25] nawkboy: So whats the bug fix to the mojo? can I place a quasi-annotation on the mojo to make it first build to the package phase? [15:26] nawkboy: Do I need to internally use the artifactResolver in some explict manner (I had to do this for one of the plugins I wrote) [15:26] jdcasey: you can use @exec phase="package" but you're likely to make some people mad if you were to commit it ;) [15:26] nawkboy: lol [15:26] jdcasey: put that in the class-level javadoc > All child modules are forced to share the same parent POM > --------------------------------------------------------- > > Key: MRELEASE-151 > URL: http://jira.codehaus.org/browse/MRELEASE-151 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Affects Versions: 2.0-beta-4 > Environment: Windows XP > Reporter: James Carpenter > Priority: Blocker > > Problem Description: > Assume the following layout: > fooProject/pom.xml > fooProject/dotnet1/pom.xml (has parent pom of maven-csharp-master-parent) > fooProject/dotnet2/pom.xml (has parent pom of maven-csharp-master-parent) > fooProject/dotnet3/pom.xml (has parent pom of maven-csharp-master-parent) > fooProject/java1/pom.xml (has parent pom found above it ../pom.xml) > fooProject/java2/pom.xml (has parent pom found above it ../pom.xml) > fooProject/java3/pom.xml (has parent pom of > maven-fancy-framework-master-parent) > Assume fooProject/pom.xml lists dotnet1, dotnet2, dotnet3, java1, and java2 > in the modules section. Furthemore, assume that the dotnet modules all refer > to a parent pom of maven-csharp-master-parent rather than refering to the pom > shown at fooProject/pom.xml. By changing into the fooProject directory one > can successfully run mvn clean, and mvn install without any problems. > Unfortunately, the maven release plugin has problems because it seems to > expect all of the child poms to refer to the parent above them. > Motivation: > Any time a child pom needs a bunch of custom plugin's configured, its always > nice to inherit the setup from a parent pom. As it turns out, modules which > should naturally be released and packaged together occassionally need to be > configured quite differently. This is certainly the case whenever dotnet > code is co-released with java code. The dotnet code requires a significant > number of custom plugins be setup for any arbitrary csharp build. It > therefore makes a lot of sense to have a maven-csharp-master-parent to take > care of this. These csharp related configurations are inappropriate for a > java build. In my case the java code happens to be a maven plugin which is > executing the csharp code from a sister module (equivalent in example above > would be for a plugin in fooProject/java1 to be executing code from > fooProject/dotnet3. > Although the motivating example above describes the issue in terms of java > and dotnet build interactions, its not at all unreasonable to think one might > have java code requiring lots of plugins (say cactus configuration, etc) > which would be inappropriate for sister modules. Required differences in > plugin configuration should not impose any constraints on which modules are > considered to be released/packaged together. Maven doesn't impose any such > constraint, but the release plugin is. > Progress So Far: > I havn't taken the time to dig around in the release plugin and figure out > how to fix this. Currently, I am just manually performing what the release > plugin would normally do for me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
