Using Maven in a large company - case studies requested

[Mike Cripps <mi...@taptu.com>]

Hi all,

My company has recently transitioned from custom ant scripts to a fully
mavenized build and release system, using Nexus and Hudson to store and
create artifacts. In general, the move is working well. However, the
'old guard' in the company have been slow to embrace Maven - worried as
they are about its effects on Continuous Integration and 'dependency
management hell'.

We're a medium sized company with about 35-40 components, the majority
of which are library code ('common' code etc) but with about 10 actually
'deployed' services. What we have done is encourage people to release
their projects when they are about to deploy them. Stable versions being
re-creatable is a good thing.

We've recently hit a snag with this though. Each project has its own
release schedule and maintainer, and some projects are languishing on
old versions of common libraries. Normally this isn't a problem, as it
doesn't affect individual service deployment.

However, we have a task-scheduling service that runs tasks generated by
other deployed projects - and this is reporting conflicts with 'common'
versions as it needs to have everything in its classpath to run said
tasks - if two projects have a different version of common this doesn't
work.

Are we just 'doing it wrong' - should we fix the version of common
libraries in the task-runner pom?

This brings me onto the second 'desire' - continuous integration. Some
members of the team want all of our projects to depend on the latest
-SNAPSHOT version of its (internal) dependencies - so that breaking
changes to trunk are picked up quickly in all projects. However, this
has major negative effects to Hudson as a change in a common code
library can keep the system busy for an hour rebuilding everything.

I'm in the keep-fixed-versions camp on this, but I can see their point.
Again, is this just an issue with the way we're using Maven? We have a
lot of inter-dependencies (which we're working on reducing through
refactoring and introducing API projects).

Obviously for external dependencies, Maven is great - the only issues
we're having is for internal ones.

So, I'd like to ask people with experience in using Maven in larger
corporate environments what they do. Especially:

   How do you handle internal dependencies with a high degree of
connectedness?

   How would you structure service-layer artifacts?
   
   How do you convince others that Maven is working for you, not against
you?

Apologies for length, many thanks for the great product.
Mike Cripps


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

RE: Using Maven in a large company - case studies requested

[Todd Thiessen <th...@nortel.com>]

We are moving to a larger Maven build as well. My project was one of the
first projects to move and now we are moving the larger build over and
we have some of the same concerns you do. We are aiming for a larger
agile continous integration build using snapshots and I believe it will
work.

We are using Bamboo as our continour integration server and I believe it
has the ability to do dependency builds. I am sure Hudson must have
something similar. For example if project A depends on B, then if B
builds, then A will build once B is done.

But if A also depends on C, D and E, but have not changed, then they are
not re-compiled. The larger overall build simply pulls in the latest
already built snapshot jars. Thus the overall build shouldn't take very
long.

We have a lot of mixed feelings as to which path to take as well (fixed
versions vs latest snapshots). I am in the latest snapshots camp myself
to foster a more agile development environment, but I do understand how
it can make some feel a bit uneasy. 

As for your first issue I think now that you have moved to maven it is
pointing out the jar hell that you had even when you were not using
maven. I am not really sure what you meant by "task-scheduling service"
but whether or not maven is involved, jar conflicts need to be resolved.
We went through a phase where maven helped us find many jar conflicts
which we were fortunate didn't cause any issues when using ant since the
higher overall build just pulled in the jars it thought it needed
without having any transitive knowledge of the inner projects. The old
ant build used newer jars that were backwards compatible with the older
jars that many of the inner projects were using. In many cases, jars
were simply not included in the final container (war/rpm) but this
wasn't a problem since non of these jars were needed at runtime. You
will notice that when you move to maven that the size of the final
container will likely be larger than what you had without it. Thats
because maven will ensure that it includes all transivitive jars in the
final container, even if you are not using all of this functionality at
runtime.

---
Todd Thiessen
 

> -----Original Message-----
> From: Mike Cripps [mailto:mike.cripps@taptu.com] 
> Sent: Friday, October 02, 2009 5:15 AM
> To: users@maven.apache.org
> Subject: Using Maven in a large company - case studies requested
> 
> Hi all,
> 
> My company has recently transitioned from custom ant scripts 
> to a fully mavenized build and release system, using Nexus 
> and Hudson to store and create artifacts. In general, the 
> move is working well. However, the 'old guard' in the company 
> have been slow to embrace Maven - worried as they are about 
> its effects on Continuous Integration and 'dependency 
> management hell'.
> 
> We're a medium sized company with about 35-40 components, the 
> majority of which are library code ('common' code etc) but 
> with about 10 actually 'deployed' services. What we have done 
> is encourage people to release their projects when they are 
> about to deploy them. Stable versions being re-creatable is a 
> good thing.
> 
> We've recently hit a snag with this though. Each project has 
> its own release schedule and maintainer, and some projects 
> are languishing on old versions of common libraries. Normally 
> this isn't a problem, as it doesn't affect individual service 
> deployment.
> 
> However, we have a task-scheduling service that runs tasks 
> generated by other deployed projects - and this is reporting 
> conflicts with 'common'
> versions as it needs to have everything in its classpath to 
> run said tasks - if two projects have a different version of 
> common this doesn't work.
> 
> Are we just 'doing it wrong' - should we fix the version of 
> common libraries in the task-runner pom?
> 
> This brings me onto the second 'desire' - continuous 
> integration. Some members of the team want all of our 
> projects to depend on the latest -SNAPSHOT version of its 
> (internal) dependencies - so that breaking changes to trunk 
> are picked up quickly in all projects. However, this has 
> major negative effects to Hudson as a change in a common code 
> library can keep the system busy for an hour rebuilding everything.
> 
> I'm in the keep-fixed-versions camp on this, but I can see 
> their point.
> Again, is this just an issue with the way we're using Maven? 
> We have a lot of inter-dependencies (which we're working on 
> reducing through refactoring and introducing API projects).
> 
> Obviously for external dependencies, Maven is great - the 
> only issues we're having is for internal ones.
> 
> So, I'd like to ask people with experience in using Maven in 
> larger corporate environments what they do. Especially:
> 
>    How do you handle internal dependencies with a high degree 
> of connectedness?
> 
>    How would you structure service-layer artifacts?
>    
>    How do you convince others that Maven is working for you, 
> not against you?
> 
> Apologies for length, many thanks for the great product.
> Mike Cripps
> 
> 
> ---------------------------------------------------------------------
> 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