Popular wisdom

Reading more and more Apache mailing lists you often face tougher questions than you can possibly answer but also blatantly obvious (kinda lazy) questions which you’d like to answer in a very nasty and impolite way…

But then as usual “Someone’s did it” and here you are a couple of geek tools when you want to subtly insult an obvious guy:

http://letmegooglethatforyou.com/

and the more impolite

http://www.justfuckinggoogleit.com/

For example, do you want to know how to get more information about me and my work, well. click here if you dare ๐Ÿ˜‰

[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…

Back to the cold…no sorry, hot and humid. But that’s Netherlands and we’ll have to live with that :)

Yesterday night I flew back to The Netherlands from my (first bunch of) holidays, finding (expectedly) the typical, so too typical, dutch rain andย  (pretty much less expectedly) a oustandingly hot temperature but far more humid than the weather I just left: I’ve been in factย  to the best place ever to have vacation, guess where…Italy of course ๐Ÿ˜‰

And particularly I enjoyed Ponza, a wonderful island between Roma and Napoli,ย  in the so called Pontine islands. Special time, relaxing time, during which I realized what was probably inconsciously already motivating my last years decisions to expatriate from Italy and work in Holland, and that is:

Italy is the country of your (or my) dreams when it comes to holiday, relax, well being, easy life, good food and emotions; wherever you go you will find sociality and nature, fun and good mood no matter what.

Holland is instead the ideal place to work, to do your (or my) business in the most optimized possible way, offering a noticeably positive balance between quality of life and quality of work, and a wage/tax conditions people of my same age/education in Italy can only dream about.

But warning: don’t let homesickness gets you mistaken, don’t think that you miss Italy 100% until you come back there and just gave a fast glance at what’s going on down there, the sad staticity so well depicted by the Ecomonist (not exactly one of those “communist” newspaper Berlusconi keep on threatening Italians about) and in general the stressed (because money is running out) but still boastful country in which people keep opening mortgages to go on vacation, almost at the point not to eat to save money to show out a little bit.

“Not too bright folks, not too @$%#!ng bright”
(just to quote a genius men called George Carlin, recently passed away, as he would have hated to say he was dead ๐Ÿ™‚ )

So I realized that until things don’t change, Holland or any other real country (sadly under too many POVs)ย  is the only solution to have a rewarding fair career which does not overburn you, that maks you feel capable of moving, of evolving.
But then as soon as I can have holidays, well, then no comparison is possible: sun, seaside, culture, landscape variety (can’t stand anymore flat low land ๐Ÿ™‚ ), colors, food, family, friends, mood, empathy and too many other things make Italy the place where I really would like to be.

To everything there’s a season, said someone in the past. And I probably found it out now.

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 ๐Ÿ˜‰

Caius iulius gab

After more than five months, I went back to the beloved mother Italy, for both business and homesickness reasons.
After 4 days spent in Milan for the Advanced JBoss training for J2EE developers (which was interesting but not outstanding, considering the quite out of date material and the basic nature of the course), I ran to Rome on Friday 6th in order to see my friends and my parents. Brief parenthesis here, thanks to Trenitalia for raising the Rome-Milan Eurostar ticket of 10โ‚ฌ in less than 2 years. Impressive โ‚ฌuro effects…

But apart from that and from the typical good weather and mom’s food which keep on being the most important roots that bring me back to my country, I was able to join one of the most crazy private parties in Rome which I can remember: have to say that living in Amsterdam, wild parties are pretty common, but I found quite difficult to have the same level of fun (maybe directly correlated to the level of beer) and empathy between people in parties in Rome.

Well, it’s the second year in a row I join these kind of parties (organized by friends of mine which I know since the times of Scarpetteria ): last year it was basically a Pimps and Hookers theme party in which we (me and Mau) masqueraded ourselves with pretty cool results, while this year, supported by all kind of social networking marketing campaigns , the Ancient Roman theme party Baccanalia party had its birth…Gab and vale at Baccanalia 2008

And what a successful birth considering that I ended up as you can see in the photo below (ok, heart shaped glasses are not really latin style but they are SO COOL ๐Ÿ™‚ … and they allow me to meet such cool photographers ๐Ÿ˜‰ PS: well, for those who did not notice before, I cut my dreadlocks ๐Ÿ˜‰

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 ๐Ÿ™‚

Back to (second) life

The few fellow readers (or just occasional surfers as Google Analytics cleverly notifies me) of this blog may have worried about my health, knowing how social and verbose I am, when seeing this blog silent for more than one year. Not that before this was the most active blog ever, but almost 15 months of silence, well, that’s sound kind of rude to the whole social revolution I’m taking part in.
Especially because it’s in the last 12 months that the biggest change in my life happened, both on the personal side with relocation to Amsterdam, working for Sourcesense Netherlands, and on the professional side in which I grew enormously to the role of Alfresco ECM Architect.

Read more Back to (second) life