[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Possible problem when multiple developers depend on SNAPSHOT versions
From:       Scott Heaberlin <heabdogg () gmail ! com>
Date:       2009-03-31 20:22:25
Message-ID: 0886AFAC-61AA-4B50-9256-DF99149001B7 () gmail ! com
[Download RAW message or body]

Trevor -

My organization is facing this exact same concern.  We are primarily  
an application platform / hosted-solution company, meaning we don't  
"shrinkwrap" and support multiple versions of our systems - only one  
version is in production at a time.  Of course, multiple branches are  
undergoing testing in parallel, each with different release  
timeframes, etc, and normal branch merging / management occurs at the  
SCM level.  Separate systems, however, have their own release schedules.

SystemA = Dev team A
  -War AWar1, depends on AJar1
  -War AWar2
  -Jar AJar1, depends on SSJar1

SharedStuff
  - Jar SSJar1

SystemB = Dev team B
  - Jar Bjar1, depends on SSJar1
  - Jar Bjar2, depends on AJar1 **note: cross-system dependency
  - War Bwar1
  - Ear Bear1

etc.  Organizationally speaking, we have dev teams responsible for one  
system.  Shared stuff is just that, shared - no particular team as  
owners / maintainers.

Our current solution we're incubating is based around a "floating  
snapshot" concept.  We use the version "current-SNAPSHOT" in all our  
trunk POMs.  So far, we like it.  I reiterate the fact that we don't  
really care about version numbers - once a branch goes to production,  
the previous branch is retired. Period. And we want to keep our  
systems relatively up-to-date in the in-house code they share.

- Our CI server (CruiseControl at present) runs a 30 minute build  
loop. All projects - jars and wars alike - are mavenized (m2).  Souce  
retrieved is tip/trunk at all times, to ensure trunk integrity.
- Our "build server" runs builds on-demand, and retrieves only  
"promoted" source from our SCM.  We think of these as release  
candidate builds, and we create them often.

The ant scripting surrounding our mvn invocations basically mimics the  
release plugin.  The scripts run by our "build server" check out the  
pom, inserts the CC build number, checks in a pom revision in SCM.   
The CI build scripting checks back out and re-inserts "current- 
SNAPSHOT" into the tip revision when triggered.

The result is that whenever CI builds run, they build trunk of  
everything against trunk (current-SNAPSHOT) builds of all  
dependencies, creating an early warning system.  Whenever "build  
server" builds run, the packaging of resultant builds include the  
latest "blessed" (promoted) builds of in-house code.  If large amounts  
of time go between RC builds, then that project's dependencies can get  
"out of date" so to speak.  We're still struggling with that to be  
honest.

I welcome your thoughts.  I think this is a discussion that is central  
to large-scale adoption of maven in the enterprise.  If we need to  
take this off-list I am fine with that as well.

-Scott Heaberlin
Columbia, SC


On Mar 25, 2009, at 3:10 PM, Trevor Harmon wrote:

> Consider this scenario:
>
> Alice and Bob are working independently on two different  
> applications, AppA and AppB. Both applications depend on an in-house  
> shared library, Foo, that Alice and Bob are working on together.  
> They have both checked out Foo's trunk and are regularly committing  
> changes to it.
>
> Because Foo is undergoing heavy development, AppA and AppB depend on  
> Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's  
> AppA needs some of the features scheduled for Foo 2.2, so she  
> decides to perform a release of Foo 2.1 and does the usual release  
> procedure:
>
> 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into  
> the trunk
> 2) Deploys Foo 2.1 to the company's internal repository
> 3) Tags the Foo trunk as the 2.1 release branch
> 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into  
> the trunk
> 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT
>
> But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his  
> AppB. If he updates his working copy of Foo's source code, any  
> changes he makes to Foo will be built as a 2.2-SNAPSHOT release,  
> since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem  
> because his AppB has a dependency on 2.1-SNAPSHOT, so the next time  
> he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring  
> any changes Bob makes in Foo. He will probably waste a lot of time  
> debugging, at least until he happens to notice that Foo's version  
> has changed.
>
> What can be done to prevent Bob's problem?
>
> Trevor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


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

[prev in list] [next in list] [prev in thread] [next in thread]