Message-ID: <822161566.499.1432822667383.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_498_145582557.1432822667382" ------=_Part_498_145582557.1432822667382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Why Enterprise needs unified build platform?=20
Sooner or later every single company that builds their own software come= s to implementing some kind of generalized build & 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 develo= pers rotate or simply resign? What kind of support does such a system gets?==20
This paragraph may evolve into a huge discussion, but in my opinio= n - creating and maintaining commodity software only makes sense if it is t= he primary business of an institution, in all other cases (we are discussin= g commercial enterprises) obtaining commodity software is preferable and sa= ves a lot of money. Especially clear this becomes when the primary business= changes: grows, modifies requirements.=20
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 communit= y project, the return is 10-fold right away. Provided that the direction of= development is agreed upon by all 10=20
I think it' the right time to get together and discuss all that. The upc= oming ApacheCon in Austin, TX Oct 9-13 2006 seems to be reasonably good opp= ortunity to do that.=20
What is different for Maven in the Enterprise= =20
In my understanding Maven for Enterprise has a set of unique characteris= tics. Most of these characteristics are common sense options for almost all= projects, but in the enterprise environment they sease being options and b= ecome requirements.=20
As a build platform, Maven is expected to deliver:=20
A very interesting challenge i= s version maintance: if I have a thousand developers working on 500 project= s - keeping versions in sync is a hustle. Some of it may be addressed by th= e release plugin, but that one is very limited in terms of project structur= e support. I think we are coming to a more fundmental requirement here: dep= endency graph manipulation tool, which supports:
In the enterprise it is very important to know and quickly access the li= cense of any project. Licence may have a version, it may be just another, s= pecially designated dependency that resolves into either a predefined set o= f known licenses or a new URI for the license?=20
A clean separation "internal project" vs. "external depen= dency" might be desirable. We can do it by, say, groupId. Is there a n= eed in more granular project attributes?=20
Enterprise Development cycle
Maybe we should defi= ne a reference "enterprise software development cycle" and brains= torm how well Maven supports various aspects of it? Normally we always stop= ped at unit tests, completly ignoring QA/regression testing, saying: OK - i= t may happen behind the seen and then - by miracle - project is released; v= ersion 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 gener= alize:=20
I fully realize that this is an over simplified description, but we need= to start with something and grow the meat.