If you are working or willing to work on Alfresco ECM platform with Maven, you better stay tuned and keep your patience for a few weeks more.

Why?

Well for a few interesting reasons:

*  The Maven Alfresco Community is growing and every day there is more activity in the lists and on the code contributions side. If you need information around Maven and Alfresco, the Maven Alfresco discussion group is the place to be.

* Alfresco is integrating Maven artifacts deployment in its build process (see issue): we are literally days away from having 3.4 and 4.0 Community and Enterprise versions available on the Alfresco Artifacts Repository. BTW, bear with us in these days as some changes might be undergoing in the repositories. This is great news for all of you who are hosting corporate repositories (especially for Alfresco Enterprise) as this way you will just have to point to maven.alfresco.com to retrieve Alfresco artifacts

* We are working actively (kudos to Mau) on a clean, neat, supportable version of the Maven Alfresco Lifecycle project: if you check out the experimental branch you’ll find a nicely merged, lean, fully functional set of parent POMs and archetypes to allow you, for example, to run a full Alfresco Repository, Share, AMP, etc. as a single project embedded in Jetty and H2. Nice, ain’t it? Stay tuned there because we are aligning that to the automated deployment at point #2, so we’re just really weeks away from a nice, fully featured, extensible but above all standard open Maven Alfresco SDK.

As we do lots of progress on this area, your feedback is more than welcome and, once again, bear with us while we actively work to make your Maven Alfresco developer life easier.

I’m proud to announce that thanks to a vigorous Community help (special mentions and kudos to Mao and Stijnr for the great help in the last period), we have been able to pull out the 3.9.1 release of the Maven Alfresco LIfecycle.

Multiple bug-fixes, a zero defect targeted release and a couple of juicy new features like:

• Support for H2 DB embedded run
• Support for empty file-mappings.properties (to map WEB-INF)
• Support for Share AMPs

make of this one probably the most stable and tested release of the Maven Alfresco Lifecycle. The release is tested against Alfresco 4.0b Community, and it’s the perfect foundation to the great work we are going to do in the next weeks to clean it up completely and support Alfresco Enterprise.

The releases is available in the Maven Alfresco Repository (in case you are wondering, I still need to update the archetype-catalog.xml, but that will happen just after Easter, as I have no permissions right now ). Full release notes are also published on the Google Code project and per component documentation is available in the brand new published Maven Site (using the HUGELY COOL Maven Fluido Skin).

Feedback is always welcome in the Maven Alfresco List and we also have a Skype chat so feel free to contact me on Skype if you want to contribute / participate in any way

Have fun and let us know what you think!

Of course prerequisite is that you need to have some kind of X11 server running on your client, whose display will be forwarded to the server. Linux has it by default, Mac users can install it from the OS disks, for Windows users I suggest XMing to avoid the whole CygWin download).

So this is Gab self reminding recipe for that (tested from MacOS 10.6.8 to RHEL5):

1. Make sure that

   "X11Forwarding Yes"

   is in your

   /etc/ssh/sshd_config

   on the SERVER SIDE

2. Make sure that

   "ForwardX11 yes"

   is your

   /etc/ssh_config

   (or

   /etc/ssh/ssh_config

   for Linux distros) on the CLIENT SIDE
   

3. Login to the machine with

   ssh -X user@host

4. If “echo $DISPLAY” does not display any meaningful value (e.g. host:display) then you typically miss libraries on the server side. From root or sudo your should issue at least (this worked for me on all RedHat based distros):

• yum install xorg-x11-xauth

• yum install libXtst

• yum install libXi

At that point you might have to logout/login but the you should be able to run whatever X based application (e.g. JConsole, JProfiler, can you tell I use Java? ) directly from the server and see the UI pop up on your client.

Never forget anymore Gab…and thanks for reminding to write this down my friend

• BP-1 (Best Practices) -  “Alfresco 4.x scalabity and performance”
• PLAT-1 (Platform) – “CMIS in the Real World”
• BP-5 (Best Practice) – “Alfresco Application Lifecycle Management”

Turnout was great and the event was wonderfully mastered by our beloved Chief Community Officer: regarding my presos, I found a very good general interested public on my Maven + Alfresco Application Lifecycle preso, as the Slideshare searchbox top suggestions seem to confirm

A couple of other presentations were using Maven and I even heard our mighty VP of Engineering mentioning the magic 7-six lettered word a couple of times in the Engineering QA panel.

New challenges in scalability and complex application management are to be expected with the so long awaited Alfresco 4.x version (BTW, don’t forget to join the 4.o EE launch parties

So I think we can expect more VERY juicy news VERY soon in scalability and Maven…once again, stay posted

Still it’s the best representation of contradiction I can think of. Maybe it’s because I’m Italian and, although living in the Netherlands for 5+ years, I still have a pretty tight connection with my mother land. And there are some things which I feel I need to post, at least because those are the main reasons why I don’t want to go back home now.

This is mostly a technical blog, so I will start with something somehow technical, which was the original reason for this post: as you might have heard already, seems that neutrinos have been recently discovered to be able to travel faster than the speed of light. This would have disruptive consequence’s on Einstein relativity theory and on other pillars of contemporary physics. But that’s another story and worth reading some expert’s blog post as well at the original paper

The point is another one: the original article is in from a international team involving many Italians, since the measurement of neutrinos speed was done from Geneve’s CERN to Italian Gran Sasso laboratories. And that’s when Italy is somehow involved in something big, that some character of the great persistent comedy troupe which is Italy comes into stage.

This time it was our “smart” Minister of Education, Mariastella Gelmini, came out with this press release (English Translation) on the official Minister website to actually congratulate with the scientists for their discovery, but especially to take credit for

“The construction of the tunnel between CERN and Gran Sasso Laboratories, through which the experiment took place, Italy has contributed a sum now estimated at around 45 million euros. “

Now, I’m not asking Ministries to be nuclear physicists (although I’d secretly dream of it), but at least to have a decent level of culture or realism not to imagine that that a 730km tunnel (yeah, that is the air distance between CERN and Gran Sasso) could have been build below Alps and Apennine Mountains.

I’m fed up of having to take account for the stupidity (yeah that’s the only good definition of it) of our Government and in general of the whole ruling class in Italy, since, when I finish working, it’s always about those childish, banana republic style, ignorant declarations that some random member of our Government does.  No wonder why all my foreign friends sort of laugh at us for that.

I’ve never wanted to play the part of the “bitchy expat” that over-criticizes his country, but it seems at least we (expats) have a lower threshold of BS we are able to digest.  So think it’s time to do something more substantial to actually try and wake up our country, that seems now asleep, almost indifferent to any type of attack to normal rules and democracy, completely powerless drugged by media.

Other Italian expat fellows seem to have been stroke by this, last, unbearable deprivation of the Italian culture.

And don’t get me wrong, I still like to remember all great things Italian culture did in history. People like Leonardo, Michelangelo, Cristoforo Colombo, Guglielmo Marconi, Enrico Fermi or periods like Renaissance or the same Roman Empire marked our cultures permanently.

That’s why I think we should get organized and do something, something very well designed and planned, using the weapons of internet and social networks to propose a wake up call for Italy and destabilize the current status quo. I am sure we can out smart them, they are basically organized old farts. Italy is a cash cow right now.

Just brainstorming here, but I am all in for any initiative any reader will suggest!

I’m all ears …

I’m very excited about what’s going to happen and I’m going to participate to next week in my mother country

If you did not know (and so should definitely join!), next week we’re holding an Alfresco Developer Conference in a nice venue in Rome!

The DevCon is spread over two days (Tuesday 12th and Wednesday 13th of April) and will be full of technical in depth topics on Alfresco product and application development.

On day 1, we’ll be hosting a full day introduction of Alfresco Fundamentals, in which I’ll be giving quick and effective insights on Alfresco key concepts like Repository, Content Modeling, Architecture & Technologies.

On day 2, the agenda is full of Alfresco stars like our Product Managers Mike Farman & Ben Hagan, giving us a full insight on the new and great evolutions of Alfresco 3.4 (and above) in the Social Content Management era. I will also be giving a talk about latest CMIS (and the recent OpenCMIS 0.3.0 release) evolutions and how you can leverage them with Alfresco.

Most of the event will be held in the English language, but for all my talks I guess we can of course be a bit more flexible and go for Italian

So, if you did not do it already, please subscribe to this event and join the most interesting Alfresco technical event and first Alfresco Developer Conference in Italy!

See you there!

But I expect some juicy new content to be available soon, I reckon to be interesting for almost all (1 o 2 actually) classes of potential readers of this blog, ranging from Alfresco Partners and Customers to Community members, but also more simply from my personal social (BTW if only all my FB friends would read my blog daily, I would be rich…).

Not much time now but maybe some anticipation (one each, so nobody gets disappointed):

• For Alfresco Partners, we’re working on a Newsletter which will be issued soon with interesting updates and pointers specifically targeted. Stay tuned!
• For Alfresco Customers, my quest for Maven Alfresco Enterprise repository is still on. Hope to be able to post updates soon. But if you also think this is a strong enterprise fit requirement, make yourself heard
• For the Alfresco Community, apart from some juicy release update and review for OpenCMIS and Surf, discussions are starting to consolidate and produce a new release of the Community Maven Alfresco SDK. If you have any wishes join the Maven Alfresco Community so we might produce a more complete and up to date release.
• And for my beloved social network, last but not least of course, 2010 is a key year for my personal objectives and I see it already quite shaky. And I’ll turn 30 in 10 months anyways, so worst case you’ll get to make fun on me getting “older”

Now that I look at it seems more of a TODO list rather than a quick eye-and-attention-catching intro but anyways…anything to add?

Talk soon, gotta go now.

Till a couple of years ago the South Park official site (South Park Studios) was nice, free and open worldwide, airing all episodes and clips just right after US airing, once again demonstrating Matt & Trey (the authors) open mindedness and free-o-cratic approach.

Well that couldn’t last and months ago Comedy Central decided to start shaping traffic from the .com domain to national domains (e.g. SouthPark.nl in my case, being resident in Amsterdam). Pretty fair you would say?

Well, I guess so but you know, as a South Park fan, when they also started messing around with content, limiting views “based on pre-existing contractual agreements” and following the local Dutch TV Comedy Central broadcasting schedule (typically postponing a few, CRUCIAL, weeks after the US original airing), this became hardly bearable

Basically if you try to access SouthParkStudios.com from the Netherlands (in my case) you’ll get a nice Cartman in blond dialog telling you to click and go to the national SouthPark.nl … with outdated content … outrageous

To be honest, I could solve my issues using the infinite resources of online streaming

But today I wanted to do something more: I actually wanted to send a friend a link to a specific clip from the last espisode (“Mysterion Rises”, 14th series, aired last Wed in the US), so basically something possible to just from the US site, SouthParkStudios.com.

First try: with little success I tried the standard Google Translate hack which was nicely detected by the SouthParkStudios, and still the blondish Cartman blocked me.

The way too easy win: 

Looking a bit closer to the type of regional check, I noticed than, upon detecting an access to the .com site from a non US IP address, a grayed out foreground DIV was overlaid on the pre-loaded (and fully functional) underlying .com page.

Well, then, why don’t try with a simple Firefox plugin like Firebug which allows me to point and click the web page and edit the live rendered DOM?

And the game was done: as you can see in the second pic with Firebug open on the SouthParkStudios.com page, I was easily able to identify the DIV which caused the geoblock (search for ‘geoblock’) , and using Firebug DOM editing features I could remove the guilty DIV (apologies to the dutch Cartman and the black DIV).

Of course you need to re-do the edit at every click you do, but you understand how easy would be to automate this using tools like Greasemonkey or successors. This way I could easily browse the .com site from the Netherlands and send the proper Mysterion link to my friend

Now, get me straight, the intention of this post (and of this author) is NOT TO ANYHOW SUGGEST to use this hack (and anyways this was so simple that calling it a hack would be a unique case of overrating), but more to send a message to website writers all over the world, a message which goes something like DON’T INSULT OUR INTELLIGENCE

Please, in the undesirable and potentially not agreeable case that you really need to perform this kind of blocks, take into account that the Internet public is growing in maturity day by day, and you don’t have to be anymore a computer science geek or an engineer like me to actually being able to break such a poorly designed and coded geoblock.

And with specific reference to Matt & Trey: I love you guys a lot, and if you knew me you would know. But you also know (or I think assume) that to watch and appreciate South Park your need a proper level of self irony and a decent IQ … also I know lots of real geek friends of mine which die for South Park, as yes let’s be honest there’s a geek irony component in the series …  then please hire (or tell the Network) to hire some serious guy to run you online video publishing, as with these ***ppy solutions “pre-existing contractual obligations” are doomed to a dark oblivion 

I know “someone” who would be definitely interested to spare a hand 

Today I’m approaching the Spring Surf RC2 release and one of the major thing that has been bothering me (and definitely the other devs) has been the slowness and instability of the Maven build.

Recurring issues like:

• Huge overhead in repository snapshot artifact lookups
• Multimodule useless plugin invocations
• Build randomly failing on the build server
• Release unnecessary complex

In this sense, as Maven has always been my boy, today I decided, prior to the RC2 release, to try and improve performances and stability of the build to a good extent before proceeding with release: in this sense, as I often suggest, a Maven project is somehow like a very sweet but complicated woman, who really need some Tender, Love & Care before actually being able to release all its potential.

And as I believe that, in the infinite hate & love between software writers and software users/configurators, Maven design has too many times blamed for circumstances that actually are fully under the control of the configurator (e.g. the dev who writes the Maven POM), while I go trough this Maven refactoring I dediced to share my experience and achievements with you, to actually try and somehow give Ceasar what belongs to Ceasar.

The Before

Before we enter in the Maven refactoring best practices a glimpse on what the project looks like right now.

• My machine is a MacBook Pro 2.66 Ghz Intel Core 2 Duo, with 4GB DDR3 RAM and MacOSX 10.5.8
• Maven POM on Spring Surf Trunk at revision 603
• Maven 2.0.11 (old version but needed for some non updated plugins) on Java 1.6.0_20
zion:spring-surf-parent mindthegab$ mvn --version
Apache Maven 2.0.11 (r909250; 2010-02-12 06:55:50+0100)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman

• Using Cloc to count lines in pom.xml files across the whole project, I got 7139 LOC
  Command: zion:tools mindthegab$ perl cloc-1.52.pl ~/Dev/alfresco/workspace/spring-surf-parent/ --match-f=pom.xml
  

• With a fairly full repository (already built this at least once) this is the current build performance:
  

  When	Command	Performance
  Original	mvn clean install	18 minutes 49 seconds

Let’s make it fly, now

Best Practice 1 – Lower the number of repositories

Keeping the number of Repositories declared in the POM as low as possible has a drastic impact on the build experience and also lowers concerns on the build being dependent on multiple internet sources to be reproducible. This has to be achieved by:

• Remove development leftovers, i.e. validating which repositories are actually needed by the build
• Use a corporate repository to proxy external repositories, allowing Maven to focus on building and leaving the hassle of remote repository dependency resolution to the proxy repository. In our example we’ll an Enterprise Maven repository software called Sonatype Nexus, which is hosted by Alfresco at http://maven.alfresco.com

In our case Surf original POM contained 10 repositories and 3 plugin repositories which seems really to be an exaggeration, especially most repositories are from the Spring community anyways (and one of them is already the http://maven.alfresco.com Nexus instance).

So first of all I removed the following repositories:

• http://private.repository.springsource.com/maven/bundles/external – This is private repo, not suitable for an opensource project

And then I proceeded removing from the POM (and creating corresponding Proxy URLs in http://maven.alfresco.com) for the following repositories:

Now the whole point of this repository proxying is that Nexus allows us to group repositories on common URLs so that we can have a single reference for only one releases and only one snapshots repositories. In this sense what I did is grouping:

• all the above release repositories under one single URL http://maven.alfresco.com/nexus/content/groups/public/
• all the above snapshot repositories under one single URL http://maven.alfresco.com/nexus/content/groups/public-snapshots/

This way the refactored Surf POM will mention only 2 repositories (+ 2 pluginRepositories) which looks already much better than when we started, see below:
<repositories>
<!-- Alfresco Community Maven Repositories -->
<repository>
<id>alfresco-public-snapshots</id>
<url>http://maven.alfresco.com/nexus/content/groups/public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
<repository>
<id>alfresco-public-releases</id>
<url>http://maven.alfresco.com/nexus/content/groups/public</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>alfresco-public-snapshots</id>
<url>http://maven.alfresco.com/nexus/content/groups/public-snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>alfresco-public-releases</id>
<url>http://maven.alfresco.com/nexus/content/groups/public</url>
</pluginRepository>
</pluginRepositories>

After this refactoring, we tried to run the build again with a following (encouraging, have to admit) drastical 48% performance improvement:

Best Practice 2 – Fine tune SNAPSHOT repositories policies

By default Maven 2 checks always for newer versions of SNAPSHOT dependencies and plugin, but this can definitely be controlled by POM/settings configurations. It’s always a best practice to limit SNAPSHOT update policies to perform a daily check rather than bothering every single build with useless (unless you’re in heavy development phases) HTTP failed requests.

In our case we only have (after applying Best Practice 1) 2 snapshot repositories: in this sense, with respect to the above repositories configuration we only need to add the <updatePolicy>daily</updatePolicy> snippet to the alfresco-public-snapshots repository and pluginRepository.

Since we have few repositories after refactoring, we expect this won’t improve that much the performances (and anyways SNAPSHOTs were already updated today by earlier builds), so we skip the performance improvement step for this best practice.

Best Practice 3 – Limit Multimodule unnecessary plugin executions

When used in their default configuration certain plugins result in unnecessary (or at least overhead) executions for all the submodules in the reactor. In our context, especially, being Spring Surf composed of 30 submodules + 1 parent, well, you can already see the issue.

In particular, looking around in the POM I found and optimized the usage of :

With this configurations turned on, we are happily improving the build performances of another incremental 40%:

Best Practice 4 – Fix plugin versions

One the main causes of non reproducible or instable builds is the Maven “feature” which allows you not to specify a plugin version, in which case Maven will try to retrieve the latest plugin version fronm any of the available repositories. This becomes expecially dangerous when using proxying which are basically mirroring the full Maven public artifacts arena, because, simply, if and whenever someone will upload a new (maybe broken) plugin version your build will pick it up right away potentially failing.

In our contexts no plugins were using SNAPSHOT versions, but I leave this best practice here as a reference

Best Practice 5 – Check for weird plugin executions in your lifecycle

In certain contexts a complex POM configuration or a heavily multi-module build might require certain plugins (in certain configurations) to be ran multiple times, with unnecessary build time wasted. It’s always a good practice to follow (at least once) your build in order to understand if there are weird loops.

In our contexts I was able to find a bug in the maven javadoc plugin 2.6+ which was causing the plugin to be invoked N*N times where N is the number of modules of my project (so N times per each of the N modules). The workaround was to downgrade to 2.5 version of the javadoc plugin.

Wrap up and considrations
Looking at the numbers we can be quite happy of having reduced the build time from 18 minutes and 49 seconds to actually 5 minutes and 51  (a good 68% performance improvement), while POM LOC went down to 6990 (~2% reduction) Not saying this is the recipe for any build improvements, just trying to convey the message that, when used properly, Maven can actually be a great automation tool instead of an additional hassles for the devs.
Last but not least, the ASF has just announced Maven 3, which promises to speed up our builds and provide a much safer framework to do Application Lifecycle Management. So stay posted, because I might try to Maven3ize the Spring Surf build sooner or later