A
andrew.may
Guest
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
ublish 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
Continue reading...
ublish 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 wayContinue reading...