On Oct 22, 2008, at 4:45 PM, mvlcek wrote:
I'm currently converting a ant build script with ivy dependency
resolution and publishing to a gradle script.
However, although gradle integrates ivy, I have found nothing to
simplify determine a version number.
Let me first explain what we do currently with ant:
read the current version number from a property file ..properties
on a file server
if the property file is not available, assume version 0.0.1
if the target publish_major is executed, increment the major
version number and set minor/patch to 0, similar for publish_minor
and publish_patch, otherwise append '-SNAPSHOT' to the current
version number
li>publish the files (gradle: uploadLibs)
the same for the targets deliver_major, ... (gradle: uploadDists)
How does this work with Ant? If you call publish_major the jar is
build with another target publish_major depends on. The jar target
does not know that publish major is called. So I guess the jar has no
version name and but is published with a version name.
increment the patch version number and save it to the property file
Of course we can do this with gradle, too - it's even shorter than
with ant.
However, it needs to be in every gradle file (in ant it's in an
include) and it could be much simpler.
Here my proposal:
In the init-Task of the Java plugin do the following, if the
project.version is not yet set:
get the latest version number for the current project module
(project.group/project.name) from Ivy using the uploadResolver(s)
from uploadLibs
if no published version was found, assume 0.0.0
Good idea.
if the property 'major' is set, increment the major version number
and set minor/patch to 0, similar for properties 'minor' and 'patch',
I'm not sure if properties are the best way of doing this. I'd rather
have the tasks publishMajor, publishMinor, publishPatch. As Gradle
evaluates the whole execution graph before the build gets executed,
we can provide this graph to the build script:
build.taskGraph.whenReady {graph ->
if (graph.hasTask(':publishMajor')) {
} else {
}
}
I think it makes the build easier to understand and to use if we use
tasks instead of properties. On the other hand there are issues due
to the fact that whenReady gets called after the build script is
evaluated. In the Gradle build we use this approach. But I'm not sure
what the best approach is after all.
otherwise if the current version is not a snapshot version,
What would make the current version a snapshot version?
increment the patch number
I think not necessarily the patch number. In our Gradle build we
check if the working copy belong to trunk or a release branch. If it
belong to trunk we increment the minor version, otherwise patch.
Whatever the default behavior is, we should provide a hook for custom
strategies.
and add '-SNAPSHOT' (configurable?) to the version (this ensures
that using 'latest.integration' as version in a dependency will
really get the latest version)
set project.version to the calculated value
This should be quite easy to implement (if you know the Ivy-API)
and would implement a default behavior which can easily be ignored
(by setting the project.version manually).
In any case, a method String Project.getLatestUploadedVersion()
would definitely be very appreciated.
Comments? Ideas to make it even more general?
It is a core feature of any out of the box release management
support. I like this very much. For our Gradle build we have custom
logic to implement this, it would be much nicer to have generic
functionality for this. To be really flexible I like the following
options to use this functionality.
1.) Out-of-the-box + configuration (e.g. by properties)
2.) Out-of-the-box + hooked in custom strategies + configuration
3.) Toolbox usage. The custom logic does not fit into the framework
but we can still support our users by providing tools (e.g.
RepositoryVersionFinder.latestVersionFromRepository()).
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
