News: Maven Calm, an Maven based open source approach to ALM

  1. Maven Calm is a fresh new attempt to implement Application Lifecycle Management (ALM), using founding Apache Maven principles like archetypes and inheritance. ALM is about orchestrating engineering and business processes processes, so archetypes finally become properly stated blocks/operations in process flow diagrams while inheritance is the tool used to centralize, so standardize the processes themselves. More practically, Calm is an open source (so collaborative) cross-corporate superPOM which you can inherit from, and to which you can contribute your ALM best practices. Currently allows you to implement, by the means of simple POM or profiles.xml properties, the most common application lifecycle use cases like: - Packaging and running of your application (JAR/WAR) - Releasing and SCM configuration - Selenium Tests - Distribute a production ready bundle based on Apache Tomcat In addition to it's quickstart(see Calm tutorial here) nature, Calm provides a layer of stabilty (sort of wrapper) around your Maven builds, by a smart usage of plugin and dependency management. Your build will stay reproducible until YOU decide to move to the next Calm version, which has already been released and tested by the community. Calm is originally designed to stand on top of your corporate pom, but practically, it removes most of the burden related to typical Maven project startup (for non Maven trained resources) so we're seeing advantages in using it for project of virtually any size and for both enterprises (final clients) and system integrators. Despite of some modularization issues (it's only 1 POM for now, and will grow messy if the community start contribution), this seems a very good approach to standardize the way we work around J2EE applications and definitely is making my consultant life easier :) Eager to hear your opinions on this approach and to contribute to the project if you appreciate the effort! But above all, whatever you do, do it Calm ;) More references below: -------------------- - Maven Calm Project - Maven Calm Mailing list - Maven Calm Announcement - Maven Calm Tutorial Who's using Calm: ----------------- - Maven Alfresco 3.x Archetypes - Maven Hippo 7.x Archetypes - Dutch Semiconductors Enterprise using Calm - Dutch integrator using Calm - More to come...

    Threaded Messages (5)

  2. yes but..[ Go to top ]

    Even if the idea is tempting, I find it hard to believe that the approach "1 Pom to rule them all" will really work. Looking at the calm pom, there are several plugins that really are not of use of a plethora of Maven enterprise projects. For sure, many users will find pretty useless many of them (selenium, to mention one). I believe that after a first bootstrap with maven, where calm might really help, users will start heavily customizing their POMs, inheriting by their home-made parent pom, with only what they need. I'd be curious to know what's your experience so far.
  3. aiming at modularity[ Go to top ]

    Hi Valerio, the idea of Calm is not exactly "1 Pom to rule them all", but it's more abstract; it would be more like "extended conventions on top of Maven" or simply "Maven best practices"; one of these is IMO to keep you Pom files clean and readable; maven-calm is not meant to be a huge Pom, but more an aggregation of different behaviors. It would be nice - for example - to inherit profiles from dependencies, using - for example - a import-profiles as convention rule: com.sourcesense.maven maven-calm-selenium 1.0-beta-9 import-profiles This is still a *big* challenge for Calm; I'd like to see if Maven 3 will introduce similar facilities. What do you think? Would you use this feature and start modularizing your behaviors in different dependencies or you'd prefer to use the default approach? Thanks, Maurizio
  4. Hello Maurizio, you're assuming that it's a wide-adopted practice to make 'reusable profiles', from which users can easily inherit. Frankly, it's a strong bet to make. Every time I make a profile, it's very well customized for the specific case at hand. It might be bound to a specific phase, using a very specific plugin version which might work for me but not for you, etc. The exceptional/corner cases are so many that I doubt that such a profile-inheritance feature is widely useful. Especially if you're targeting a broad audience of applications, and not a very restricted set which is known to be compatible with your profile. The typical example I exploit in my applications is to provide a 'run' profile in your parent pom, set the main class as a property, and ask sub-modules to re-define that variable in their pom. This is perfectly fine, but arguably justify (for me) to import a parent pom. What I'm saying here is that it's hard to promote a pom to provide some "extended conventions" across all kind of projects/modules. What I would have prefered to see in calm is, perhaps, a "set" of CALMed poms, each one of them useful for a given class of applications (j2ee, j2se, j2me, spring-based, you-name-it). Also you could provide guidelines to users to publish themselves their CALMed POM. In this sense, you could promote a given methodology to use on top of Maven, but not your implementation of this methodology. Of course, I might have missed your point once again... best regards valerio
  5. Ciao Valerio, I think that there's quite a bit of similarity between the concept Calm is trying to push and the sort of methodology you talk about. The difference is only in granularity, or if you prefer in scalability, meaning: - it's clear that at the moment Calm is one single POM, so the coarser granularity inheritable component that can expose is the Profile. Meaning: you can create and contribute your CALMed profile, following a standard convention and providing some properties for sub-poms to override. More docs to come here. - by providing a solution to the import-profiles (or better import-pom) issue we could extend the notion of inheritable component to the POM itself (which is no more than an aggregation of a main and possible several additional profiles). This way, any "client" POM could use whatever POM which is available in Calm as well as Calm could produce pre-configured archetypes importing different combinations of POMs (e.g. vertical on the technology) So, repeating myself, I think that in the "think big, start small" agile idea, the best way to proceed is to evaluate the community reaction and see if we need to scale out prioritizing the resolution of the mentioned issue. BTW, would you act on Maven 2.x (which is outstandingly putting out a new minor release per month or so) or try to squeeze such a functionality directly on Maven 3? Thanks for the comments! Ciao, Gab As far as I can see it
  6. Maven best practices[ Go to top ]

    Maven started with the idea of bringing best practices in the world of software builds, and succeeded in it. As it happens in every project that gains attention, complexity tends to increase quite quickly. Maven already uses internally a super-pom to declare a number of default settings, what i find limiting is that it declares only one super-pom. The idea behind CALM is that of giving another, premade, pretested, well documented, pom to use as a super for your own applications. I'd love to see it scale to include a number of them, precustomized for various "macro classes" of applications. As always, what costs you more is competence and bugfixing, and Maven is no exception to this. When you go beyond what the default super-pom already includes, you need to be able to configure properly the plethora of Maven plugins, and then fix up all the corner situations. CALM aims to be a pre-made saving you this hassle, and from this point of view it is a great idea. Maven was not designed to offer modularity at the pom level, but there are a number of ways this could be achieved in Maven 2, and probably refactorings in Maven 3 will make it even simpler, opening a new way for POM handling.