You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Bleier Thomas <Th...@arcs.ac.at> on 2007/04/13 13:46:13 UTC

relase plugin, multimodule-project and internal depenencies

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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at> 

 


RE: relase plugin, multimodule-project and internal depenencies

Posted by Doug Tanner <do...@benefitfocus.com>.
You have to change the dependency in Module 2 from version 1.12-Snapshot
to 1.12.

Doug Tanner
 

> -----Original Message-----
> From: Bleier Thomas [mailto:Thomas.Bleier@arcs.ac.at]
> Sent: Friday, April 13, 2007 7:46 AM
> To: users@maven.apache.org
> Subject: relase plugin, multimodule-project and internal depenencies
> 
> 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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at>
> 
> 



****************************************************************************************
BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is intended only for the individual or entity to which it is addressed and may contain information that is confidential and protected by law. Unauthorized review, use, disclosure, or dissemination of this communication or its contents in any way is prohibited and may be unlawful. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please notify the original sender immediately by e-mail or telephone, return the original message to the original sender or to bfpostmaster@benefitfocus.com, and destroy all copies or derivations of the original message. Thank you.  (BFeComNote Rev. 08/01/2005)
***************************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: relase plugin, multimodule-project and internal depenencies

Posted by Roland Asmann <Ro...@cfc.at>.
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:Roland.Asmann@cfc.at]
> 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:Roland.Asmann@cfc.at]
> > 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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at>
> >
> > --
> > 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: Roland.Asmann@cfc.at
> > Web: www.cfc.at
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> --
> 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: Roland.Asmann@cfc.at
> Web: www.cfc.at
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
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: Roland.Asmann@cfc.at
Web: www.cfc.at

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: relase plugin, multimodule-project and internal depenencies

Posted by David Jackman <Da...@fastsearch.com>.
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:Roland.Asmann@cfc.at] 
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:Roland.Asmann@cfc.at]
> 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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at>
>
> --
> 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: Roland.Asmann@cfc.at
> Web: www.cfc.at
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

--
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: Roland.Asmann@cfc.at
Web: www.cfc.at

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: relase plugin, multimodule-project and internal depenencies

Posted by Roland Asmann <Ro...@cfc.at>.
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:Roland.Asmann@cfc.at]
> 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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at>
>
> --
> 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: Roland.Asmann@cfc.at
> Web: www.cfc.at
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
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: Roland.Asmann@cfc.at
Web: www.cfc.at

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


RE: relase plugin, multimodule-project and internal depenencies

Posted by David Jackman <Da...@fastsearch.com>.
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:Roland.Asmann@cfc.at] 
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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at>

--
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: Roland.Asmann@cfc.at
Web: www.cfc.at

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: relase plugin, multimodule-project and internal depenencies

Posted by Roland Asmann <Ro...@cfc.at>.
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: thomas.bleier@arcs.ac.at <ma...@arcs.ac.at>

-- 
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: Roland.Asmann@cfc.at
Web: www.cfc.at

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org