Comment and community contributions are more than welcome!
See you soon in the Calm-o-sphere 😉
It’s still at its early stages but it’s definitely collecting already lots of interest and potential use cases.
Maven Calm is an Apache Maven based attempt to provide a simple and collaborative implementation to the problems of ALM (Application Lifecycle Management), which is based on a simple rationale developed in 3+ years of complex architectures development on Maven:
“All best practices can be externalized, in a cross technology and cross organization fashion, using Maven project inheritance capabilities”
As Mau explains in his wonderful Maven Calm tutorial, simply by the means of using Calm as parent POM and setting some properties, you have access to a number of pre-configured behaviors of your build, neatly bound to lifecycle phases.
Hopefully this list is meant to grow pretty soon, but at the moment Maven Calm support ALM processes like:
Some random note, mostly to myself, to remember, in some dark Maven time, how cool this technology is and that sometimes, at a certain point sure, you CAN have success stories with it.
For now, as I anticipated I’m just playing around with Alfresco core modules, to see how they fit with Maven and how tough can it be to port the full suite.
And you know what guys, on Friday, in just 4 hours I was able to have the core AND webscript framework completely building and tested with Maven (98% success rate).
I mean, it’s just a beginning, but considering that Webscripts are meant/designed to be deployed and integrated also outside of Alfresco, well, you understand the power of having only to add few dependency lines.
I’ll just drop the raw log of my operations, to give you a raw idea what can take for the m10n of an Ant project and how easy it can be if the source project is well maintained and tested.
Alfresco core mavenization (m10n):
mvn install:install-file -Dfile=jta.jar -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1b -Dpackaging=jar
mvn install:install-file -Dfile=jug-lgpl-2.0.0.jar -DgroupId=jug -DartifactId=jug-lgpl -Dversion=2.0.0 -Dpackaging=jar
mvn install:install-file -Dfile=ibatis-220.127.116.116-patched -DgroupId=com.ibatis -DartifactId=ibatis -Dversion=18.104.22.1686-patched -Dpackaging=jar
// FIXME: Refactor this to take resource from classpath
this.resourcesDir = System.getProperty("user.dir") + File.separator + "target" +
File.separator + "test-classes" + File.separator;
Tests run: 54, Failures: 1, Errors: 0, Skipped: 0
[INFO] For more information, run Maven with the -e switch
[INFO] Total time: 1 minute 2 6 seconds
[INFO] Finished at: Fri May 22 20:32:39 CEST 2009
[INFO] Final Memory: 8M/22M
Well pretty cool if you consider only a couple of hours of work, 54 tests out of 55 working again 😉
That’s refactoring yeah!
Webscript Framework mavenization (m10n):
Pretty much the same steps, some dependency to deploy but basically the same trick.
Nice to note, under modules coupling POV, that the only intra-Alfresco dependency of the Webscript Framework is the Core, so that in another couple of hours I was able to run a
mvn clean install
on the Webscript frameowork project, with the following result:
Tests run: 16, Failures: 2, Errors: 0, Skipped: 0
[ERROR] There are test failures.
Please refer to /Users/mindthegab/Dev/alfresco/workspace/WebScript Framework/target/surefire-reports for the individual test results.
[INFO] Building jar: /Users/mindthegab/Dev/alfresco/workspace/WebScript Framework/target/alfresco-webscript-framework-3.2.0-SNAPSHOT.jar
[INFO] Installing /Users/mindthegab/Dev/alfresco/workspace/WebScript Framework/target/alfresco-webscript-framework-3.2.0-SNAPSHOT.jar to /Users/mindthegab/.m2/repository/org/alfresco/alfresco-webscript-framework/3.2.0-SNAPSHOT/alfresco-webscript-framework-3.2.0-SNAPSHOT.jar
[INFO] BUILD SUCCESSFUL
[INFO] Total time: 14 seconds
Ok needs refinement, and a proof of concept of integration in some webapp, but I feel already like all the “glue” power of Maven can be an additional enabler to such a feature-ful platform like Alfresco.
Suggest to stay tunes as I’ll definitely post more on this 🙂
How come writing is always the last thing?
Before it was blogging, now fashion says we must micro-blog, and we even don’t have time to spend a few words on what we do. Effective as business, but blogging gave us a bit of writers pride, isn’t it? But it goes much earlier than that…the vast majority of software projects is developed almost until the end without any piece of seriously meaningful documentation.
Ok, ok, stop!
I was just finding lame philosophical excuses for not having blogged anything in this period of my life, such dense of changes in many aspects of my life and career. And this blog post keep staying in the infinite backlog of my TODOs.
seems to run a famous Chinese or supposed to be Chinese curse, which I actually heard for the first at the Alfresco Rome’s meetup during my new CTO – John Newton – presentation, but that reflects the current status of my life, career and more in general world there days. Read more The infinite tail of TODO
Yes, it’s just yet another success story.
But still worth mentioning isn’t it? Especially when it happens right to you and right in one of the toughest period of my entire career.
So to keep it short: I’m working together with Marijn on some fully fledged complex Alfresco workflow, working on 3.0 but still on the “old” Alfresco web client (now renamed to Repository Explorer ).
One big requirement that has been left out was the possibility of displaying the task history of a workflow on the document details page. To be clear, Alfresco allows showing documents associated to a workflow, but the reverse association is not displayed and a document has no means of showing the task history that a specific document has undergone to.
About to drop this requirement, while googling around I came across this genius post, in which Marc de Kwant describes and shares the code of exactly this feature. Ok, I understand it’s a quite obvious requirement, especially in enterprise controlled documents contexts, but I mean, look at the picture, it’s exactly what I needed 😉
That is extremely cool, and will allow to implement the feature in a matter of minutes.
Makes me wanna contribute to the project, just to give all my kudos to his great work (still have to try it actually, but appreciate the effort 😉 ).
The code is hosted here and if I look better at some comments on the blog post , seems that the gap of poor packaging of this feature (just a bunch of files dropped there) can be easily bridged with another success story, a one shot execution of my Maven AMP archetype. Guess it can make a really nice Forge contribution as such. Anyone interested to try it out?
I especially love when open source achievements come together in a product, which is typically more than double valued than the original addendums. That’s why I probably will always like, enjoy, be interested in being an open source integration pioneer.
When building a multimodule project in Maven, you often use POM inheritance to centralize plugin configuration and even executions. While centralized configuration is most of time fairly straightforward, the centralization of a plugin definition may force (or try to force) all or your submodules to follow the same *customized* build lifecycle which may even not apply to their packaging.
Think for example of having a cargo-maven-plugin configuration centralized for a project of 3 WAR projects and a JAR: I don’t think your appserver will be happy of receiving a your JAR as a deployable because you too smartly centralized a configuration which deploys after the packaging phase (I wouldn’t be happy either… 😉 )
I solved this problem using profiles and working on the fact that a profile is inherited only when it’s defined also in the child pom, so not definying your plugin/plugins configuration in the main build.
I have a project structure composed of multiple (WAR and JAR) artifacts with cross dependencies and a super pom, something like:
So basically I have a (for jboss using cargo) a super pom which defines all cargo plugin configuration in a profile called ‘deploy’ , which goes something like this:
<!-- Profile to deploy to a local jboss instance, due to http://jira.codehaus.org/browse/CARGO-416 -->
Properties for this profile are configured in the superpom <properties> section, which goes something like:
<!-- src/main/properties/<env>/application.properties is loaded for all subproject -->
Then, for every project which I’d like to deploy I configure in the specific child pom an profile with same id (“deploy” in our case) as this one which actually binds the specified plugin configuration to an actual lifecycle phase (typically in the pre-integration-test):
So basically running my build from the super pom by explicitly activating the plugin (because according to  inherited profiles only gets run if explicitly called by id with -P option and not with the other activation methods described here  ):
mvn clean install -P deploy
I get only the selected sub projects to be deployed with cargo while other projects (that do not inherit the profile) will only run the default build lifecycle (so with neither cargo configuaration nor binding it to a phase).
As a side note, I also use “environmental” profiles (using the <env> variable) so that different cargo (buildtime) properties and and application (runtime) properties are selected, e.g. :
which allows me to have my selected subprojects deployed to different environment by combining profiles:
mvn clean install -Pdeploy,accpt
I believe deploying and one of the things which maven does best, and hopefully this post can let you have a better understanding of which degree of configurability you can get with can get with this tool!
Maybe it’s more social 2.0, maybe it’s more open source but on the other hand we the “big brother” threat is still there.
Anyways, for the record I moved the m2alfresco Alfresco Forge project to a better and safer place on Google Code, under the new fancy name of maven-alfresco-archetypes.
Let’s assist and take part to the community miracle 😉
I’ll see you there…