You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Dan Godfrey <da...@gmail.com> on 2012/12/13 13:51:06 UTC
Release plugin & ${project.version} dependencies
Hi,
I'm having trouble using the release-plugin on a project as it is
complaining that it has snapshot dependencies, even though those
dependencies are actually set to ${project.version}. So when the dependency
check phase runs they are indeed SNAPSHOT dependencies, if it were to
continue then they would be updated to non-SNAPSHOT dependencies in a later
phase.
I was wondering if anybody knows of anyway to get around this?
To explain why: I have 2 separate projects project-main & project-windows.
project-main is a jar (well multiple jars)which are deployed to our local
repo. project-windows then takes that deployed jar and packages it up as an
MSI. Both of these projects are kept in lockstep with regards version
numbers and have separate CI jobs. I've split the 2 projects up in
different SCM repos like this as we have have other CI jobs depending on
project-main for testing, and potentially in the future a project-linux,
etc.
Thanks,
Dan.
AW: Release plugin & ${project.version} dependencies
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
Actually the release plugin allows you to specify a release and a development version for any module in your build:
http://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html
Even if this means you have to configure a comandline that is insanely long.
I recently built a Jenkins plugin for Volkswagen and they allowed me to publish that. It's main goal is to allow to configure that commandline by selecting checkboxes and suggesting version.
https://dev.c-ware.de/confluence/display/PUBLIC/Developing+a+Jenkins+Plugin+for+the+Maven+Release+Plugin
It allows to do a "Major" release (All modules are set to the same version) or a minor release, in which you check a checkbox for the modules you want to release. The tool automatically queries a repo for existing versions and suggests a new version number for that minor release. I did do quite some work on that plugin in the last 2 Weeks and am planning on updating my documentation and publishing the code at github as soon as I have the time to cleanup the code and strip out the VW-specifics.
Chris
-----Ursprüngliche Nachricht-----
Von: Robert Scholte [mailto:rfscholte@apache.org]
Gesendet: Donnerstag, 13. Dezember 2012 21:38
An: Maven Users List
Betreff: Re: Release plugin & ${project.version} dependencies
Hi,
the maven-release-plugins only accepts ${project.version} for reactor-projects, i.e. projects being part of a multi-module project.
The fact that your projects are separated also means that they both have their own release-cycle. As you describe, they often(!) will be the same, but if your MSI config is changed, does that require a new project-main?
So I understand why it was implemented like this.
You could change the value for allowTimestampedSnapshots[1] to true, but then you've lost the check for all snapshots.
What you could probably do is combine this with the enforcer rule called RequireReleaseDependencies[2] (have never done this myself though).
Robert
[1]
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots
[2] http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html
Op Thu, 13 Dec 2012 13:51:06 +0100 schreef Dan Godfrey
<da...@gmail.com>:
> Hi,
>
> I'm having trouble using the release-plugin on a project as it is
> complaining that it has snapshot dependencies, even though those
> dependencies are actually set to ${project.version}. So when the
> dependency check phase runs they are indeed SNAPSHOT dependencies, if
> it were to continue then they would be updated to non-SNAPSHOT
> dependencies in a later phase.
>
> I was wondering if anybody knows of anyway to get around this?
>
> To explain why: I have 2 separate projects project-main &
> project-windows.
> project-main is a jar (well multiple jars)which are deployed to our
> local repo. project-windows then takes that deployed jar and packages
> it up as an MSI. Both of these projects are kept in lockstep with
> regards version numbers and have separate CI jobs. I've split the 2
> projects up in different SCM repos like this as we have have other CI
> jobs depending on project-main for testing, and potentially in the
> future a project-linux, etc.
>
> Thanks,
> Dan.
---------------------------------------------------------------------
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: Release plugin & ${project.version} dependencies
Posted by Dan Godfrey <da...@gmail.com>.
In our case the 2 projects will always have the same versions, so you're
correct, if we make a change to the project-windows then it will also
require a release of the project-main artifact. In practice though
project-windows rarely changes, while project-main is constantly in flux,
so that hasn't ever been an issue.
Potentially, these should probably be a single project. However, that would
involve more complexity and maintenance on our CI server and greater chance
for mistakes to happen than just having the 2 separate projects.
Why does it only ignore ${project.version} from the current reactor and not
for all dependencies? There must be something I'm missing, as I can't see
any downside to allowing it for any & all dependencies.
Thanks,
Dan.
On 13 December 2012 20:37, Robert Scholte <rf...@apache.org> wrote:
> Hi,
>
> the maven-release-plugins only accepts ${project.version} for
> reactor-projects, i.e. projects being part of a multi-module project.
> The fact that your projects are separated also means that they both have
> their own release-cycle. As you describe, they often(!) will be the same,
> but if your MSI config is changed, does that require a new project-main? So
> I understand why it was implemented like this.
>
> You could change the value for allowTimestampedSnapshots[1] to true, but
> then you've lost the check for all snapshots.
>
> What you could probably do is combine this with the enforcer rule called
> RequireReleaseDependencies[2] (have never done this myself though).
>
>
> Robert
>
> [1] http://maven.apache.org/**plugins/maven-release-plugin/**
> prepare-mojo.html#**allowTimestampedSnapshots<http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>
> [2] http://maven.apache.org/**enforcer/enforcer-rules/**
> requireReleaseDeps.html<http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html>
>
>
>
>
> Op Thu, 13 Dec 2012 13:51:06 +0100 schreef Dan Godfrey <
> daniel.godfrey@gmail.com>:
>
>
> Hi,
>>
>> I'm having trouble using the release-plugin on a project as it is
>> complaining that it has snapshot dependencies, even though those
>> dependencies are actually set to ${project.version}. So when the
>> dependency
>> check phase runs they are indeed SNAPSHOT dependencies, if it were to
>> continue then they would be updated to non-SNAPSHOT dependencies in a
>> later
>> phase.
>>
>> I was wondering if anybody knows of anyway to get around this?
>>
>> To explain why: I have 2 separate projects project-main & project-windows.
>> project-main is a jar (well multiple jars)which are deployed to our local
>> repo. project-windows then takes that deployed jar and packages it up as
>> an
>> MSI. Both of these projects are kept in lockstep with regards version
>> numbers and have separate CI jobs. I've split the 2 projects up in
>> different SCM repos like this as we have have other CI jobs depending on
>> project-main for testing, and potentially in the future a project-linux,
>> etc.
>>
>> Thanks,
>> Dan.
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Release plugin & ${project.version} dependencies
Posted by Robert Scholte <rf...@apache.org>.
Hi,
the maven-release-plugins only accepts ${project.version} for
reactor-projects, i.e. projects being part of a multi-module project.
The fact that your projects are separated also means that they both have
their own release-cycle. As you describe, they often(!) will be the same,
but if your MSI config is changed, does that require a new project-main?
So I understand why it was implemented like this.
You could change the value for allowTimestampedSnapshots[1] to true, but
then you've lost the check for all snapshots.
What you could probably do is combine this with the enforcer rule called
RequireReleaseDependencies[2] (have never done this myself though).
Robert
[1]
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots
[2] http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html
Op Thu, 13 Dec 2012 13:51:06 +0100 schreef Dan Godfrey
<da...@gmail.com>:
> Hi,
>
> I'm having trouble using the release-plugin on a project as it is
> complaining that it has snapshot dependencies, even though those
> dependencies are actually set to ${project.version}. So when the
> dependency
> check phase runs they are indeed SNAPSHOT dependencies, if it were to
> continue then they would be updated to non-SNAPSHOT dependencies in a
> later
> phase.
>
> I was wondering if anybody knows of anyway to get around this?
>
> To explain why: I have 2 separate projects project-main &
> project-windows.
> project-main is a jar (well multiple jars)which are deployed to our local
> repo. project-windows then takes that deployed jar and packages it up as
> an
> MSI. Both of these projects are kept in lockstep with regards version
> numbers and have separate CI jobs. I've split the 2 projects up in
> different SCM repos like this as we have have other CI jobs depending on
> project-main for testing, and potentially in the future a project-linux,
> etc.
>
> Thanks,
> Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org