True, but since I do the release:prepare on the release-machine -- which deletes its local repo like I wrote -- I do get the released version on MY local machine.
Besides, cleaning out your own local repo now and again doesn't hurt... On Friday 13 April 2007 16:37, David Jackman wrote: > 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] -- 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]
