Read my email again. It's not the build machine that gets the wrong thing. It's the machine you used when you did the release:prepare. Because you did an install on that machine as part of the release:prepare, that machine won't download the real deployed version of the released project. So your steps for releasing a project have to include cleaning your own local repository after release:prepare. I'd rather not.
-----Original Message----- From: Roland Asmann [mailto:[EMAIL PROTECTED] Sent: Friday, April 13, 2007 8:05 AM To: Maven Users List Subject: Re: relase plugin, multimodule-project and internal depenencies I think it should be. Anyway, I've noticed that some packaging-types force me to do this. I however do not really find this a problem, since we have a build-server (like you suggested), which cleans its repository (read: deletes the local repo) before releasing. That way we always have the latest deployed version(s) of the projects and plug-ins we use. Packaging-types that have this problem include EJB, WAR and EAR. JARs are no problem (for me), and the others are more or less logical, since they package the referenced JARs, so these MUST exist. I believe it has to do with the order a release is done -> first maven checks if everything builds fine, and deploying is done ONLY if things work. This means that the release tries to find the newly released project (for the problematic packaging-types above) to really create the package. If these packages were build correctly, they are then uploaded to the deployment-server, not before. Thinking about it while typing this mail, I believe this is the correct way. There really is no other way to do this if one of the above packaging-types is used. Besides, on a 'clean' release-server no problems should occur... On Friday 13 April 2007 15:46, David Jackman wrote: > This shouldn't be the "correct" way to do this. If I'm releasing my > projects, I want to deploy the (only) release build of the projects, > not install one build and then deploy another build. This is > especially true if a company "official" build server will be doing the > deploy--if I've done an install as part of the release process, my > local repository will already have that version and won't download the > official deployed version. > Hopefully there is no real difference, but the point is to eliminate > any risk for this. > > ..David.. > > > -----Original Message----- > From: Roland Asmann [mailto:[EMAIL PROTECTED] > Sent: Friday, April 13, 2007 5:56 AM > To: Maven Users List > Subject: Re: relase plugin, multimodule-project and internal > depenencies > > Hi, > > Nothing wrong, I have a similar problem myself. If you add the > release-plugin to your POM and tell it to run the targets 'clean install' > instead of 'clean intergration-test', everything will work fine. > > On Friday 13 April 2007 13:46, Bleier Thomas wrote: > > Hi everyone, > > > > > > > > It seems that I've got some missunderstanding of the maven2 > > mechanisms, and I would be thankfull if someone could help me... > > > > > > > > We have a maven project that consists of several modules. Some of > > them depend on others. To clarify that, I'll try to sketch our > > project > > structure: > > > > > > > > root > > > > |--- pom.xml *1 > > | > > |--- module1 > > | > > | |--- pom.xml *2 > > | > > |--- module2 > > | > > | |--- pom.xml -> depends on module1 > > > > ... > > > > > > > > *1 -> packaging: pom, lists submodules in <modules>, > > <version>1.12-SNAPSHOT</version>, <dependencyManagement> entries for > > the submodules using <version>${project.version}</version> > > > > > > > > *2 -> packaging jar or whatever, <parent> references the above pom, > > no <version> tag for project itself (inherited), dependencies listed > > without <version> tags (-> dependencyManagement) > > > > > > > > > > > > When building the project during development I executed "mvn install" > > in the root folder, and due to the ordering of the modules in the > > parent pom maven builds one module after the other, installs it in > > the local repository, and uses it to build the other modules. > > Everything's fine until here. > > > > > > > > Now when I use the maven-release plugin and execute release:prepare, > > the plugin changes the version numbers from say "1.12-SNAPSHOT" to "1.12" > > and then executes the build, but only up to the "integration-test" > > lifecycle phase. "module1" in my example builds successfully, but > > the build of "module2" fails since "module1-1.12.jar" is obviously > > not available in the local repository. > > > > > > > > What is wrong with my setup? > > > > > > > > Best regards, > > > > __ > > /homas Bleier > > > > > > > > > > > > -- > > > > Thomas Bleier, DI > > Information Management > > Austrian Research Centers GmbH - ARC > > 2444 Seibersdorf, Austria > > > > Mobile: +43 (664) 8251279 > > E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > -- > Roland Asmann > > CFC Informationssysteme Entwicklungsgesellschaft m.b.H Bäckerstrasse > 1/2/7 A-1010 Wien FN 266155f, Handelsgericht Wien > > Tel.: +43/1/513 88 77 - 27 > Fax.: +43/1/513 88 62 > Email: [EMAIL PROTECTED] > Web: www.cfc.at > > --------------------------------------------------------------------- > 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] -- Roland Asmann CFC Informationssysteme Entwicklungsgesellschaft m.b.H Bäckerstrasse 1/2/7 A-1010 Wien FN 266155f, Handelsgericht Wien Tel.: +43/1/513 88 77 - 27 Fax.: +43/1/513 88 62 Email: [EMAIL PROTECTED] Web: www.cfc.at --------------------------------------------------------------------- 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]
