ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Oulds <jonat...@sbdev.net>
Subject Re: buildnumber Ant task & automated updates of ivy.xml
Date Thu, 20 Nov 2008 11:10:41 GMT
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/info@revision 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 <jonathan@sbdev.net> 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>
>>
>>


Mime
View raw message