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>
>
>
