ActiveMQ is a good example of how this can break down too... he are
already using 2 different versions in the build... 3.2.4-SNAPSHOT and
4.0.1.
But hopefully, once we get our dependencies cleaned up in m2, and
hopefully get the g deps to be based on the m2 deps, than this will
be much easier to manage.
Anyways, I'd be happy to have less snaps... I can't stand how it
slows down trivial build tasks... yes I know I can use -o, but I hate
it even more when I do that and it gets 90% though and freaks about
missing some dependency :-\
--jason
On Aug 10, 2006, at 2:08 PM, Dain Sundstrom wrote:
On Aug 10, 2006, at 1:31 PM, Jason Dillon wrote:
On Aug 10, 2006, at 9:14 AM, Dain Sundstrom wrote:
I wanted to get a general sense before discussing the details,
since there would be no point if were against independent
versioning. I was thinking we should put each them in a tree
which is a peer to Geronimo trunk. I also think we should
generally only use released versions of the jars in Geronimo
(i.e., no snapshots) for two reasons 1) it is much easier to
maintain from a build perspective and 2) is will push us to do
more frequent releases of them.
I don't think that #1 is really a valid reason... IMO that is.
The more trees you have to build and the more version numbers you
have to manage is inherently more complex and thus harder to
maintain from a build perspective. The only way it might scale is
if we can:
a) automate the entire process of multi-tree building and
configuration version updates
b) reduce the frequency of change in the decoupled components,
thus reducing the need to build or reversion
(a) is a bit of work to put some more magic (and complexity) into
Maven2... (b) seems to be negated by your #2 to push out more
frequent releases... :-\
I really disagree with you on this. I think we should be treating
these modules (and more modules) like we do ActiveMQ. AMQ moves at
it's own rate, and every so often we integrate it. For another
example, is also how we treat commons logging. The problems only
occur when you are highly coupled to version specific details of a
library, and this is why I think we should avoid SNAPSHOTS as it
pushes you to develop more decoupled code.
-dain
