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:[email protected]] > Sent: Friday, October 02, 2009 5:15 AM > To: [email protected] > 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
