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
warning.
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.
Ron
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
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: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
