geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
Date Fri, 01 Apr 2005 06:12:43 GMT
On Fri, Apr 01, 2005 at 03:10:58PM +1000, sissonj@insession.com wrote:
> 
> I haven't thought this through too much, but have never felt comfortable 
> with SNAPSHOTs.  Could versioned dependencies help us here?
> 

I think they would.  When I introduced a dependency on XFire in the Geronimo build I chose
to use datestamped versions rather than SNAPSHOTs.  Not because I thought there would be no
more changes required in XFire, but because it didn't seem like a win to use a SNAPSHOT and
make other people have to deal with build failures that might arise from the constant mutation
in a SNAPSHOT jar.  There have been plenty of changes in XFire, have you noticed any XFire
related build failures?

Sure it's more work for me to take a slice of the cvs, build it with a datestamp, publish
it to a repo, then update the Geronimo dependencies and check that in.  But I figured since
I was the only one working on XFire, all related build failures are going to come back to
me anyway, so I might as well be proactive about it.

I've only had to do three or for datestamped versions of XFire--not every change in XFire
required an new version from Geronimo's perspective.  I've only done three patches to Axis,
so we could easily get by with datestamped versions of that provided I became a little more
proactive with that too.

Obviously, it's not a rule we can apply to everything.  The tighter the coupling, the more
frequently you would need to produce date-stamped or revision-stamped jars.  Sometimes it's
worth it, other times not.

<aside>
It's strange, but using SNAPSHOTs tends to promote increased coupling and dependency between
code over time, which I think would otherwise be avoided or at least inhibited.  Very good
for innovation, but puts an ironic spin on the term Continuous Integration.
</aside>


-David

Mime
View raw message