On 05/10/2010 4:27 PM, Mike Lenner wrote:
You just need to bump the dep
version in project-2.
What about the use case where developers on project-2 don't even know
that project-1 has been released? All they know is the next time they
check in code to shared-util and check in code to use that in
project-2, their CI build breaks.
People who check in code without looking at the error messages about
conflicts in source version control will get you into all kinds of trouble.
If they checked out version 1.0-SNAPSHOT and are checking into version
1.1 releases without seeing that someone else has written conflicting
interfaces and classes, that is the problem to tackle.
Perhaps shared-util is too big and is more unstable than it should be.
We went through this and have refactored our shared libraries to create
a better set of functionally organized libraries that are more stable.
It also makes it much more obvious that a library will have to change
during a development cycle so that everyone anticipates the changes.
We have a set of aggregator POMs that are used to build composite jars
so that the set of "official" libraries can be referenced without having
to know the version of all of the component libraries.
Ron
Maybe part of the release process of shared-util should be to update
some parent pom's dependencyManagement section to the 1.1-SNAPSHOT?
On Tue, Oct 5, 2010 at 4:10 PM, Anders Hammar<[email protected]> wrote:
I don't see that you're doing anything wrong. You just need to bump the dep
version in project-2. Or, I guess, you could use version ranges but I'm kind
of allergic to them so I'd suggest stay off that path.
/Anders
On Tue, Oct 5, 2010 at 22:05, Mike Lenner<[email protected]> wrote:
Any help would be greatly appreciated - I'm trying to figure out how
to do this the maven way.
I have a shared dependency called shared-util. My team frequently
makes changes to our deployable projects along with changes to the
shared-util. So, in my continuous build, I'd like each of our
projects always building against the latest shared-util.
Seems like a perfect situation for a SNAPSHOT dependency. So,
project-1 and project-2 each depend on 1.0-SNAPSHOT of shared-util.
Continuous Build deploys the current 1.0-SNAPSHOT to our repo after
each code commit, and project-1 and project-2 build fine.
But then we release project-1. We don't want to do so with SNAPSHOT
dependencies, so we release shared-util as well. The maven release
plugin updates shared-util to 1.1-SNAPSHOT after the release (as well
as project-1's dependency).
But now project-2, still dependent on 1.0-SNAPSHOT, is no longer
building against the latest shared-util. Future commits to
shared-util will not be built against in our Continuous Build for
project-2 because project-2 is dependent on a "dead" snapshot.
What am I missing / doing wrong here? Seems like snapshots were made
for this use case.
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
