Continuum

release using mvn release plugin

Details

  • Type: Improvement Improvement
  • Status: Reopened Reopened
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.1
  • Fix Version/s: Backlog
  • Component/s: Release
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

I think that the release process should use the release plugin rather than the maven-release classes directly.

Actually, it's possible to choose the maven installation to execute the compilation in continuum, BUT the maven version used to release a project can't be changed because of the compilation/runtime dependency of continuum-release.

Also, if I configure the release plugin in pom.xml (for default values or to use a specific version of the plugin), this is ignored by continuum.

What do you think about externalize the release execution using external command line as you do to execute scheduled goals ? Is there any blocker issue so that it's not possible ?

Issue Links

This issue relates to:
CONTINUUM-1572 Release should support Build Environments (formerly called Continuum Profiles) Major Closed
CONTINUUM-2028 Continuum release prepare should use maven-release-plugin scmCommentPrefix configuration in pom Major Closed
This issue is related to:
CONTINUUM-2364 Partial release plugin configuration loses the defaults for unconfigured items Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

I think the answer here is that we need to be able to use the configuration from the POM (which I believe is already filed). Executing the release plugin externally doesn't seem to make much sense - you'd get the same functionality from the classes. You'd also lose the ability to monitor it's progress.

Show
Brett Porter added a comment - I think the answer here is that we need to be able to use the configuration from the POM (which I believe is already filed). Executing the release plugin externally doesn't seem to make much sense - you'd get the same functionality from the classes. You'd also lose the ability to monitor it's progress.
Hide
Permalink
Benoit Decherf added a comment -

If I do it that way I will have a diferent behaviour between builds and the release.
I won't be able to choose the version of the JDK to use (It seems that on some case, the behaviour is diferent between jdk1.4 and jdk1.6 with target and source 1.4), I won't be able to upgrade easily maven (I will have to do an internal version of continuum to upgrade the jars), and I won't be able to pass variable that are defined in the profile.

And in case of an error, it's easier to check the output of the release plugin than just see the failed phase and a short description of the problem.

The actual ways continuum make release is useless for us, and we will have to make a own release system If you are not interested with this feature.
I'm finishing a first version of the release system we need (integrated to continuum). I will give you a sample URL at the end of the week to know what you think about it and if it will be possible to integrate it to continuum.

Show
Benoit Decherf added a comment - If I do it that way I will have a diferent behaviour between builds and the release. I won't be able to choose the version of the JDK to use (It seems that on some case, the behaviour is diferent between jdk1.4 and jdk1.6 with target and source 1.4), I won't be able to upgrade easily maven (I will have to do an internal version of continuum to upgrade the jars), and I won't be able to pass variable that are defined in the profile. And in case of an error, it's easier to check the output of the release plugin than just see the failed phase and a short description of the problem. The actual ways continuum make release is useless for us, and we will have to make a own release system If you are not interested with this feature. I'm finishing a first version of the release system we need (integrated to continuum). I will give you a sample URL at the end of the week to know what you think about it and if it will be possible to integrate it to continuum.
Hide
Permalink
Brett Porter added a comment -

there is also an issue for using the different profiles in a release. Your problem is real - I would just like to see the release system fix the real issues at hand than delegate it all.

But it's great that you are working on an alternative - we look forward to seeing it!

Show
Brett Porter added a comment - there is also an issue for using the different profiles in a release. Your problem is real - I would just like to see the release system fix the real issues at hand than delegate it all. But it's great that you are working on an alternative - we look forward to seeing it!
Hide
Permalink
Brett Porter added a comment -

reopening for the alternative

Show
Brett Porter added a comment - reopening for the alternative
Hide
Permalink
PeteJohlie added a comment -

I am having the same issue with continuum and the release button.
It does not behave like the plugin and my pom is not handled the same.
Setting up a goal as follows:
POM filename: pom.xml
Goals: release:prepare release:perform -X -e -Ptst
Arguments: --batch-mode --non-recursive
Build Fresh (Run always a clean checkout instead of an SCM update)
Always Build
Is it default?
Schedule: Never DEFAULT_SCHEDULE
Profile: vm-tst-apps
Type: maven2
Description:

We have modified the <preparationGoals> of the release plugin to use cargo:deploy for some profiles
I can get that to work in continuum when using a specific build definition. Our only problem is that we do not get the chance to provide release/tag/etc values.

However, when using the release button (which allows us to provide the values), the variables do not work.
Why doesn't the release button just act like a cmd-line invocation of the mvn release:prepare?
thanks

Show
PeteJohlie added a comment - I am having the same issue with continuum and the release button. It does not behave like the plugin and my pom is not handled the same. Setting up a goal as follows: POM filename: pom.xml Goals: release:prepare release:perform -X -e -Ptst Arguments: --batch-mode --non-recursive Build Fresh (Run always a clean checkout instead of an SCM update) Always Build Is it default? Schedule: Never DEFAULT_SCHEDULE Profile: vm-tst-apps Type: maven2 Description: We have modified the <preparationGoals> of the release plugin to use cargo:deploy for some profiles I can get that to work in continuum when using a specific build definition. Our only problem is that we do not get the chance to provide release/tag/etc values. However, when using the release button (which allows us to provide the values), the variables do not work. Why doesn't the release button just act like a cmd-line invocation of the mvn release:prepare? thanks
Hide
Permalink
Benoit Decherf added a comment -

Here is my alternative.
There are several changes:

  • I add the possibility to make the release from a previous tag/revision (and create a branch from this tag to create the release).
  • It is now possible to release all/several projects of a group. (The projects doesn't need to have the same parent).
  • The release is done by an external maven process.
  • Profiles are supported.

This still not support the mutliple project. I will work to add it.

This is what I like to have in continuum. Please give me some feedback about it.

Show
Benoit Decherf added a comment - Here is my alternative. There are several changes:
  • I add the possibility to make the release from a previous tag/revision (and create a branch from this tag to create the release).
  • It is now possible to release all/several projects of a group. (The projects doesn't need to have the same parent).
  • The release is done by an external maven process.
  • Profiles are supported.
This still not support the mutliple project. I will work to add it. This is what I like to have in continuum. Please give me some feedback about it.
Hide
Permalink
Brett Porter added a comment -

I'll review this for the next version - thanks!

Show
Brett Porter added a comment - I'll review this for the next version - thanks!

People

Vote (5)
Watch (8)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.