Thank to all. I'll try the latest version of the release plugin against a simple project setup as proposed. I'm still l uncertain whether to use the property or hardcoded version...
2009/3/24 Todd Thiessen <[email protected]> > > Interesting. How should the plugin this without installing? > > I am not sure. I have not walked through the code to find out. The release > plugin must put the target directory of dependant modules on its classpath > so it can find those artifacts. But I have seen the release plugin fail in > the same way you are seeing it and I couldn't explain it. The projects it > was failing on were not a project I owned but were projects I simply made a > checkout of and tried to do a build so there were likely some things going > on there that the release plugin didn't like. For instance I suspect if you > have some generated code or if you have a module which uses something other > than the target directory, the release plugin may not be able to find those > artifacts. > > I am taking educated guesses though. I have not yet taken the time to > figure this one out on my own (hard to find the time to figure out > everything). I have been hoping that a more knowledgable release plugin dev > would fill in some details here but I have not seen or found such a > response. > > > > > > > > If all else fails, you could do that (ie: install first) although > > > there have been a number of Maven users on this list who > > have spoken > > > against this approach. > > > > > > > This is would mean I'd have to replace the SNAPSHOT Version > > manually before the release to trigger the install. Maybe I > > should try to add "install" to the preperartionGoals. > > Yes. Using the preperationGoals configuration was what I was referring to. > > Before you do that, however, I would recommend taking the time to create a > very simple multi-module project to see the release plugin work without > having to install dependant modules first. It does seem to work and there is > likely something special about your project which is causing it to fail. If > you do figure it out, please post it to this list. > > > > > > > > > > > So why does the release plugin display a message indicating that an > > > install should be done first? I don't know but would really > > like to ;-). > > > > > > --- > > > Todd Thiessen > > > > > > > > > > -----Original Message----- > > > > From: Reinhard Nägele [mailto:[email protected]] > > > > Sent: Tuesday, March 24, 2009 8:13 AM > > > > To: Maven Users List > > > > Subject: Re: Release plugin and multimodule interdependent childs > > > > > > > > I don't have a solution to your problem, but I would > > advice against > > > > putting the real version number instead of > > ${project.version}. It is > > > > good practice to avoid such redundancy using ${project.version}, > > > > even though the release plugin can deal with explicit versions. > > > > Using ${project.version} is also suggested by "The > > Definitive Guide" > > > > > > (http://www.sonatype.com/products/maven/documentation/book-defguide). > > > > > > > > Reinhard > > > > > > > > > > > > Martin Eigenbrodt schrieb: > > > > > I've replaced ${project.version} with 1.1-SNAPSHOT. The > > > > Release plugin > > > > > replaces this with 1.1 during release:prepare and fails > > > > with the same > > > > > message. > > > > > I think the release plugin should first trigger a install > > > > on the ejb > > > > > and then run the servlet target. > > > > > > > > > > 2009/3/24 Jörg Schaible <[email protected]> > > > > > > > > > > > > > > >> Martin Eigenbrodt wrote at Dienstag, 24. März 2009 10:16: > > > > >> > > > > >> > > > > >>> This may be a beginner question, but I haven't found > > any hints.. > > > > >>> I've got a project that contains a servlet and an ejb. The > > > > >>> Servlet > > > > >>> > > > > >> depends > > > > >> > > > > >>> on the ejb. I've trouble releasing that as complete project. > > > > >>> > > > > >>> My directory Layout is like: > > > > >>> > > > > >>> pom.xml <- package type pom > > > > >>> servlet > > > > >>> pom.xml > > > > >>> ejb > > > > >>> pom.xml > > > > >>> > > > > >>> the parent pom has version 1.1-SNAPSHOT. The Servlet > > an ejb pom > > > > >>> don't specify a version (inherit them). > > > > >>> The Servlet defines a dependecy on the ejb without > > > > specifing a version. > > > > >>> The dependencyMangement section from the parent pom contains: > > > > >>> <dependencies> > > > > >>> <dependency> > > > > >>> <groupId>myGroup<groupId> > > > > >>> <artifactId>ejb<artifactId> > > > > >>> <version>${project.version}</version> > > > > >>> </dependency> > > > > >>> > > > > >>> If I try release:prepare the build fails with "Failed > > to resolve > > > > >>> artifacts: myGroup:ejb:1.1 > > > > >>> > > > > >>> I understand why this happens but is there a obvious > > > > solution? How > > > > >>> do you release multimodule projects with > > interdependent childs? > > > > >>> > > > > >> Do not use that property and write the corretc version. > > > > The release > > > > >> plugin will then handle it and adjust it automatically. > > > > >> > > > > >> - Jörg > > > > >> > > > > >> > > > > >> > > > > > > -------------------------------------------------------------------- > > > > - > > > > >> 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
