Maven Alfresco SDK 1.0.2 is out and ready for your enjoyment :)

Just a quick update for the Alfresco Mavenistas, as yesterday we released the Maven Alfresco SDK 1.0.2!

This is a (major) maintenance release for our preferred Alfresco SDK (see full 1.0.2 release notes), and I wanted to stress a couple of fixes who went in there which might drastically improve your development experience:

  1. As I described in my last post, if you are a Linux/Mac SDK user, then your build is probably going to speed up 5x to 10x times. This is thanks to a fix using the plexus-archiver…I look forward to hear your wows from here 🙂
  2. The latest MMT fixes are in there. This should fix any weird issues of your build in case you were overriding Alfresco resources

You can find official documentation and artifacts on the Alfresco Artifacts repository.

And BTW, I suggest you stay tuned on this channel as I have worked hard in the last months on a plan for a full Mavenization of Alfresco…and you all know what that would mean for the functionality and “coolness” of our SDK 🙂

One thought on “Maven Alfresco SDK 1.0.2 is out and ready for your enjoyment :)

  1. Gab,

    when comparing the jar dependencies of


    with the actual jars in the alfresco.war file (enterprise 4.1.5), there are a LOT of differences.

    Some minor, for example jar dependency is “alfresco-enterprise-repository-4.1.5.jar”, while in the war it’s “alfresco-enterprise-repo-4.1.5.jar”, or sometimes the version number is missing from a jar name in the war)

    Some major, for example missing “apache-solr-solrj-1.4.1.jar” in the jar dependencies, spring-surf-1.2.0-SNAPSHOT.jar exists in the war file, while spring-surf-1.2.0-M6.jar exists in the jar dependencies

    These snapshot vs release and missing jars on either side seem dangerous when developing for an enterprise environment.

    My guess is that the original alfresco.war file and/or some of it’s dependencies are still being build using ant scripts instead of a proper maven pom.

    With the scope of several jars being default compile instead of provided, this runs the risk when building a war overlay that a lot of jars will be mixed that really shouldn’t be mixed. (with potentially unexpected/dangerous results, a bad thing for enterprise)

    Am I being over concerned here? Love to hear your thoughts about this!

    (Email me anytime)


Leave a Reply

Your email address will not be published. Required fields are marked *