0
votes

I'm trying to upgrade librarires and artifacts management in my company. Now we're making artifacts (jar, war, ear files) with ant scripts running from Jenkins. I'd like to add Ivy and Artifactory but I'm a little bit unsure what would be best (or at leats good) configuration. As per documentation, Ivy has three repositories (local, shared and public) and additionaly cache. Reading Artifactory docs, one has to configure Ivy files for Artifactory resolver (not repository?!). My questions are:

  1. Would that be public repository in Ivy terminology?
  2. Is Ok tu use only one Artifactory repository for development (we have 4 teams) and deployment pipeline?
  3. What would be (approximate) configuration? Is this ok (public ibiblio + enterprise Artifactory)?

    <resolvers>
        <ibiblio name="libraries" m2compatible="true" />
        <url name="arti">
            <artifact pattern="http://localhost:8081/artifactory/libs-snapshot-local/[organization]/[module]/[revision]/[artifact]-[revision].[ext]"/>
            <ivy pattern="http://localhost:8081/artifactory/libs-snapshot-local/[organization]/[module]/[revision]/ivy-[revision].xml" />
        </url>
    </resolvers>
    



Update on 11th Feb: Just for the record, here is working configuration:

<credentials host="artifactory.host" realm="Artifactory Realm" username="admin" passwd="password"/>

<resolvers>
    <chain name="loc-ext">
    <filesystem name="tmp-lib">
        <artifact pattern="${ivy.settings.dir}/lib/[artifact].[ext]" />
    </filesystem>
    <ibiblio name="libraries"
        m2compatible="true"
        checkmodified="true"
        root="http://artifactory.host:8081/artifactory/ext-release-local" 
    />
    </chain>

    <ibiblio name="snapshots"
        m2compatible="true"
        pattern="[organisation]/[module]/[artifact]-[revision].[ext]"
        root="http://artifactory.host:8081/artifactory/libs-snapshot-local"
    />
</resolvers>

Chain resolver is for retrieving (f.e. for compiling), tmp_lib has libraries, that are needed only for current task, libraries is sort of enterprise repository and snapshots is for publishing.

1

1 Answers

2
votes

We us Artifactory, Jenkins, and Ivy to build most or our projects, but I probably am doing it all wrong.

First, we don't bother with a shared repository. It never made much sense to me. The shared repo looks similar to the private repo, but is shared among developers. What makes that so different from a Artifactory repository that's only shared among the developers?

We also use <ivy:makepom> to create a pom.xml and then use mvn deploy to deploy our artifacts to our Artifactory repo instead of using the <ivy:publish>. We make two poms per jar, one is pom.xml and the other is pom-snapshot.xml. We use Jenkin's Build Promotion Plugin to run mvn deploy with each successful build to deploy the snapshot jar, and then let developers manually "promote a build" via the Build Promotion Plugin to deploy the release version of the jar.

Ivy has the concept of status which looks similar to the snapshot vs. release idea of Maven, but I believe that all these jars with their status are deployed to the same repo. I simply keep the status set to release and depend upon the snapshot/release concept in Maven.

Developers can switch from snapshot versions of a jar to the release version by simply appending or removing -SNAPSHOT from the revision in ivy.xml. This allows developers to use recently built jars without waiting for them to be promoted to the release repository.

My main concern was keeping Artifactory compatible with Maven since some of our projects are Maven projects. Some of this was due to not being 100% familiar with Ivy, and having a firmer grasp with Maven. However, it does work for us and keeps me from worrying about the differences between Ivy and Maven.

Now, that you know we're doing it all wrong, here are the answers to your question:

  1. Would that be public repository in Ivy terminology?

Ivy has the concept of status, but I'm not sure how a Maven project could use that. This is why we use mvn deploy and why we build a snapshot and release pom with each build.

  1. Is Ok tu use only one Artifactory repository for development (we have 4 teams) and deployment pipeline?

Sure, why not? What would be the advantage of making four separate repositories. Besides, even if you go with the separate repositories, you could create them all with a single Artifactory instance. This way, you could assign read/write permissions to each group for each of their repos, but only have to maintain a single Artifactory instance.

  1. What would be (approximate) configuration? Is this ok (public ibiblio + enterprise Artifactory)?

Ours is:

<ivysettings>
    <resolvers>
        <ibiblio name="public"
            m2compatible="true"
            checkmodified="true"
            root="http://buildl01.tcprod.local/artifactory/libs-release" />
    </resolvers>
</ivysettings>

But we're not deploying as Ivy. Just reading from a Maven repo. The libs-release is a virtual repo with includes our local repo and the public repos from Maven, JBoss, and whatever repos we need.

I have a special ivy.dir project that automatically integrates Ivy into our builds. You add in <import file="${ivy.dir}/ivy.tasks.xml"/> into your build, and you automatically have all the necessary Ivy settings. I also create several parallel macros such as` that are drop in replacements with the standard Ant tasks, but do a few mysterious things behind the scenes.

For example <jar.macro> creates a pom.xml, a pom-snapshot.xml, and embeds the Maven info (plus the Jenkins build info) into the jar. This way, developers could start to integrate Ivy into their build process with a minimum of fuss.