Functionallity a'la maven release plugin?

[oland]

Hello

How would something like the functionality provided by the maven release plugin (http://maven.apache.org/plugins/maven-release-plugin/introduction.html) be done in gradle?

The only thing I can think off is using ant's eg cvs target but that seems kind of "primitive".

Thanks
Carsten

[Helmut Denk]

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

[Phil Messenger]

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

[Helmut Denk]

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


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

[Helmut Denk]

let me correct myself a little bit:

Helmut Denk wrote:

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.

i think the gradle-team should consider to make
this part of 1.0.