Archive for April, 2011

How to upload your artifacts to Maven Central?

I just applied for access to upload my maven plugin to Maven Central Repository and I would like to outline the steps I have followed. There is already a couple of HowTo pages on the subject but mine will be much shorter. You just have to follow the steps given below in order to have your artifact on the Maven Central.

First of all you need to have a PGP (Pretty Good Privacy) signature known by public signature servers.

Go to GnuPG web site, download and install it on your computer. For linux user it is good old ./configure; make; make check; sudo make install routine. Windows users have the option to download it as a binary. After installation follow the steps given below to have your public key signed.

$ gpg --gen-key
$ gpg --keyserver hkp://pool.sks-keyservers.net --send-keys C6EED57A

To obtain the ID of your generated key, execute the following command.

$ gpg --list-keys
/home/john/.gnupg/pubring.gpg
-----------------------------
pub   2048R/C6EED57A 2011-04-24
uid                  John Doe <john.doe@csi.com>
sub   2048R/C6EED57A 2011-04-24

Now that you have your key signed with public key servers, you can upload your artifacts to Maven Central. Now all you need is to have access to the repo. The easiest way to gain access to Maven Central is via Sonatype OSS Repository. It is an Apache approved repository provided by Sonatype and it helps any OSS (Open-source Software) project to have their artifacts uploaded to Maven Central.

Sign-up to Sonatype JIRA and create a JIRA ticket for access.

You have to choose Community Support - Open Source Project Repository Hosting for the ticket and enter the required information properly. They require you to provide the following information.

  • Summary: a brief introduction of your project
  • groupId : the groupId of your Maven project
  • Project URL : location of the project website
  • SCM URL : location of source control system
  • Nexus Username : the JIRA Username you just signed up, one or more
  • Already Sync To Central : if yes, we will copy those artifacts to Sonatype repository, and rebuild a correct maven-metadata.xml
  • Description

For more information please refer to this guide provided by Sonatype.

After your request is processed they will provide you the repository url's to upload your artifacts to.

Sign your artifacts and upload to the provided repositories

In order to sign your artifacts you can use maven-gpg-plugin otherwise you have to sign them manually using GnuPG. See the plugin page if you need more information on how to use the plugin.

After you upload your artifact to Sonatype OSS Maven Repository, they will be synced to Maven Central for you.

Maven plugin to force parent POM upgrades

It is no news that having a corporate POM for a group of projects is a maven best practice for standardization purposes and avoiding repetition.

And just like any other project a parent POM is also a living project and you need to update it from time to time. When the parent POM is updated, you also need to make the inheriting projects receive this update. There are two ways to do this;

  • We can either perform releases and have the version increased
  • Or we can deploy it without making a release (no version increase)

At first the second option seems logical since it does not require any communication to inform the users of this POM to upgrade the version. Actually it does. When you make a deploy without a release, there is no way to be sure that the developers will have the latest POM on their local, maven will not download it from the repository because there is already the copy in the local repository with the same version.

There is a long thread discussing these two approaches. As stated by someone on this thread that the problem is actually the same, either way you need to communicate the update with the developers. The only difference is the content of the dispatch :)

  • For the first approach, you have to tell the developers to upgrade the version of their parent POM to the latest one. (send an email)
  • For the second approach, you have to tell the developers to delete their local copy of the parent POM from their local repository. (send an email)

In the end the problem seems to be how to communicate. Sending an email is not a good option, it can get lost, go to junk or simply can be ignored. We need a persistent and controlled way to communicate this. We can simply make the maven build let the developers know that there is an update, we can even make the build fail if it is needed.

What the simply plugin does is;

  • Checks whether the current building project has a parent POM
  • If so checks whether it is one the parent POMs that we want to check for updates
  • If so checks whether there is a newer version
  • If so depending on the plugin configuration, it makes the build fail or print a warning to let the developer be aware of it

In order to activate the plugin all you have to do is to configure it within your parent POM. See the following snippet for the configuration options.

<plugin>
    <groupId>org.hoydaa.maven.plugins</groupId>
    <artifactId>parent-checker-maven-plugin</artifactId>
    <version>1.0-SNAPSHOT</version>
    <configuration>
        <!-- When true makes the build fail if there is a new version-->
        <forceUpgrade>false</forceUpgrade>
        <!-- The parent artifacts to check for -->
        <checkArtifacts>
            <artifact>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-parent-checker-plugin-parent</artifactId>
            </artifact>
        </checkArtifacts>
    </configuration>
</plugin>

The plugin attaches itself to validate lifecycle phase if the user does not explicitly specify an execution.

At first sight making the build fail when there is a parent POM update seems annoying from the developer perspective however there are sometimes that you want to ensure that the version is upgraded by all the using projects. But with the configuration above you cannot do that, you cannot change your config to force the upgrade because this config is already in your parent POM, meaning; in order to force you need the using projects to upgrade the version. It is a chicken-and-eggs problem.

There is another option to make a SPECIFIC VERSION of your parent POM to force the update. You can define the very same property force.upgrade as a property in your parent POM just before release. Besides just checking plugin's configuration for forceUpgrade, the plugin also searches force.upgrade property within the available parent POM to see if there is a SPECIFIC VERSION that forces for upgrade. And if it finds a version forcing for upgrade, it will make the build fail not matter what the plugin's forceUpgrade config is. See the following example config.

<project>
....
    <properties>
        <force.upgrade>true</force.upgrade>
        ....
    </properties>
....
</project>

See the following sample build outputs depending on the situation.

When the plugin is configured with force.update=false and there are two new versions, it just displays a warning log.

[WARNING] New versions available for your parent POM org.hoydaa.maven.plugins:test-parent:pom:1.1!
[WARNING] 1.2 (not forced)
[WARNING] 1.3 (not forced)
[WARNING] Your parent POM org.hoydaa.maven.plugins:test-parent:pom:1.1 is 2 versions behind, you have to upgrade it to 1.3!

When the plugin is configured with force.update=true and there are two new versions, it makes the build fail.

[WARNING] New versions available for your parent POM org.hoydaa.maven.plugins:test-parent:pom:1.1!
[WARNING] 1.2 (not forced)
[WARNING] 1.3 (not forced)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Your parent POM org.hoydaa.maven.plugins:test-parent:pom:1.1 is 2 versions behind, you have to upgrade it to 1.3!

When there are three versions one of which is forced (meaning there is a property force.upgrade=true within the released parent POM, it makes the build fail even the forceUpgrade is false for the plugin.

[WARNING] New versions available for your parent POM org.hoydaa.maven.plugins:test-parent:pom:1.1!
[WARNING] 1.2 (not forced)
[WARNING] 1.3 (not forced)
[WARNING] 1.4 (FORCED)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Your parent POM org.hoydaa.maven.plugins:test-parent:pom:1.1 is 3 versions behind, you have to upgrade it to 1.4! You have to upgrade your parent POM to the latest forced update at least!

The source code of the plugin is on github, feel free to check. I will also try to put it on maven central repo.

What does Alfresco mean by Social Content Management?

For those who follow/use Alfresco content management platform, it is no secret that the product team is heavily working around this new phrase (social content management) and they are planning to release features starting with version 3.4.

When I first heard the word social content management --in the same sentence as alfresco--, I let the intuitive side of my brain to understand what it might mean.

  • What does social content management mean or rather what does it mean in the context of a content management platform?
  • Is it making the product more social friendly (UI improvements to ease up collaboration) or does it really mean managing content through different social channels like twitter, facebook, youtube?

Luckily, I had the opportunity to see the CEO's (John Powell) presentation on the very same subject in one of alfresco's solution partner's client day and also had the opportunity to discuss it both with the CEO and WCM product architect (Brian Remmington). These are the things I extracted from the talks, not exactly things that was told.

There are new features coming with the next releases to make the product more social, more collaborative. These are mostly some UI improvements to make it more collaborative, they will simply provide a new UI based on Share for the existing social features like rating, blogs, wikis, etc. As you may know Share is the their new user interface that is based on Spring Surf (developed by Alfresco and adopted by Spring).

Besides UI improvements, one exciting feature is the Google Docs integration. I assume they also realized that it is very expensive to provide a better online authoring experience than Google Docs (also Alfresco is a content management product rather than being an online authoring tool) and decided to leverage Google Docs. As far as learned, it will be possible to author content on Google Docs and import them to Alfresco or the way around. They are even in contact with people from Google in order to be able to provide a better integration.

These are all good features but what about social content management? It is the same question, right :) The difference is nicely put by Jeff Potts in one of his blog posts. Where is the emphasis in this phrase, is it more about social content management (managing the content collaboratively) or social content management (management of social content)? Personally I want to see something related to the latter one.

Apparently they will implement a publishing connector for different social channels like Facebook, Youtube, Twitter, etc. Now, this is a novel idea that can change the way we look at content managements systems. You may agree that marketing has also changed a lot in the last decade. Nowadays marketing for a product might also include, launching a Facebook page, tweeting updates, publishing product videos on Youtube, etc. However until now these are the things done by marketing departments manually. All the marketing departments are already authoring content for different mediums/channels and why not reuse some of these content for social channels? It may even be possible to put a process into place in case of product launches, everybody knows the difficulties with product launches; every step has to be performed in a specific order and there is no margin for error (if something fails everything has to be rolled back).

I am really looking forward for this social publishing connector and I hope it would be flexible enough to introduce new channels easily.