Sonatype Nexus and Apache Ivy

In order to move STAR’s webapps to a more enterprise-like structure, I really wanted to deploy a private artifact repository. Some quick searches I found various artifact managers, but I found that the Sonatype Nexus repository fit well for STAR’s usage. I will forgo the configuration setup to focus on my experience and comments regarding usage.
Configuring artifact users and permission is very easy. Sonatype Nexus created a distinction between the users it manages versus the users an external service manages. An external user must be given permissions to manage the artifactory, or else the artifactory would deny an external user. Therefore, user management, whether internal or external, was intuitive.
Due to the nature of Sonatype Nexus being a Maven artifactory, there are a few configurations that need to be done in regards to Apache Ivy integration. By the rules governing the retrieval URI, the Nexus artifactory will allow both a mixture of classified and unclassified artifacts. But in regards to Apache Ivy, the artifact classifier field’s importance depends on the method used to retrieve the artifacts. The classifier field is only necessary when uploading more than one artifact per module as the URI pattern is:

[organization]/[module]/[version]/[module]-[version](-[classifier]).[type]

The classifier’s existence depends on whether it was previously defined.

The problem with allowing the classifier to be optional manifests itself in the artifact retrieval process with Apache Ivy, not with the method Sonatype Nexus handles the artifacts. If the classifier attribute is defined for an uploaded artifact, then the default Ivy retrieval pattern must be overridden as: 

[organization]/[module]/[version]/[module]-[version]-[artifact].[type]
 In practice, using a mixture of classified and unclassified artifacts fails to resolve properly.

Let’s assume that all uploaded artifacts have a defined classifier. All artifacts can be defined in the ivy.xml file as:

   
     

       
     
   

or in shorthand as:

    <dependency org="com.example" name="module" rev="3.0"/>

if all that is necessary is the jar file. The short hand dependency tag will define the [artifact] attribute as the same as the [module] attribute and the [type] attribute as jar. Please refer to ivy.xml and ivysettings.xml to gain a better understanding.

Now that we can define which artifacts to retrieve, actually retrieving the artifacts is the easy part. Basically, this is the only line needed:

   

Publishing an artifact to the artifactory is just as easy.

<ivy:publish resolver="nexus" organisation="com.example" module="module" revision="3.0status="publish" overwrite="true" forcedeliver="true">
<artifacts pattern=”${basedir}\publish\[artifact].[ext]/>


FYI, since the ivy:retrieve and ivy:publish will be defined inside an Apache Ant build file, it is possible to define a property for the organization, module, revision, and status. If these attributes are defined as an Apache Ant property, the ivy.xml file will inherit the properties. The Ant properties can then be used to automatically populate the ivy.xml’s info tag.

Advertisements