On Oct 25, 2008, at 3:41 AM, Adam Murdoch wrote:
Hans Dockter wrote:
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()).
Do you mean we would provide all 3? Or just one? Given that options
1 and 2 need option 3, and 2 is just an extension of 1, it seems
like we reasonably could provide all 3.
We should provide all three. My point is that you could easily
implement 1 and 2 in a way that 3 is not really an option to the
user. To make 3 work you probably have to have the design goal
'toolset' in mind when implementing 1 and 2.
By 'out-of-the-box', do you mean that the core or a plugin would
provide this?
With out-of-the-box I mean a framework plus pre-configured by
conventions.
It feels like it belongs in a release management plugin, so that I
can use it both with the java/groovy/war plugins or separately with
my own plugins (and conversely, I can use my own release management
plugin with the java/groovy/war plugins)
Definitely.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
