You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Leon Rosenberg <ro...@gmail.com> on 2010/10/15 08:28:41 UTC
Now seriously: how can I manage dependencies of own projects with maven
Hello,
following situation:
I have like 20 projects which are libs of different level. They are
all built as jars. They are partially dependent on each other (not
circularly).
For example project A provides very basic utils. Project B is more
specialized and depends on A. Project C depends on A, project D on A
and C.
I have two requirements:
First: I want them to depend on a released version of each other, not
necessary last release, but preferred.
This work if I declare the dependency as RELEASE or a version number like 1.0.2
Second:
I want to be able to build automatically each night to check whether
the last svn committed changes of the projects break the dependent
projects.
This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT.
The problem with SNAPSHOT is that If I release 1.0.1 of project B it
upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if
I previously released an 1.0.1 of project A).
As a result I am not able to release 1.0.2 of project B until I have
released 1.0.2 of A, even I had no changes in A.
Therefore the question, how can I teach maven that project depend on
RELEASEd versions of each other for release process and dependency
management on the one side, and on svn snapshots for CI purposes on
the other?
The only thing I can come up with right now is to have two different
poms for each project, with different dependencies. But this sounds
like a mess to maintain :-(.
I have done this before with ant+ivy by simple declaring a file based
'local repository'. This local repository existed only in the context
of a job. I than had a hudson job that checked out all 20 projects and
published them one after each other into the local repository. If some
versions would not compile, the job would fail and send an alert. This
hasn't affected already released versions. Is something similar
possible with maven?
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Benson Margulies <bi...@gmail.com>.
On Wed, Oct 20, 2010 at 8:12 AM, Michael McCallum
<mi...@redengine.co.nz> wrote:
> You could try something like...
>
> mvn -s special-settings-file.xml verify install
haha. Hudson has a horrible bug involving -s that the maintainers keep
claiming to fix and failing to fix. Perhaps some day.
>
> set that up for the jobs in hudson that should share snapshots...
>
> and for the others
>
> mvn verify
>
> So you end up with two sets of jobs
> * those the build the head of an artifact against the heads of the others
> * those that build the head of an artifact against the latest releases of the others (assuming you use ranges of course)
>
> cheers
>
> Michael
>
> On Wednesday 20 October 2010 00:25:33 Benson Margulies wrote:
>> If you are using 'downstream', how do you avoid the need to publish to
>> at least a common local repo?
>>
>> I've been facing the following variation on this:
>>
>> I do not want to publish snapshots to nexus, since they mess up people
>> who download stale ones into their development process.
>>
>> I do want to split a hudson build into multiple jobs with dependencies.
>>
>> Short of an extra repo in nexus that is used only for intra-hudson
>> snapshots, I haven't thought of anything. Have you?
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Michael McCallum <mi...@redengine.co.nz>.
You could try something like...
mvn -s special-settings-file.xml verify install
set that up for the jobs in hudson that should share snapshots...
and for the others
mvn verify
So you end up with two sets of jobs
* those the build the head of an artifact against the heads of the others
* those that build the head of an artifact against the latest releases of the others (assuming you use ranges of course)
cheers
Michael
On Wednesday 20 October 2010 00:25:33 Benson Margulies wrote:
> If you are using 'downstream', how do you avoid the need to publish to
> at least a common local repo?
>
> I've been facing the following variation on this:
>
> I do not want to publish snapshots to nexus, since they mess up people
> who download stale ones into their development process.
>
> I do want to split a hudson build into multiple jobs with dependencies.
>
> Short of an extra repo in nexus that is used only for intra-hudson
> snapshots, I haven't thought of anything. Have you?
>
> ---------------------------------------------------------------------
> 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: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
stripped
On 19 October 2010 16:50, Wayne Fay <wa...@gmail.com> wrote:
>> Attached is a sample of how I configure the builders (using
>> update-properties as my inter-module deps are via properties for this
>> uber-integration-project) the principle remains the same
>
> Either you failed to attach anything, or it got stripped.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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: Now seriously: how can I manage dependencies of own projects with maven
Posted by Wayne Fay <wa...@gmail.com>.
> Attached is a sample of how I configure the builders (using
> update-properties as my inter-module deps are via properties for this
> uber-integration-project) the principle remains the same
Either you failed to attach anything, or it got stripped.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
Attached is a sample of how I configure the builders (using
update-properties as my inter-module deps are via properties for this
uber-integration-project) the principle remains the same
On 19 October 2010 12:50, Stephen Connolly
<st...@gmail.com> wrote:
> On 19 October 2010 12:42, Benson Margulies <bi...@gmail.com> wrote:
>> On Tue, Oct 19, 2010 at 7:28 AM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>> because downstream is the trigger, the build checks everything out and
>>> uses an uber-aggregator build so that all the artifacts will be in the
>>> reactor which is how "mvn verify" can work (no need for clean because
>>> I do a clean checkout for every build)
>>
>> I'm confused between the implications of 'uberaggregated' and
>> 'downstream'. You've combined all the pieces into one giant build that
>> is downstream of something else, right? OK, I see.
>
> it's downstream of the trunks of each of it's components...
>
> the trunk projects build svn as is and are triggered by svn trigger
>
> this is the "latest of everything project" and that builds only if the
> constituent trunk projects are building, and wht it is building is not
> the code in svn but the code in svn after re-linking to the
> reactor.... hmmm I think I might have a new feature for versions-m-p
> (versions:use-reactor)
>
> -Stephen
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
On 19 October 2010 12:42, Benson Margulies <bi...@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 7:28 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>> because downstream is the trigger, the build checks everything out and
>> uses an uber-aggregator build so that all the artifacts will be in the
>> reactor which is how "mvn verify" can work (no need for clean because
>> I do a clean checkout for every build)
>
> I'm confused between the implications of 'uberaggregated' and
> 'downstream'. You've combined all the pieces into one giant build that
> is downstream of something else, right? OK, I see.
it's downstream of the trunks of each of it's components...
the trunk projects build svn as is and are triggered by svn trigger
this is the "latest of everything project" and that builds only if the
constituent trunk projects are building, and wht it is building is not
the code in svn but the code in svn after re-linking to the
reactor.... hmmm I think I might have a new feature for versions-m-p
(versions:use-reactor)
-Stephen
>
> ---------------------------------------------------------------------
> 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: Now seriously: how can I manage dependencies of own projects with maven
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Oct 19, 2010 at 7:28 AM, Stephen Connolly
<st...@gmail.com> wrote:
> because downstream is the trigger, the build checks everything out and
> uses an uber-aggregator build so that all the artifacts will be in the
> reactor which is how "mvn verify" can work (no need for clean because
> I do a clean checkout for every build)
I'm confused between the implications of 'uberaggregated' and
'downstream'. You've combined all the pieces into one giant build that
is downstream of something else, right? OK, I see.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
because downstream is the trigger, the build checks everything out and
uses an uber-aggregator build so that all the artifacts will be in the
reactor which is how "mvn verify" can work (no need for clean because
I do a clean checkout for every build)
On 19 October 2010 12:25, Benson Margulies <bi...@gmail.com> wrote:
> If you are using 'downstream', how do you avoid the need to publish to
> at least a common local repo?
>
> I've been facing the following variation on this:
>
> I do not want to publish snapshots to nexus, since they mess up people
> who download stale ones into their development process.
>
> I do want to split a hudson build into multiple jobs with dependencies.
>
> Short of an extra repo in nexus that is used only for intra-hudson
> snapshots, I haven't thought of anything. Have you?
>
> ---------------------------------------------------------------------
> 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: Now seriously: how can I manage dependencies of own projects with maven
Posted by Benson Margulies <bi...@gmail.com>.
If you are using 'downstream', how do you avoid the need to publish to
at least a common local repo?
I've been facing the following variation on this:
I do not want to publish snapshots to nexus, since they mess up people
who download stale ones into their development process.
I do want to split a hudson build into multiple jobs with dependencies.
Short of an extra repo in nexus that is used only for intra-hudson
snapshots, I haven't thought of anything. Have you?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
On 18 October 2010 23:15, Zac Thompson <za...@zac.ca> wrote:
> On Fri, Oct 15, 2010 at 6:34 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>> I just set up a big fat aggrigator for each of the "test everything
>> together" projects that I want to run CI over. I use svn:externals to
>> check everything out and then two maven builders, first to update the
>> aggregator and all child modules to link them together and the second
>> to run "verify". That way I never pollute the local repo... and these
>> types of build run less frequently (hourly), so the slower build is
>> less of an issue.
>>
>
> Thanks for this bit, Stephen; I've been considering doing exactly this
> for a little while, so it's good to know you've already proven it can
> work well in practice. I think nightly is good enough in my case. I
> haven't tried using externals with Hudson yet, so I'm curious: does
> your hourly build always run whether there have been changes or not,
> or are you getting Hudson to check for updates first?
I set it as downstream of each module's job so that if the
svn:externals build correctly, then we trigger a build of the latest
integration uber-build
>
> ---------------------------------------------------------------------
> 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: Now seriously: how can I manage dependencies of own projects with maven
Posted by Zac Thompson <za...@zac.ca>.
On Fri, Oct 15, 2010 at 6:34 AM, Stephen Connolly
<st...@gmail.com> wrote:
> I just set up a big fat aggrigator for each of the "test everything
> together" projects that I want to run CI over. I use svn:externals to
> check everything out and then two maven builders, first to update the
> aggregator and all child modules to link them together and the second
> to run "verify". That way I never pollute the local repo... and these
> types of build run less frequently (hourly), so the slower build is
> less of an issue.
>
Thanks for this bit, Stephen; I've been considering doing exactly this
for a little while, so it's good to know you've already proven it can
work well in practice. I think nightly is good enough in my case. I
haven't tried using externals with Hudson yet, so I'm curious: does
your hourly build always run whether there have been changes or not,
or are you getting Hudson to check for updates first?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
On 15 October 2010 12:57, Leon Rosenberg <ro...@gmail.com> wrote:
> On Fri, Oct 15, 2010 at 10:31 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 15 October 2010 07:28, Leon Rosenberg <ro...@gmail.com> wrote:
>>> Hello,
>>>
>>> following situation:
>>>
>>> I have like 20 projects which are libs of different level. They are
>>> all built as jars. They are partially dependent on each other (not
>>> circularly).
>>> For example project A provides very basic utils. Project B is more
>>> specialized and depends on A. Project C depends on A, project D on A
>>> and C.
>>>
>>> I have two requirements:
>>>
>>> First: I want them to depend on a released version of each other, not
>>> necessary last release, but preferred.
>>> This work if I declare the dependency as RELEASE
>>
>> STOP right there!
>>
>> NEVER EVER USE <version>RELEASE</version>
>>
>> the tag is depricated and relies on correct metadata to work.... and
>> it does not work the way you think it works. The metadata for RELEASE
>> is the last (in time) version that was not a -SNAPSHOT and that was
>> deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then
>> RELEASE will be equivalent to 1.0.2 and not 2.1
>
> Good to know, thanx!
>
>>
>>> or a version number like 1.0.2
>>
>> That is the correct way to work
>>
>>>
>>> Second:
>>> I want to be able to build automatically each night to check whether
>>> the last svn committed changes of the projects break the dependent
>>> projects.
>>> This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT.
>>>
>>> The problem with SNAPSHOT is that If I release 1.0.1 of project B it
>>> upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if
>>> I previously released an 1.0.1 of project A).
>>
>> Sounds like a bug in either your project structure, or the maven
>> release plugin. can you post the poms of A and B and a diagram of
>> their layout in SVN, e.g.
>>
>> /
>> + A
>> + trunk
>> + tags
>> + branches
>> + B
>> + trunk
>> + tags
>> + branches
>>
>>> As a result I am not able to release 1.0.2 of project B until I have
>>> released 1.0.2 of A, even I had no changes in A.
>>>
>>> Therefore the question, how can I teach maven that project depend on
>>> RELEASEd versions of each other for release process and dependency
>>> management on the one side, and on svn snapshots for CI purposes on
>>> the other?
>>
>> another trick is to have your CI build run one of the
>> versions-maven-plugin goals before running the build.
>>
>> but you will actually want two CI builds, one which builds SVN exactly
>> as it is, the other which uses v-m-p to update to the bleeding edge
>> and build things... one of the goals like
>> http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html
>> should help
>
> Ok, from what I understood I should use
> versions:use-latest-snapshots from the vmp to replace all
> 1.0.something to 1.0.somethingelsesnapshot, build with it and tell
> whether its still working.
> If I execute mvn install on each commit I should be able to detect
> errors early.
>
> Is this correct?
>
> Do you know by chance whether hudson will be able to recognize that
> builds as dependency builds and trigger the build of dependent
> projects automatically?
>
> thanx
> regards
> Leon
>
>>
>>>
>>> The only thing I can come up with right now is to have two different
>>> poms for each project, with different dependencies. But this sounds
>>> like a mess to maintain :-(.
>>
>> if you use v-m-p it should not be
>>
>>>
>>> I have done this before with ant+ivy by simple declaring a file based
>>> 'local repository'. This local repository existed only in the context
>>> of a job. I than had a hudson job that checked out all 20 projects and
>>> published them one after each other into the local repository. If some
>>> versions would not compile, the job would fail and send an alert. This
>>> hasn't affected already released versions. Is something similar
>>> possible with maven?
>>>
I use freestyle projects and if you are using v-m-p you will need to
use them too.
I just set up a big fat aggrigator for each of the "test everything
together" projects that I want to run CI over. I use svn:externals to
check everything out and then two maven builders, first to update the
aggregator and all child modules to link them together and the second
to run "verify". That way I never pollute the local repo... and these
types of build run less frequently (hourly), so the slower build is
less of an issue.
-Stephen
>>> regards
>>> Leon
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Now seriously: how can I manage dependencies of own projects with maven
Posted by Leon Rosenberg <ro...@gmail.com>.
On Fri, Oct 15, 2010 at 10:31 AM, Stephen Connolly
<st...@gmail.com> wrote:
> On 15 October 2010 07:28, Leon Rosenberg <ro...@gmail.com> wrote:
>> Hello,
>>
>> following situation:
>>
>> I have like 20 projects which are libs of different level. They are
>> all built as jars. They are partially dependent on each other (not
>> circularly).
>> For example project A provides very basic utils. Project B is more
>> specialized and depends on A. Project C depends on A, project D on A
>> and C.
>>
>> I have two requirements:
>>
>> First: I want them to depend on a released version of each other, not
>> necessary last release, but preferred.
>> This work if I declare the dependency as RELEASE
>
> STOP right there!
>
> NEVER EVER USE <version>RELEASE</version>
>
> the tag is depricated and relies on correct metadata to work.... and
> it does not work the way you think it works. The metadata for RELEASE
> is the last (in time) version that was not a -SNAPSHOT and that was
> deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then
> RELEASE will be equivalent to 1.0.2 and not 2.1
Good to know, thanx!
>
>> or a version number like 1.0.2
>
> That is the correct way to work
>
>>
>> Second:
>> I want to be able to build automatically each night to check whether
>> the last svn committed changes of the projects break the dependent
>> projects.
>> This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT.
>>
>> The problem with SNAPSHOT is that If I release 1.0.1 of project B it
>> upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if
>> I previously released an 1.0.1 of project A).
>
> Sounds like a bug in either your project structure, or the maven
> release plugin. can you post the poms of A and B and a diagram of
> their layout in SVN, e.g.
>
> /
> + A
> + trunk
> + tags
> + branches
> + B
> + trunk
> + tags
> + branches
>
>> As a result I am not able to release 1.0.2 of project B until I have
>> released 1.0.2 of A, even I had no changes in A.
>>
>> Therefore the question, how can I teach maven that project depend on
>> RELEASEd versions of each other for release process and dependency
>> management on the one side, and on svn snapshots for CI purposes on
>> the other?
>
> another trick is to have your CI build run one of the
> versions-maven-plugin goals before running the build.
>
> but you will actually want two CI builds, one which builds SVN exactly
> as it is, the other which uses v-m-p to update to the bleeding edge
> and build things... one of the goals like
> http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html
> should help
Ok, from what I understood I should use
versions:use-latest-snapshots from the vmp to replace all
1.0.something to 1.0.somethingelsesnapshot, build with it and tell
whether its still working.
If I execute mvn install on each commit I should be able to detect
errors early.
Is this correct?
Do you know by chance whether hudson will be able to recognize that
builds as dependency builds and trigger the build of dependent
projects automatically?
thanx
regards
Leon
>
>>
>> The only thing I can come up with right now is to have two different
>> poms for each project, with different dependencies. But this sounds
>> like a mess to maintain :-(.
>
> if you use v-m-p it should not be
>
>>
>> I have done this before with ant+ivy by simple declaring a file based
>> 'local repository'. This local repository existed only in the context
>> of a job. I than had a hudson job that checked out all 20 projects and
>> published them one after each other into the local repository. If some
>> versions would not compile, the job would fail and send an alert. This
>> hasn't affected already released versions. Is something similar
>> possible with maven?
>>
>> regards
>> Leon
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Now seriously: how can I manage dependencies of own projects with maven
Posted by Stephen Connolly <st...@gmail.com>.
On 15 October 2010 07:28, Leon Rosenberg <ro...@gmail.com> wrote:
> Hello,
>
> following situation:
>
> I have like 20 projects which are libs of different level. They are
> all built as jars. They are partially dependent on each other (not
> circularly).
> For example project A provides very basic utils. Project B is more
> specialized and depends on A. Project C depends on A, project D on A
> and C.
>
> I have two requirements:
>
> First: I want them to depend on a released version of each other, not
> necessary last release, but preferred.
> This work if I declare the dependency as RELEASE
STOP right there!
NEVER EVER USE <version>RELEASE</version>
the tag is depricated and relies on correct metadata to work.... and
it does not work the way you think it works. The metadata for RELEASE
is the last (in time) version that was not a -SNAPSHOT and that was
deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then
RELEASE will be equivalent to 1.0.2 and not 2.1
> or a version number like 1.0.2
That is the correct way to work
>
> Second:
> I want to be able to build automatically each night to check whether
> the last svn committed changes of the projects break the dependent
> projects.
> This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT.
>
> The problem with SNAPSHOT is that If I release 1.0.1 of project B it
> upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if
> I previously released an 1.0.1 of project A).
Sounds like a bug in either your project structure, or the maven
release plugin. can you post the poms of A and B and a diagram of
their layout in SVN, e.g.
/
+ A
+ trunk
+ tags
+ branches
+ B
+ trunk
+ tags
+ branches
> As a result I am not able to release 1.0.2 of project B until I have
> released 1.0.2 of A, even I had no changes in A.
>
> Therefore the question, how can I teach maven that project depend on
> RELEASEd versions of each other for release process and dependency
> management on the one side, and on svn snapshots for CI purposes on
> the other?
another trick is to have your CI build run one of the
versions-maven-plugin goals before running the build.
but you will actually want two CI builds, one which builds SVN exactly
as it is, the other which uses v-m-p to update to the bleeding edge
and build things... one of the goals like
http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html
should help
>
> The only thing I can come up with right now is to have two different
> poms for each project, with different dependencies. But this sounds
> like a mess to maintain :-(.
if you use v-m-p it should not be
>
> I have done this before with ant+ivy by simple declaring a file based
> 'local repository'. This local repository existed only in the context
> of a job. I than had a hudson job that checked out all 20 projects and
> published them one after each other into the local repository. If some
> versions would not compile, the job would fail and send an alert. This
> hasn't affected already released versions. Is something similar
> possible with maven?
>
> regards
> Leon
>
> ---------------------------------------------------------------------
> 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