maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Cripps <mike.cri...@taptu.com>
Subject Using Maven in a large company - case studies requested
Date Fri, 02 Oct 2009 09:14:37 GMT
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


Mime
View raw message