maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From erich8 <Eric.Herrm...@intermedix.com>
Subject Re: Misunderstanding modules: "Two or more projects in the reactor have the same identifier"
Date Mon, 06 Jan 2014 23:12:27 GMT
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
> http://maven.apache.org/ref/3.0.3/maven-settings/settings.html#class_snapshots)
> 
> 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: http://maven.40175.n5.nabble.com/Misunderstanding-modules-Two-or-more-projects-in-the-reactor-have-the-same-identifier-tp4614001p5780688.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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


Mime
View raw message