Dreams come true … launching the Alfresco Community Maven Repository :)

Busy days busy days, busy but definitely happy days 😉

after working a lot on the CMIS 1.0 Webinar (recording out soon) and having made my first official commit for Apache, I saw an unexpected but never so welcome outstanding speedup of one of the processes that I’ve been pushing in the Alfresco Community for about 3 years now.

I’m proudly announcing the institution of an Alfresco hosted Maven Repository, capable of consolidating and bring the Maven Alfresco Community to the next level. Hosting a repository (for Community artifacts only for now) means a great step towards a even more mature open source community which works against high standards of quality and automation.

I’ll be discussing and demoing this and other Maven Alfresco related topics in next Friday’s Alfresco Tech Talk Live. You’ll find more info on the Alfresco wiki.

For now, here’s a screenshot of our new shiny Sonatype Nexus 1.4.0 instance, which will allow a proper consolidation still scale-out for our community by the means of repositories proxying and Alfresco Community artifacts hosting. Kudos to everyone that made this happen 🙂

Alfresco Maven Repository

This is is a big step for the community which is growing around projects like the Maven Alfresco Lifecycle  and the small CMIS 1.0 Maven toolkit which I built for my recent training engagements.

In addition to that,  the mighty great news about the Alfresco SURF and Alfresco Webscripts project now being contributed to the Spring Framework under the newly born Spring Surf Extension (follow our work here), all of which is powered by Maven gives even a more central role to this technology in the company I work for.  Great job guys and thanks for giving me the opportunity to participate in this!

This is such a nice moment for me which I pushed for this since a long time, when I was still working for Sourcesense. And a special thanks must go to them for having first allowed me to work on a Maven Alfresco suite in the past and for having supported it with their Nexus instance, until we introduced an Alfresco Maven repo. Most content is now migrated so you can safely use the new repo in your POMs.

I’m still in the process of migrating (tomorrow should be done) all the apps to the new repo, so expect changes in the docs. I’ll keep you posted with the coming changes and news.

Also, please provide your feedback on this event so we can offer the best service around this important open source Application Lifecycle Management technology.

Geek and Vain

It’s probably my first real recognition in open source matters. More soon will come, as I’m really putting my heart in the cause.
It was a nice surprise in fact to get to see my big face on Alfresco’s wiki home page, having been nominated January’s contributor of the month for the work on Alfresco and the Maven Archetypes.

Even if, I guess, the photo I sent the Alfresco guys reflects my vain nature 😉

Good stuff, especially as I’m trying to release the 3.0 version of the archetypes in a matter of days.  Stay posted on 3.0.0 branch and on Sourcesense‘s repo. And why not contribute? 🙂

God bless Open Source

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 ).
Apart from Alfresco a bit odd JBPM Javascript implementation, we could get quite close to the fully working solution, but now that users are a bit struggling with the usability of the web client (and some lack of training) we are a bit delayed and trying to prioritize some issues.

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 😉Alfresco Task History Panel

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.

[HowTo] Give your multimodule Maven build subproject/environment specific behavior

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:

project_root
|-- project_war1
|-- project_war2
|-- project_jar1

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>
<!-- Profile to deploy to a local jboss instance, due to http://jira.codehaus.org/browse/CARGO-416 -->
<id>deploy</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<container>
<containerId>jboss4x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.hostname>${cargo.hostname}</cargo.hostname>
<cargo.servlet.port>${cargo.servlet.port}</cargo.servlet.port>
<cargo.remote.password>${cargo.remote.password}</cargo.remote.password>
<cargo.remote.username>${cargo.remote.username}</cargo.remote.username>
</properties>
</configuration>
</configuration>
</plugin>
</plugins>
</build>
</profile>

Properties for this profile are configured in the superpom <properties> section, which goes something like:
<properties>
<!-- src/main/properties/<env>/application.properties is loaded for all subproject -->
<env>local</env>
<cargo.hostname>localhost</cargo.hostname>
<cargo.remote.password/>
<cargo.remote.username/>
<cargo.servlet.port>8080</cargo.servlet.port>
</properties>

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):


<profile>
<id>deploy</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<executions>
<execution>
<id>deploy</id>

<goals>
<goal>deployer-redeploy</goal>
</goals>
<phase>pre-integration-test</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>

So basically running my build from the super pom by explicitly activating the plugin (because according to [1] inherited profiles only gets run  if explicitly called by id with -P option and not with the other activation methods described here [2] ):

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. :


<profile>
<id>accpt</id>
<properties>
<cargo.hostname>accpt.yourcompany.com</cargo.hostname>
<cargo.remote.password>accptJbossPassword</cargo.remote.password>
<cargo.remote.username>accptJbossUsername</cargo.remote.username>
<cargo.servlet.port>80</cargo.servlet.port>
<env>test</env>
</properties>
</profile>

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!

Enjoy!

Maven for Alfresco on Google Code

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.

We’ve a Subversion repository, a Sourcesense hosted Maven2 repository, a mailing list (maven-alfresco nospam at nospam googlegroups.com) and a partner maintaned page on the Alfresco wiki.

Let’s assist and take part to the community miracle 😉

I’ll see you there…

Not Just yet another Maven success story

After struggling a bit too much with the maven-release-plugin under Apache Maven 2.0.9 and hierachical projects, I was finally able to release full support for Maven based Alfresco ECM lifecycle.

As I was mentioning in previous post, despite being one of the best piece of software I’ve worked on, Alfresco still lacks a lot in Enterprise ready delivery of its customizations, providing solutions based on Ant and custom tools like the Alfresco Module Management Tool which does not really fit in environments where control over versions, complex interdependent grids of applications are deployed on top of Alfresco, or simply when you not willing to perfom the (typically open source related) web googling-crawling to make that damn thing work.

In this sense I developed, based on successful internal Sourcesense and end customers implementations, a full support for Maven based Alfresco customizations. It’s documented in the Alfresco wiki, but basically comprise:

  • A maven-alfresco-extension-archetype which allows creation of a custom build of Alfresco community/enterprise,  basically producing a WAR as main build artifact, storing all customization in the alfresco/extension folder (Convention Over Configuration). All dependent AMPs (yes, we support AMP dependencies 😉 ) are included in the WAR. Typical usage scenario is the main Enterprise Alfresco build which includes base configuration settings (e.g. db, alf_data, custom model) then can include many satellite modules (AMPs produced by the maven-alfresco-amp-archetype)
  • A maven-alfresco-amp-archetype which allows creation of an Alfresco compatible custom AMP (Alfresco Module Package) .  basically producing a .amp  as main build artifact. The produced AMP is configured in the alfresco/modules/{pom.groupId}.{pom.artifactId} without requiring manual developer synchronization between module name and POM properties.
  • A maven-amp-plugin providing support for .amp files lifecycle, handling archiving, unarchiving, dependencies, install and deployment on enteprise repos

Cool features which you may find handy as a developer are

  • One commad creation of archetype from remote Sourcesense repositories (only maven 2.0.9 installed is required)
  • maven-jetty-plugin embedded run for integration testing,
  • environment dependent and single sourcing of application properties,
  • jboss/tomcat local/remote deployment with Cargo
  • Easy integration with other opensource frameworks due to wide Maven support

while as an enterprise release manager you could appreciate

Hopefully it can really gear contributions on Alfresco and grow it to the open source mature development process we try to deliver every day: and be careful, this is not only a Sourcesense marketing ad, but an approach already proof to be a development booster  on my project on a day by day basis since almost a year. And considering Alfresco 3.0 will be fairly modular, I think Maven has a point.

Give it a spin and let me know…

Issues are always welcome 😉

Alfresco and the sustainable open source
(aka Maven is your friend :)

Since almost one year I’m involved in Alfresco ECM huge architectures design, and considering my expertise in open source communities, I’m now at the level of being able to give a clear statement on which are the aspects (not in the Alfresco meaning 😉 in which this GREAT product still lacks, especially in terms of open source maturity and scalable community / enterprise application lifecycle support.

My past experiences with open source communities and frameworks like Apache Cocoon , recently released 2.2 version with features like complete springification but most important (to me) the full m10n (mavenization, from Apache Maven), taught me that even the most genius idea, the best architectural pattern or the killer app, will NOT have the desired penetration and adoption (and expected ROI, if you think about enterprise backed open source) if not properly backed by a solid foundation which can (at least) provide the following high level features (among many others which I consider as derivatives):

  • Easy inter-component and intra-component reuse gearing best practices
  • Centralized and standardized component management and definition
  • Fast project startup and (fast if not “hot”) develop-test-commit cycle

Read more Alfresco and the sustainable open source
(aka Maven is your friend 🙂