maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject RE: dependencies in reactorized builds
Date Tue, 01 Feb 2005 23:49:37 GMT
On Tue, 2005-02-01 at 09:59 +0100, Vincent Massol wrote:
> Hi Michal,
> 
> We have a big project at work (some 100+ projects with 60+ developers as of
> now). This is all a single application that goes in the same EAR (we could
> have some smaller EARs but that wouldn't change the pb).
> 
> We need to ensure all those projects share the same version of dependency
> libraries they use (log4j, hibernate, commons-*, etc). ATM we're using
> entity include but that's not a very nice solution.
> 
> I don't see what's the relationship with releasing all at once. We simply
> want to be sure all the projects are using the same external library
> versions.

+1

That's what I've always done and it does ensure a greater level of
integrity in your deployed applications. Only in extremely rare cases
would I, myself, settle for different versions of an artifact within a
deployment. You're just asking for trouble if you do.

> Thanks
> -Vincent
> 
> > -----Original Message-----
> > From: Maczka Michal [mailto:michal.maczka@imtf.ch]
> > Sent: mardi 1 février 2005 09:48
> > To: 'Maven 2 Developers List'
> > Subject: RE: dependencies in reactorized builds
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Brett Porter [mailto:brett@apache.org]
> > > Sent: Monday, January 31, 2005 11:18 PM
> > > To: Maven 2 Developers List
> > > Subject: Re: dependencies in reactorized builds
> > >
> > >
> > > > Isn't the one version across the board scenario already
> > > supported by m1
> > > > and m2?
> > >
> > > Yes, I just think it needs to become a best practice.
> > >
> > 
> > I just wonder what's your experince with this pratice guys as
> > honestly I am bit sceptical about it and I am not sure if this is really
> > that good thing.
> > Note that we are here tying to find a workable solution for large projects
> > not for the small ones
> > as small ones (say up to 7-10 modules, 3-4 developers) can be still
> > maintained by hand.
> > 
> > I tried to use "one version across the board scenario"
> > couple of times and I am still doing it in some of my projects so I can
> > share my experience in this domain.
> > Only reason why I am still doing it in some projects
> > is due to the fact that we are using jira at work and in jira project's
> > components cannot be versioned separately
> > and there is not so many people actively working on those projects.
> > 
> > Simply there is a couple of issues with that approach
> > 
> > a) release process is difficult as the application is released in one big
> > shoot.
> >    If you keep a track of changes per every module, use separate tags in
> > SCM
> > system per module, keep a track of changes per module in your issue
> > tracker
> >    this really slows you down.
> >    This is not something you want to do if you fixed a bug in a single
> > module and you want
> >    quickly ship it to the customer. If there is some sort of involvement
> > of
> > QA team in release process this quickly becomes a bottle neck.
> > 
> > 
> > b) when release is made there is usually so called "code freeze period".
> > If
> > you changed only a single module - you don't want to slow down
> >    other people which are working in parallel on some other modules. This
> > makes the policy "release early, release often"
> >    not so easy to apply (if at all possible) as modules are only released
> > when platform is released.
> >    I know that branching is recommended practice in such cases but with
> > CVS
> > it is not that easy and I think it globally adds you more work
> >    to do then the scenario in which you are releasing modules separately.
> > 
> > 
> > So to conclude - I think this is a good solution for small projects but I
> > doubt if this is something which may ever work for
> > bigger ones: say eclipse or geronimo and this is not really solving the
> > problem which we are trying to solve here :(
> > 
> > 
> > Michal
> 
> 
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha


Mime
View raw message