Get yer deployment on, watch out!


I’m becoming sort of a Mavenvangelist or whaddever-yuh-call-it. Even as such I have to admit the tool has some rough edges. This morning I wanna point out one of these rough-edge-I’m-going-to-get-you things that you might not be aware of or maybe you are. Even if you are read up because it bites even when you do know completely what you’re dealing with. I call it configuration spillage.

In Maven you have this awesome ability to point your build to any repository you wish. The repos can be virtual, chained-together, or whatever crazy idea you can come up with. (I’ve dreamed up a couple of wild ideas here.) The problem here starts with where the repository management ends and where the project management begins. Configuring an internal repository for deployment seems to require entries in both the settings.xml which should be shared across team members and also the project descriptor, pom.xml file. The crazy part that I can never get straight is how the majority of these configs go in the pom file leaving only the most critical piece sitting in the settings.xml file. For example, consider an Artifactory deployment repository. In the pom.xml you put something like this:

    <distributionManagement>
        <repository>
            <id>artifactory-webdav-on-server1</id>
            <url>dav:http://myrepo:8080/artifactory/libs-releases@repo</url>
        </repository>
        <snapshotRepository>
            <id>artifactory-webdav-on-server1</id>
            <url>dav:http://myrepo:8080/artifactory/libs-snapshots@repo</url>
        </snapshotRepository>
    </distributionManagement>

Then you authenticate the deployment repository using these tags in settings.xml:

  <servers>
    <server>
    	<id>artifactory-webdav-on-server1</id>
    	<username>user</username>
    	<password>password</password>
    </server>
  </servers>

This morning I worked on relocating our deployment repository and because I got bit by the split config thing in the past I spent a good twenty minutes trying to identify all of the tricky configuration. It’s hard to put into words but I knew that I needed to update the deployment settings but I couldn’t figure out how the pieces tied together even as I had been down this path before. I got mad work to finish and just wanted to tip anybody out there. If you got a Maven repo setup and you think you got all your pieces in place check again. The other problem you’ll hit is referencing server names in the ids. It feels perfectly natural to add configs with ids like artifactory-webdav-on-server1 and proximity-ssh-on-server2 especially when you’re experimenting with two or more kinds of repos trying to settle on a best fit. but later when you say, “ok we’re going with Archiva” and release both pom.xml and settings files with both Archiva and server names littered everywhere installing new machines, changing DNS names and/or deploying something like Artifactory becomes a pain. A better approach would be to use something like this:

    <distributionManagement>
        <repository>
            <id>artifactory-webdav</id>
            <url>dav:http://myrepo:8080/artifactory/libs-releases@repo</url>
        </repository>
        <snapshotRepository>
            <id>artifactory-webdav</id>
            <url>dav:http://myrepo:8080/artifactory/libs-snapshots@repo</url>
        </snapshotRepository>
    </distributionManagement>

Then you authenticate the deployment repository using these tags in settings.xml:

  <servers>
    <server>
    	<id>artifactory-webdav</id>
    	<username>user</username>
    	<password>password</password>
    </server>
  </servers>

Hit me up people!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s