Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

Why Enterprise needs unified build platform?

Sooner or later every single company that builds their own software comes to implementing some kind of generalized build &amp; deploy system. While meeting the need, such a system does not add any competitive advantage to the core business. It is like if each company will start creating their own programming languages: it could be made highly optimized for a particular busines, but maintaining one sucks in more money that it generates. And don't forget the people around it: how much expertize is preserved when developers rotate or simply resign? What kind of support does such a system gets?

This paragraph may evolve into a huge discussion, but in my opinion - creating and maintaining commodity software only makes sense if it is the primary business of an institution, in all other cases (we are discussing commercial enterprises) obtaining commodity software is preferable and saves a lot of money. Especially clear this becomes when the primary business changes: grows, modifies requirements.

This may sound trivial, but a community can achieve more that any single entity. And if 10 entities manage to invest 1 unit of work into a community project, the return is 10-fold right away. Provided that the direction of development is agreed upon by all 10 <img class="emoticon emoticon-smile" data-emoticon-name="smile" border="0" src="/s/en_GB/3278/15/_/images/icons/emoticons/smile.png" alt="(smile)" title="(smile)" />

I think it' the right time to get together and discuss all that. The upcoming ApacheCon in Austin, TX Oct 9-13 2006 seems to be reasonably good opportunity to do that.

What is different for Maven in the Enterprise

In my understanding Maven for Enterprise has a set of unique characteristics. Most of these characteristics are common sense options for almost all projects, but in the enterprise environment they sease being options and become requirements.

As a build platform, Maven is expected to deliver:
<ul>
	<li>Speed</li>
	<li>Reliability</li>
	<li>Scalability</li>
	<li>Documentation</li>
	<li>Training</li>
	<li>Support</li>
	<li>Stable Community - this comes from being successful OSS project</li>
</ul>

Versioning support 
A very interesting challenge is version maintance: if I have a thousand developers working on 500 projects - keeping versions in sync is a hustle. Some of it may be addressed by the release plugin, but that one is very limited in terms of project structure support. I think we are coming to a more fundmental requirement here: dependency graph manipulation tool, which supports:
<ul>
	<li>snapshot creation operation: a project is being modified, it needs to be marked as a snapshot</li>
	<li>snapshot promotion operation: project is approved into production - all dependents (not dependencies) should be modified as well</li>
	<li>operations are SCM aware: we should be able to control whether operation should affect all (some?) active branches and non checked out dependents</li>
</ul>

Licensing support

In the enterprise it is very important to know and quickly access the license of any project. Licence may have a version, it may be just another, specially designated dependency that resolves into either a predefined set of known licenses or a new URI for the license?

A clean separation &quot;internal project&quot; vs. &quot;external dependency&quot; might be desirable. We can do it by, say, groupId. Is there a need in more granular project attributes?

Enterprise Development cycle 
Maybe we should define a reference &quot;enterprise software development cycle&quot; and brainstorm how well Maven supports various aspects of it? Normally we always stopped at unit tests, completly ignoring QA/regression testing, saying: OK - it may happen behind the seen and then - by miracle - project is released; version may or may not change. Well - this is not going to fly if you try to sell it to a big company's software development management; first question will be: how does it support my real cycle?

Here is an attempt to define coarse cycle phases we can refine and generalize:
<ul>
	<li>initiation: a new project is either created in or checked out of SCM</li>
	<li>development - iterative process that includes unit and maybe integration testing
	<ul>
		<li>development includes remote builds when intermediate code is checked into SCM, built by a &quot;build server&quot; - Continuum and results shipped back to the developer</li>
		<li>intermediate product maybe be deployed into QA environment and tested by developer(s) as part of development</li>
	</ul>
	</li>
	<li>QA deployment &amp; acceptance
	<ul>
		<li>may result in firing a separate test battery: code coverage, PMD - etc.</li>
	</ul>
	</li>
	<li>QA - iterative process resulting in the next bullet.</li>
	<li>Promotion - project is switched from snapshot to a version</li>
	<li>Production deployment (release?)</li>
	<li>Cycle repeats</li>
</ul>

I fully realize that this is an over simplified description, but we need to start with something and grow the meat.