You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by maarten roosendaal <mr...@yahoo.com> on 2007/11/01 13:19:38 UTC
Re: maven-release-plugin best practice question
Hi,
I found the problem, i was also using the enforcer-plugin in a parent pom.xml. It was configured with goal 'enforce-once' which prevented a correct release:prepare. I've got things working now.
Another problem was with Archiva, which is a bit unstable when it comes to deploying 1 artifact multiple times in a short period. Some files are made read-only which cause an '507 Insufficient Storage' error. Restarting solves this problem, temporarily.
Thanks for the tips and help,
Maarten
----- Original Message ----
From: maarten roosendaal <mr...@yahoo.com>
To: Maven Users List <us...@maven.apache.org>
Sent: Tuesday, October 30, 2007 1:15:07 PM
Subject: Re: maven-release-plugin best practice question
I don't understand the first remark. It shouldn't matter what packaging
it is (jar, war, ejb, sar) should it?
I configured the release plugin just as posted but the result remains
the same. Here is the log:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] MainProject
[INFO] Module-B
[INFO] Module-A
[INFO] Searching repository for plugin with prefix: 'release'.
WAGON_VERSION: 1.0-beta-1
[INFO]
----------------------------------------------------------------------------
[INFO] Building MainProject
[INFO] task-segment: [release:prepare] (aggregator-style)
[INFO]
----------------------------------------------------------------------------
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'MainProject'...
[INFO] Updating Module-A to 0.0.1
[INFO] Ignoring artifact version update for expression:
${project.version}
[INFO] Updating Module-B to 0.0.1
[INFO] Ignoring artifact version update for expression:
${project.version}
[INFO] Checking out file:
C:\ccviews\view\project\04.Implementation\pom.xml
[INFO] Transforming 'Module-B Project'...
[INFO] Checking out file:
C:\ccviews\view\project\04.Implementation\Module-B\pom.xml
[INFO] Transforming 'Module-A Project'...
[INFO] Updating Module-B to 0.0.1
[INFO] Checking out file:
C:\ccviews\view\project\04.Implementation\Module-A\pom.xml
[INFO] Not generating release POMs
[INFO] Executing goals 'clean install'...
[INFO] Executing: mvn clean install --no-plugin-updates --batch-mode -P
repo-proxy,repo-proxy
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] MainProject
[INFO] Module-B Project
[INFO] Module-A Project
WAGON_VERSION: 1.0-beta-1
[INFO]
----------------------------------------------------------------------------
[INFO] Building MainProject
[INFO] task-segment: [clean, install]
[INFO]
----------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target\classes
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target\test-classes
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target\site
[INFO] [cobertura:clean {execution: default}]
Downloading:
http://archiva:8180/archiva/repository/internal//com/ibm/db2/db2java/1.0/db2java-1.0.pom
Downloading:
http://repo1.maven.org/maven2/com/ibm/db2/db2java/1.0/db2java-1.0.pom
Downloading:
http://archiva:8180/archiva/repository/internal//nl/module-b/0.0.1/module-b-0.0.1.jar
Downloading:
http://repo1.maven.org/maven2/nl/module-b/0.0.1/module-b-0.0.1.jar
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) nl:module-b:jar:0.0.1
Try downloading the file manually from the project website.
Then, install it using the command:
<omitted>
Path to dependency:
1) nl:module-a:jar:0.0.1
2) nl:module-b:jar:0.0.1
----------
1 required artifact is missing.
for artifact:
nl:module-a:jar:0.0.1
from the specified remote repositories:
......
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 12 seconds
[INFO] Finished at: Tue Oct 30 12:37:27 CET 2007
[INFO] Final Memory: 13M/32M
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 42 seconds
[INFO] Finished at: Tue Oct 30 12:37:29 CET 2007
[INFO] Final Memory: 7M/33M
[INFO]
------------------------------------------------------------------------
So what you see is that maven will look for module-b in de archiva repo
when it should not be looking for anything at that point.
----- Original Message ----
From: Nicole Lacoste <ni...@gmail.com>
To: Maven Users List <us...@maven.apache.org>
Sent: Tuesday, October 30, 2007 12:16:33 PM
Subject: Re: maven-release-plugin best practice question
Um, not sure. Whats the packaging on module A? If its not a jar, you
must
make sure its installed, by as Graham said configuring the release
plugin in
the parent pom's build section as follows.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-6</version>
<configuration>
<preparationGoals>clean install</preparationGoals>
</configuration>
</plugin>
BTW there is a ne version of the release plugin 2.0-beta-7
On 30/10/2007, maarten roosendaal <mr...@yahoo.com> wrote:
>
> I did delete all the versions in the coordinates and dependencies of
the
> childpom's (except for the parent which is an explicit definition -->
> 0.0.1-SNAPSHOT not ${project.version}) and added
> dependencyManagement for all modules with ${project.version}.
>
> However performing a release:prepare still fails because when
building the
> root project it says that it can't find
> a version of module A (0.0.1). I have both modules as part of the
> module-tag in the root pom.xml and a normal install works fine.
>
> What parameters are you using when calling release:prepare? How did
you
> configure the plugin?
>
> ----- Original Message ----
> From: Nicole Lacoste <ni...@gmail.com>
> To: Maven Users List <us...@maven.apache.org>
> Sent: Tuesday, October 30, 2007 9:39:14 AM
> Subject: Re: maven-release-plugin best practice question
>
>
> Hi,
>
> Don't put ANY versions in child poms EXCEPT for the parent version.
If
> module B depends on module A, declare the version of module A and B
in
> the
> common parent pom dependency management section (your main project if
I
> understand right), with ${project.version}. There should only be one
> <version>***</version> in any child pom and that is in parent
section.
> The
> fact that you say that the version is not updated in the child, means
> that
> this is currently not the case, you currently are using a version
> somewhere
> in a child project, don't declare the child version, or his
dependency
> versions. In the dependency section, declare all artifacts without
> version,
> the versions are picked up from the dependency management of his
> parent.
>
> Nicole
>
>
> On 30/10/2007, maarten roosendaal <mr...@yahoo.com> wrote:
> >
> > Hi,
> >
> > Apparently this does not work for my project. It stil does not
update
> the
> > versions in the dependencies. Using either $(pom.version} or $(
> > project.version} with our without dependencyManagement still does
not
> > solve the issue.
> >
> > Just to be sure:
> > project Main
> > module A (dependent on module B)
> > module B
> >
> > when doing a release:prepare (dryRun) you will see that in the
> pom.xml.tagthe version of the dependency is update from
> > 0.0.1-SNAPSHOT to 0.0.1 so that is good. But when i look in the
> > pom.xml.next the dependency.version is still 0.0.1-SNAPSHOT in
stead
> of
> > 0.0.2-SNAPSHOT. I believe this is a bug: MRELEASE-295. (i hope this
> gets
> > solved quickly, takes some manual labour to change all the
versions);
> >
> > The addition of the configuration also does not work. My build
starts
> with
> > the root pom.xml and at that point i get that it is missing version
> 0.0.1of module B. So it doesn't even get to installing modules
> atomically.
> >
> > I use: mvn --batch-mode release:prepare -DuseEditMode=true and i
have
> > added the plugin to the root pom.xml
> >
> > Any suggestions or ideas where to look or what to do?
> >
> > Thanks,
> > Maarten
> >
> >
> >
> > ----- Original Message ----
> > From: Graham Leggett <mi...@sharp.fm>
> > To: Maven Users List <us...@maven.apache.org>
> > Cc: users@maven.apache.org
> > Sent: Monday, October 29, 2007 4:29:25 PM
> > Subject: Re: maven-release-plugin best practice question
> >
> >
> > On Mon, October 29, 2007 5:18 pm, maarten roosendaal wrote:
> >
> > > I'm working with the maven-release-plugin and it works fine
except
> > for the
> > > fact that my own <module>-<version>-SNAPSHOT dependencies in
> various
> > > pom.xml's do no get updated when performing a release:prepare.
> > >
> > > I thought i could use the dependencyManagement for this but when
i
> > use
> > > this and do a release:prepare and start building, several modules
> > will
> > > look for dependencies with the release version instead of the old
> > SNAPSHOT
> > > version.
> > >
> > > What is the (best) way to avoid having to manually change all the
> > > versionumbers in de dependencies in the pom.xml's (we have 12)
> before
> > > performing a release?
> >
> > If all 12 dependencies are typically released at the same time,
then
> > group
> > them together as a multi-module build and release the multi-module
> > build
> > in one go.
> >
> > We set the version in the root pom of our multi-module build, and
in
> > all
> > submodules, the version is inherited and accessed using
> ${pom.version}.
> >
> > When the release:perform is run from the root of the multi-module
> > build,
> > all the version numbers are handled automatically.
> >
> > One thing that the release plugin likes to do when testing a
> > multimodule
> > build is to miss out the install phase, which can cause potential
> > confusion as each of your submodules isn't installed and used by
the
> > next
> > submodule. To work around this problem, add this to your root pom:
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-release-plugin</artifactId>
> > <version>2.0-beta-6</version>
> > <configuration>
> > <preparationGoals>clean install</preparationGoals>
> > </configuration>
> > </plugin>
> >
> > Regards,
> > Graham
> > --
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: maven-release-plugin best practice question
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Don't use enforce-once, just use enforce.
-----Original Message-----
From: maarten roosendaal [mailto:mroosendaal@yahoo.com]
Sent: Thursday, November 01, 2007 8:20 AM
To: Maven Users List
Subject: Re: maven-release-plugin best practice question
Hi,
I found the problem, i was also using the enforcer-plugin in a parent
pom.xml. It was configured with goal 'enforce-once' which prevented a
correct release:prepare. I've got things working now.
Another problem was with Archiva, which is a bit unstable when it comes
to deploying 1 artifact multiple times in a short period. Some files are
made read-only which cause an '507 Insufficient Storage' error.
Restarting solves this problem, temporarily.
Thanks for the tips and help,
Maarten
----- Original Message ----
From: maarten roosendaal <mr...@yahoo.com>
To: Maven Users List <us...@maven.apache.org>
Sent: Tuesday, October 30, 2007 1:15:07 PM
Subject: Re: maven-release-plugin best practice question
I don't understand the first remark. It shouldn't matter what packaging
it is (jar, war, ejb, sar) should it?
I configured the release plugin just as posted but the result remains
the same. Here is the log:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] MainProject
[INFO] Module-B
[INFO] Module-A
[INFO] Searching repository for plugin with prefix: 'release'.
WAGON_VERSION: 1.0-beta-1
[INFO]
------------------------------------------------------------------------
----
[INFO] Building MainProject
[INFO] task-segment: [release:prepare] (aggregator-style)
[INFO]
------------------------------------------------------------------------
----
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'MainProject'...
[INFO] Updating Module-A to 0.0.1
[INFO] Ignoring artifact version update for expression:
${project.version}
[INFO] Updating Module-B to 0.0.1
[INFO] Ignoring artifact version update for expression:
${project.version}
[INFO] Checking out file:
C:\ccviews\view\project\04.Implementation\pom.xml
[INFO] Transforming 'Module-B Project'...
[INFO] Checking out file:
C:\ccviews\view\project\04.Implementation\Module-B\pom.xml
[INFO] Transforming 'Module-A Project'...
[INFO] Updating Module-B to 0.0.1
[INFO] Checking out file:
C:\ccviews\view\project\04.Implementation\Module-A\pom.xml
[INFO] Not generating release POMs
[INFO] Executing goals 'clean install'...
[INFO] Executing: mvn clean install --no-plugin-updates --batch-mode -P
repo-proxy,repo-proxy
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] MainProject
[INFO] Module-B Project
[INFO] Module-A Project
WAGON_VERSION: 1.0-beta-1
[INFO]
------------------------------------------------------------------------
----
[INFO] Building MainProject
[INFO] task-segment: [clean, install]
[INFO]
------------------------------------------------------------------------
----
[INFO] [clean:clean]
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target\classes
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target\test-classes
[INFO] Deleting directory
C:\ccviews\view\project\04.Implementation\target\site
[INFO] [cobertura:clean {execution: default}]
Downloading:
http://archiva:8180/archiva/repository/internal//com/ibm/db2/db2java/1.0
/db2java-1.0.pom
Downloading:
http://repo1.maven.org/maven2/com/ibm/db2/db2java/1.0/db2java-1.0.pom
Downloading:
http://archiva:8180/archiva/repository/internal//nl/module-b/0.0.1/modul
e-b-0.0.1.jar
Downloading:
http://repo1.maven.org/maven2/nl/module-b/0.0.1/module-b-0.0.1.jar
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) nl:module-b:jar:0.0.1
Try downloading the file manually from the project website.
Then, install it using the command:
<omitted>
Path to dependency:
1) nl:module-a:jar:0.0.1
2) nl:module-b:jar:0.0.1
----------
1 required artifact is missing.
for artifact:
nl:module-a:jar:0.0.1
from the specified remote repositories:
......
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 12 seconds
[INFO] Finished at: Tue Oct 30 12:37:27 CET 2007
[INFO] Final Memory: 13M/32M
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 42 seconds
[INFO] Finished at: Tue Oct 30 12:37:29 CET 2007
[INFO] Final Memory: 7M/33M
[INFO]
------------------------------------------------------------------------
So what you see is that maven will look for module-b in de archiva repo
when it should not be looking for anything at that point.
----- Original Message ----
From: Nicole Lacoste <ni...@gmail.com>
To: Maven Users List <us...@maven.apache.org>
Sent: Tuesday, October 30, 2007 12:16:33 PM
Subject: Re: maven-release-plugin best practice question
Um, not sure. Whats the packaging on module A? If its not a jar, you
must
make sure its installed, by as Graham said configuring the release
plugin in
the parent pom's build section as follows.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-6</version>
<configuration>
<preparationGoals>clean install</preparationGoals>
</configuration>
</plugin>
BTW there is a ne version of the release plugin 2.0-beta-7
On 30/10/2007, maarten roosendaal <mr...@yahoo.com> wrote:
>
> I did delete all the versions in the coordinates and dependencies of
the
> childpom's (except for the parent which is an explicit definition -->
> 0.0.1-SNAPSHOT not ${project.version}) and added
> dependencyManagement for all modules with ${project.version}.
>
> However performing a release:prepare still fails because when
building the
> root project it says that it can't find
> a version of module A (0.0.1). I have both modules as part of the
> module-tag in the root pom.xml and a normal install works fine.
>
> What parameters are you using when calling release:prepare? How did
you
> configure the plugin?
>
> ----- Original Message ----
> From: Nicole Lacoste <ni...@gmail.com>
> To: Maven Users List <us...@maven.apache.org>
> Sent: Tuesday, October 30, 2007 9:39:14 AM
> Subject: Re: maven-release-plugin best practice question
>
>
> Hi,
>
> Don't put ANY versions in child poms EXCEPT for the parent version.
If
> module B depends on module A, declare the version of module A and B
in
> the
> common parent pom dependency management section (your main project if
I
> understand right), with ${project.version}. There should only be one
> <version>***</version> in any child pom and that is in parent
section.
> The
> fact that you say that the version is not updated in the child, means
> that
> this is currently not the case, you currently are using a version
> somewhere
> in a child project, don't declare the child version, or his
dependency
> versions. In the dependency section, declare all artifacts without
> version,
> the versions are picked up from the dependency management of his
> parent.
>
> Nicole
>
>
> On 30/10/2007, maarten roosendaal <mr...@yahoo.com> wrote:
> >
> > Hi,
> >
> > Apparently this does not work for my project. It stil does not
update
> the
> > versions in the dependencies. Using either $(pom.version} or $(
> > project.version} with our without dependencyManagement still does
not
> > solve the issue.
> >
> > Just to be sure:
> > project Main
> > module A (dependent on module B)
> > module B
> >
> > when doing a release:prepare (dryRun) you will see that in the
> pom.xml.tagthe version of the dependency is update from
> > 0.0.1-SNAPSHOT to 0.0.1 so that is good. But when i look in the
> > pom.xml.next the dependency.version is still 0.0.1-SNAPSHOT in
stead
> of
> > 0.0.2-SNAPSHOT. I believe this is a bug: MRELEASE-295. (i hope this
> gets
> > solved quickly, takes some manual labour to change all the
versions);
> >
> > The addition of the configuration also does not work. My build
starts
> with
> > the root pom.xml and at that point i get that it is missing version
> 0.0.1of module B. So it doesn't even get to installing modules
> atomically.
> >
> > I use: mvn --batch-mode release:prepare -DuseEditMode=true and i
have
> > added the plugin to the root pom.xml
> >
> > Any suggestions or ideas where to look or what to do?
> >
> > Thanks,
> > Maarten
> >
> >
> >
> > ----- Original Message ----
> > From: Graham Leggett <mi...@sharp.fm>
> > To: Maven Users List <us...@maven.apache.org>
> > Cc: users@maven.apache.org
> > Sent: Monday, October 29, 2007 4:29:25 PM
> > Subject: Re: maven-release-plugin best practice question
> >
> >
> > On Mon, October 29, 2007 5:18 pm, maarten roosendaal wrote:
> >
> > > I'm working with the maven-release-plugin and it works fine
except
> > for the
> > > fact that my own <module>-<version>-SNAPSHOT dependencies in
> various
> > > pom.xml's do no get updated when performing a release:prepare.
> > >
> > > I thought i could use the dependencyManagement for this but when
i
> > use
> > > this and do a release:prepare and start building, several modules
> > will
> > > look for dependencies with the release version instead of the old
> > SNAPSHOT
> > > version.
> > >
> > > What is the (best) way to avoid having to manually change all the
> > > versionumbers in de dependencies in the pom.xml's (we have 12)
> before
> > > performing a release?
> >
> > If all 12 dependencies are typically released at the same time,
then
> > group
> > them together as a multi-module build and release the multi-module
> > build
> > in one go.
> >
> > We set the version in the root pom of our multi-module build, and
in
> > all
> > submodules, the version is inherited and accessed using
> ${pom.version}.
> >
> > When the release:perform is run from the root of the multi-module
> > build,
> > all the version numbers are handled automatically.
> >
> > One thing that the release plugin likes to do when testing a
> > multimodule
> > build is to miss out the install phase, which can cause potential
> > confusion as each of your submodules isn't installed and used by
the
> > next
> > submodule. To work around this problem, add this to your root pom:
> >
> > <plugin>
> > <groupId>org.apache.maven.plugins</groupId>
> > <artifactId>maven-release-plugin</artifactId>
> > <version>2.0-beta-6</version>
> > <configuration>
> > <preparationGoals>clean install</preparationGoals>
> > </configuration>
> > </plugin>
> >
> > Regards,
> > Graham
> > --
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org