unclear what calm is for..

[leif hanack]

Hi there.

I see your announcement on TSS. After a quick look I'm not sure if I missed s.th. For me it is not clear what CALM is more than using the mentioned plugins like cargo, release, ..

Maybe you can specify this difference in more detail.

Thanks, Strug

[Gabriele Columbro]

Hi Strug,
sorry for not reacting before, having some hectic days :)

Find my answers interleaved:

On Jul 1, 2009, at 7:27 PM, leif hanack wrote:

> Hi there.
>
> I see your announcement on TSS. After a quick look I'm not sure if I
> missed s.th. For me it is not clear what CALM is more than using the
> mentioned plugins like cargo, release, ..

If you target the following main usage contexts for Calm:

_1 *Medium / Large enterprise* which is using / moving to Maven and
wants to standardize its ALM processes in a cross-technology and cross-
project fashion (see example here [1] )
_2 System integrator who is working in a naturally cross-customer and
most of times cross-technology context, and typically has to produce
solutions where the most important feature is the time to market
(Proof of concepts, demos, ...). See [3] for an example.
_3 Open source projects starting with Maven, without Maven expert
resources but willing to use Maven as enabler for interoperability and
integration with the open source codebase

then there are a few rationales or use cases that motivate the use of
Calm instead of starting a project on Maven from scratch:

__A Preconfiguration of plugins into standard profiles
You are baseline, as a Calm user, to POM and profiles.xml properties
to override instead of going around the web searching in the sometimes
minimal Maven documentation to configure your own plugins. You can
*always* go deeper in the lifecycle customization by just overriding
the Calm defined profile in your specific POM, but the possibility of
configuring simple properties (a non Maven specific concept) and
running pre-made profiles is something that scales quite easier in a
Maven entry-level enterprise/integrator/community
__B Plugin management and fixing of versions
One of the main concerns around Maven is that your build becomes not
reproducible because the org.apache.maven.plugins (or any other
defined in <pluginGroups>) plugins are updated by default to the most
recent version. By using Calm you get an already community tested
combination of plugins and plugins versions, which removes most of the
initial (possible) burden when a non Maven experts sets up a new
project. Fixing plugins versions and defining standard lifecycle use
case oriented profiles provides a layer of abstraction and stability
around Maven which I found really appreciated by even business users
(the other party having stakes in the ALM processes)
__C It's practical and allow you to start in matter of minutes
All ALM attempts I could find around are mainly theoretical and lack
of any practical implementation. Despite of the scalability issues
which we'll need to tackle [2] (if the community starts working on
Calm), Calm provides a first attempt to share the achievements of
people's Maven best practices, in a collaborative fashion.
Meaning: personally, every time I start a project in Maven, I find out
that archetypes are perfect re-use per technology achievements while I
*always* have to copy-paste (BAAAD!) the latest tips'n'tricks for my
latest Maven build. With Calm I have another weapon, working aside the
archetypes, to snapshot and re-use (via inheritance) my achievements,
without even having to maintain them myself (still assuming a
community arises around Calm).


I think we're all aware that Calm is an initial attempt to build a
community based set of best practices in the usage of Maven, oriented
to provide more high level easy access to the infinite possibilities
of this build framework (as opposed to 'build tool'), but needs to be
more scalable and provide standard guidelines to be actually
completely effective.
But we sort of think that checking with the community first is a good
way to start building a collaborative approach:
and the fact that we had literally thousands of visits on the
different Calm related websites kinda proves that we are targeting an
important missing ring of the enterprise J2EE development chain ;)

I tend to consider Calm as a forge where people can contribute their
best practices (e.g. maven-changes integration with Jira rather than a
nice Maven Site configuration for test reporting with Sonar, or a
custom CI server integration rather than custom packaging types, etc.)
instead of keeping them in their POMs, in order to create the
usual community phenomenon for which you get from the community
typically much more than you contributed (maintenance, new features,
suggestions, etc.)


I hope this can help the reasons why we created Calm. I'm really eager
to start a discussion on if/how we can improve the effectivity and
usability of Calm.

Ciao!
Gab




[1] http://www.slideshare.net/guest67a9ba/maven-application-lifecycle-management-for-alfresco
[2] http://code.google.com/p/maven-calm/issues/detail?id=1
[3] http://www.slideshare.net/m.pillitu/maven-calm

>
> Maybe you can specify this difference in more detail.
>
> Thanks, Strug
>
>
> >

--

Eng. Gabriele Columbro
Alfresco Software, Ltd.

M: +31 (0)627 565 103
P: +39 320 161 28 46
D: +44 (0)1628 876 654
Skype: gabrielecolumbro
Blog: http://www.mindthegab.com