ABL procedure library dependency resolution with Ant/PCT

Hi Peter,

I've got Ivy working nicely now & would highly recommend it (although figuring out how to structure things was a bit of a pain).

The only missing functinality is that PDSOE doesn't let you have an Ivy-managed propath & so we're still hand-crafting propaths separately from our Ivy.xml files.  I suspect that there may be a way to automate this, but I've not managed it yet.

The tools I'm using are:

• Kiln for SCM (which uses Mercurial under the hood)
• Hudson as our Continuous Integration server (planning on migrating to Jenkins soon)
• Artifactory as our binary repository
• Ant & Ivy to manage Progress projects (we use maven for some Java projects

Each project has it's Ant build.xml & Ivy ivy.xml in its project root folder.

Common Ant tasks are held on Artifactory & imported into each project via an <import><url url=xxxx/></import> element.

Common Ivy settings are held in a Kiln repo so that they are easily shared between devs (they rarely change)

The workflow is:

• Dev pulls project from Kiln & commits his changes locally
• Dev pushes work to Kiln repository
• This automatically triggers a Hudson build:

• Build pulls the contents of the repo from Kiln
• Build then runs the Ant build script
• An Ant target in the build script resolves Ivy dependencies that are defined in ivy.xml & retrieves them locally (with artifact names that are not version-specific (i.e. we create lib/MyLib.pl, not lib/MyLib-1.1.5.pl)
• Ivy is configured so that it will auto-unzip any dependencies packaged as zips - means that we can depend on source (e.g. a common ADM framework), database schemas, or other resources
• Ant then compiles up our source with a hand-crafted propath that includes the dependencies that we've pulled in via Ivy. If we've pulled in database dependencies, then Ant can compile the source against those DBs.
• The compiled source is packaged into .pl files (which we sometimes zip up to save space), any publishable resources are zipped up.
• Ant then calls ivy:publish to publish the artifacts of the build to Artifactory.

• If the build was successful then Hudson will trigger a build of any downstream jobs (configured by hand).

One nice twist (that took a while to work out) ... we can seamlessly build multiple OE versions of all projects (helps us when we're migrating):

• Hudson jobs are setup to build each project for multiple OE versions (version passed as a property to the build script)
• We have a separate Aritfactory repository for each OE version (all within a single Artifactory instance)
• Our shared Ivy settings file references the OE-property version supplied by Hudson & use it to connect to the appropriate Artifactory repo. This repo is used to resolve+retrieve+publish
• This means that our ivy dependencies can be written in an OE-version-agnostic way

We use Roundtable and have a set of tools on top of that to handle the "configuration" of server and client packages. Part of this configuration is which parts of an application go into procedure libraries at build time - using a set of "rules" currently managing in an XML config file that is part of the version controlled application.

When code is deployed from RTB, it can then be processed with our deployment tools which are a combination of ABL code and Ant scripts.

All of this can be tied together using scripts or running from CI tools like Jenkins.

We are currently not using PCT to create the pl files, but rather ABL code that processes our configuration rules. This may change as we look at how we can use some of the new tools that are out there.