Why would that break the CI build? It should break in your own environment as 
soon as you try and use it in project-2. Well before the CI build. This will 
tell you that project-2 needs to point to the 1.1-SNAPSHOT version of 
shared-util.

What you are doing sounds fine to me. Project-2 need not even know about the 
released version of shared-util. If project-2 never requires any additionaly 
functionality from shared-util, it can go happily along its merry way and not 
even worry about upgrading to the latest version of shared-util. Once project-2 
releases, you'd then notice that shared-util has already been released and need 
only point to the released version of shared-util.

The thing you have to be careful of is making non-backwards compatible changes. 
When you have a shared library like this, be extra careful that once you 
release something that you don't get rid of any functionality it provides. Or 
change the name of any public classes/methods. Especially if there are others 
using that jar that you may not be aware of.

An adage of Josua-Bloc comes to mind when designing a shared API like this: 
when in doubt, leave it out. Make as many of your classes package private that 
you can.

Anyway, I am starting to ramble ;-).

> -----Original Message-----
> From: Mike Lenner [mailto:mike.len...@gmail.com]
> Sent: Tuesday, October 05, 2010 4:28 PM
> To: Maven Users List
> Subject: Re: Continuous Build always building against the latest SNAPSHOT
> version
> 
> > 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.
> 
> 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 <and...@hammar.net> 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 <mike.len...@gmail.com>
> 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: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Reply via email to