hi phil, >>I was waiting for a plugin mechanism that could handle plugin dependencies...
a proper plugin-mechanism is preconditions for community-participation and community-participation is a big asset. regarding community-participation via plugins, grails can be taken as a successful model. grails differenciates core-plugins from community-plugins. few community-plugins are supported by SpringSource but may grow up so that they become supported- or even core-plugins. a typical example are the security-plugins. community-plugins are like a lab. and in that sense the publication of your plugin-source must be welcome by gradle even if release-build is a post 1.0 item on the road-map. on the long run there should be a process that defines how to publish and maintain community-plugins and keep them separate from the core. gruesse h. denk Phil Messenger wrote: > > I've written a release plugin for work that does most of this, though it's > fairly closely tied into our workflow. I had a look at the work required > to make it "generic" back around the release of Gradle 0.5. The biggest > issue is supporting various SCM's and upload mechanisms. The maven SCM and > "wagon" plugins are pretty decent, so we could use those. > > I didn't take things any further as I was waiting for a plugin mechanism > that could handle plugin dependencies... > > Incrementing version numbers etc. is pretty straight forward. We don't do > automatic snapshot dependency replacement - the plugin just refuses to do > a release in this case unless forced. > > Snapshot releases are just a slight modification of the general release > case - basically skipping the snapshto dependency check and release number > increment (unless desired). > > I could release the source for this as I did for the eclipse and > dependency plugins if there's any interest. > > Phil. > > > Helmut Denk wrote: >> >> hi carsten, >> >> looks like the right time for discussions about >> this topic. >> >> the step-list you pointed to, gives a good overview >> of what has to be done during the release-process. >> >> points that come to my mind are: >> >> - scm-abstraction that allows to update, commit, >> branch, tag against most common scm (git, svn) >> >> - snapshot-handling >> >> - manage state transitions in the project-workspace (replace >> snapshot-dependencys, increment revision-id) >> >> - manage state transitions of artifacts (qa -> production) >> >> one important thing that seems not to be adressed by the >> maven-release-process: patches, quick-fixes. >> >> gradle will be a solid ground for a customizable release-process. >> it should not be to difficult, to setup a first shot release-plugin >> on base of todays gradle. maybe one that addresses git only. >> >> have a nice day >> >> > > -- View this message in context: http://www.nabble.com/Functionallity-a%27la-maven-release-plugin--tp25802972p25867250.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
