maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Misunderstanding modules: "Two or more projects in the reactor have the same identifier"
Date Tue, 07 Jan 2014 03:00:04 GMT
During active development, we have found that libraries A,B and C should 
be released as SNAPSHOTs with a spec and warranty from the developer.
These may be informal but without this, the developer of X has a hard 
time testing if A,B and C are changing specification/behaviour without 

This implies that there is a series of stubs for methods in A,B and C 
that are not complete.

If it is not possible for the developers of A,B and C to do this, the 
developer of X needs to program to interfaces of A,B and C and find a 
way (DI for instance ) of substituting is own versions (stubs) of A,B 
and C for testing while A,B and C are being developed to a point where 
they are suitable for testing and can be released as SNAPSHOTS with 
specs and warranties.

Otherwise the developer of X will waste a lot of time debugging the 
intermediate versions of A, B and C rather than focusing on X. While 
debugging, the developer of X will never know whether changes to X are 
not working or changes to the behaviour of X are caused by undocumented 
changes to the dependencies.


On 06/01/2014 6:12 PM, erich8 wrote:
> Barrie Treloar wrote
>> When you build Product X the libraries A, B and C should already
>> exist.  You dont want to rebuild them just to build Product X, that
>> will slow down your development process.
>> Ideally A, B, and C are released versions, but if you find a bug in
>> them then you will be using SNAPSHOT versions, which will need to be
>> released separately prior to releasing Product X.
>> If developers are rarely touching the libraries then its better to let
>> your continuous build system (e.g. Jenkins) build the libraries and
>> Maven will automatically pull down the latest SNAPSHOT for you.
>> This way Developer D can fix a bug in A and Developer E will
>> automatically get the bug fix the next time they pull down the
>> SNAPSHOT build of library A, they no longer need to resync and
>> manually build.
>> You can configure how often Maven will check for a snapshot update
>> (see updatePolicy
>> With a continuous build system in place whenever C changes it will
>> automatically schedule a build for A and B, run your unit tests and
>> report success or failure.
>> It should also then build Product X and Y for you (since a downstream
>> dependency changed), again running your unit tests.
>> You will also want a Repository Manager so that it can keep some
>> control over how many SNAPSHOT versions to keep (otherwise you can
>> find yourself running out of disk space)
>> Hope this helps some.
> I understand the need to treat internally-developed dependencies as actual
> dependencies rather than forcing them to be modules, but I'm having some
> problems with the workflow.
> When the project is relatively new and the internally-developed dependency
> "A" is no where near being mature, nearly every change being made to
> "Project X" requires a corresponding change to A. At this point in the
> development cycle (and for many months in the foreseeable future) I actually
> /do/ need to rebuild A every time I build X.
> I can setup our CI system so that A SNAPSHOTS are built and published to
> Nexus after every commit, but what about during development, before I'm
> ready commit my changes? Am I stuck with what my IDE provides? We have
> developers using a wide range of IDEs, or no IDE at all, so I was hoping
> that Maven itself would have some way of kicking off builds of downstream
> dependency A when X is built, if in fact that's what I want to do.
> Right now we're simply telling folks to build A, then build X. And this
> certainly makes sense when you step back and think about it... it's just not
> terribly convenient.
> --
> View this message in context:
> Sent from the Maven - Users mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message