Let me try and deal with each of your points one by one and explain how
I am trying to solve each issue.
- How to make ivy work differently when projects are build by the CI
machine versus builds on development machines.
I include an environment variable on the CI machine that can be read and
used to parametrise the build. Here is a snippet of ant code.
<property environment="env"/>
<property name="env.builder" value="${env.BUILDER}"/>
<condition property="build.ci">
<equals arg1="${env.builder}" arg2="CI"/>
</condition>
<target name="publish-ci" if="build.ci">...</target>
<target name="publish-dev" unless="build.ci">...</target>
<target name="build" depends="publish-ci, publish-dev"/>
- As to including the version number in the ivy file prior to publish.
You are correct, in that the by using the build number task you are not
setting a concrete revision for your module until you publish. The
other alternative is to hard code the revision into the ivy file
pre-delivery. However surely this implies that the developer (or
whatever is building the module) knows the revision prior to publishing.
As an example we have our project source under SVN. Our CI inspects the
project then builds and publishes if it detects any changes. however if
we hard coded the revision number into the ivy file then our CI machine
would have to update the ivy file with the new version and do a commit.
That didn't sound like a good idea to us, so we headed down the route of
not having the version numbers specified in the ivy file and only
resolving the correct version number upon delivery. Our CI machine will
auto increment the build number, when a module changes significantly we
do a special build of the module updating the major or minor version.
long post, hope some of it is helpful
any advice / comments are welcome
Mitch Gitman wrote:
Thanks, Jonathan. This looks like precisely the simple, obvious approach
that I had been overlooking.
Anyway, this leads me to my next area where I seem to be missing something
obvious. Suppose that *ivy:publish *is normally only invoked during a CI
build. Now suppose that you want to be manually incrementing the minor
version of a given project—call it fubar—from 2.0 to 2.1.
Now, here's the obvious approach. You might create an Ant target that calls
*ivy:publish*, passing in a new version. Perhaps:
ant new-version –Dnew.version=2.1
Maybe you make this slicker and have the Ant build figure out for itself how
to increment the minor version:
ant increment-minor-version
Now, this approach hinges on carving out an exception to the rule that
*ivy:publish
*is only CI-invoked, not human-invoked. That's fine.
What strikes me funny is that nowhere in the source of the fubar project am
I specifying what the current version is or should be. You could be
specifying the revision in the ivy.xml file *in project source*, via the
/ivy-module/[EMAIL PROTECTED] attribute, but to what end? Isn't the revision
attribute, if it's in a source ivy.xml as opposed to a repository ivy.xml,
purely academic? If you look at the documentation page for the /ivy-module/info
element, you'll see this about the revision attribute. Required: "Yes in
repository ivy files, no in ivy files to resolve."
The upshot of this apparent state of things is that the place where the
current version of a project is stored is the published module in the Ivy
repository, and it's only stored there implicitly as divined by the
*buildnumber
*task, not explicitly via some, say, properties file.
You can see I'm kinda groping toward some sort of best practice here, and
I'm sure there is one. How has anyone else who has leveraged the *buildnumber
*Ant task negotiated a manual major/minor version increment?
On Wed, Nov 19, 2008 at 8:28 AM, Jonathan Oulds <[EMAIL PROTECTED]> wrote:
I too have been playing with this. Currently I have an ivy file (see
below) that is configured and delivered during the publish task.
<ivy-module version="2.0">
<info organisation="org.example"
module="FooBar"/>
<publications>
<artifact name="FooBar" type="Library" ext="lib"/>
</publications>
<dependencies>
<dependency name="Foo" rev="latest.integration"/>
<dependency name="Bar" rev="latest.integration"/>
</dependencies>
</ivy-module>
Her is the publish task that will automatically add the correct build
number. ${ivy.organisation} and ${ivy.module} are both set during the
resolve stage.
<target name="publish" depends="resolve">
<ivy:buildnumber organisation="${ivy.organisation}"
module="${ivy.module}"
default="0.0.0"/>
<ivy:publish
artifactspattern="${dir.dist}/[artifact].[ext]"
pubrevision="${ivy.new.revision}"
overwrite="true"
validate="true"
resolver="default"/>
</target>
