Re: Maven Release Plugin - Reopen MRELEASE-282

[Slawomir Jaranowski]

Hi,

Reopened. PR are welcome.

pt., 17 cze 2022 o 18:08 Pablo Caraballo Llorente 
napisał(a):

> Hello.
>
> As a user of the maven-release-plugin, I find that the issue MRELEASE-282
>  is an improvement
> that
> would be useful to improve the configuration of the prepare and perform
> goals.
>
> In my specific case, I cannot configure different arguments for each goal
> given that both share the same property, and that the 1st one generates a
> release.properties file that overrides the configuration set in the pom
> file. Even more specifically, I would like to skip the tests compilation
> and execution during the perform goal, as this job is already done in the
> preparation, and adds a lot of overhead to the release pipeline
> (configuring the specific goals to run in the perform isn't suitable, as
> they may vary at any point).
>
> If you are aware of a better way of doing this rather than implementing the
> feature, please let me know. If that is the case, maybe it's worth
> mentioning it in the documentation site.
>
> Thanks and sorry for the noise.
>


-- 
Sławomir Jaranowski

Re: Maven Release Plugin 3.0.0-M6

[Michael Osipov]

Guys,

let me know when you are done with all issues for M6, I will happily do 
the release for the community.


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Hervé BOUTEMY]

MRELEASE-1087 is a massive cleanup in terms of quantity of code, but it's not 
really functional changes: just get rid of old Plexus APIs and associated 
tricks to make our life easier. I'm confident our ITs would catch issues at 
that level.

on my own side, having feedback on 
https://maven.apache.org/maven-release-archives/maven-release-LATEST/maven-release-plugin/upgrade.html
 would be nice

yes, let's focus and do the release soon

Le vendredi 6 mai 2022, 04:05:15 CEST Olivier Lamy a écrit :
> Nice it looks like the call for release suddenly generates a lot of
> activity for this plugin :)
> but how long will it take to get all those issues done?
> Because at the start it was just a bug fix release and now we have a lot of
> changes coming.
> Can we just cut a release and then look after all of those other changes?
> because this one looks very massive change...
> https://issues.apache.org/jira/browse/MRELEASE-1087
> 
> On Thu, 5 May 2022 at 20:56, Karl Heinz Marbaise  wrote:
> > Hi,
> > 
> > I would like to enhance the list with this one:
> > 
> > https://issues.apache.org/jira/browse/MRELEASE-1079
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> > On 05.05.22 08:37, Hervé BOUTEMY wrote:
> > > https://issues.apache.org/jira/projects/MRELEASE/versions/12351336
> > > 3 issues to finish:
> > > https://issues.apache.org/jira/browse/MRELEASE-955
> > > https://issues.apache.org/jira/browse/MRELEASE-1084
> > > https://issues.apache.org/jira/browse/MRELEASE-1087
> > > 
> > > Le mercredi 4 mai 2022, 14:51:21 CEST Samuel Le Berrigaud a écrit :
> > >> Hello,
> > >> 
> > >> any news on this? Without putting any pressure, I'd just like to be
> > >> able to tell whether I should wait a few days or whether I should plan
> > >> around having an M6.
> > >> 
> > >> Thanks,
> > >> SaM
> > >> 
> > >> On Tue, Apr 26, 2022 at 2:36 PM Olivier Lamy  wrote:
> > >>> Hi
> > >>> It looks there is a plan for early (ish) next week
> > >>> 
> > >>> cheers
> > >>> Olivier
> > >>> 
> > >>> On Tue, 26 Apr 2022 at 9:48 pm, Samuel Le Berrigaud <
> > 
> > s...@leberrigaud.org>
> > 
> > >>> wrote:
> >  Hello devs,
> >  
> >  I'd just like to get an idea of when a potential 3.0.0-M6 of the
> >  maven-release-plugin might happen.
> >  
> >  I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for
> >  the
> >  quick PR & merge. And now, obviously, I would love to be able to use
> >  a
> >  regular build of the plugin.
> >  
> >  Thanks for your help,
> >  SaM
> >  
> >  (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> >  
> >  -
> >  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >  For additional commands, e-mail: dev-h...@maven.apache.org
> > >> 
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Olivier Lamy]

Nice it looks like the call for release suddenly generates a lot of
activity for this plugin :)
but how long will it take to get all those issues done?
Because at the start it was just a bug fix release and now we have a lot of
changes coming.
Can we just cut a release and then look after all of those other changes?
because this one looks very massive change...
https://issues.apache.org/jira/browse/MRELEASE-1087


On Thu, 5 May 2022 at 20:56, Karl Heinz Marbaise  wrote:

> Hi,
>
> I would like to enhance the list with this one:
>
> https://issues.apache.org/jira/browse/MRELEASE-1079
>
> Kind regards
> Karl Heinz Marbaise
>
> On 05.05.22 08:37, Hervé BOUTEMY wrote:
> > https://issues.apache.org/jira/projects/MRELEASE/versions/12351336
> > 3 issues to finish:
> > https://issues.apache.org/jira/browse/MRELEASE-955
> > https://issues.apache.org/jira/browse/MRELEASE-1084
> > https://issues.apache.org/jira/browse/MRELEASE-1087
> >
> > Le mercredi 4 mai 2022, 14:51:21 CEST Samuel Le Berrigaud a écrit :
> >> Hello,
> >>
> >> any news on this? Without putting any pressure, I'd just like to be
> >> able to tell whether I should wait a few days or whether I should plan
> >> around having an M6.
> >>
> >> Thanks,
> >> SaM
> >>
> >> On Tue, Apr 26, 2022 at 2:36 PM Olivier Lamy  wrote:
> >>> Hi
> >>> It looks there is a plan for early (ish) next week
> >>>
> >>> cheers
> >>> Olivier
> >>>
> >>> On Tue, 26 Apr 2022 at 9:48 pm, Samuel Le Berrigaud <
> s...@leberrigaud.org>
> >>>
> >>> wrote:
>  Hello devs,
> 
>  I'd just like to get an idea of when a potential 3.0.0-M6 of the
>  maven-release-plugin might happen.
> 
>  I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
>  quick PR & merge. And now, obviously, I would love to be able to use a
>  regular build of the plugin.
> 
>  Thanks for your help,
>  SaM
> 
>  (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Release Plugin 3.0.0-M6

[Karl Heinz Marbaise]

Hi,

I would like to enhance the list with this one:

https://issues.apache.org/jira/browse/MRELEASE-1079

Kind regards
Karl Heinz Marbaise

On 05.05.22 08:37, Hervé BOUTEMY wrote:

https://issues.apache.org/jira/projects/MRELEASE/versions/12351336
3 issues to finish:
https://issues.apache.org/jira/browse/MRELEASE-955
https://issues.apache.org/jira/browse/MRELEASE-1084
https://issues.apache.org/jira/browse/MRELEASE-1087

Le mercredi 4 mai 2022, 14:51:21 CEST Samuel Le Berrigaud a écrit :

Hello,

any news on this? Without putting any pressure, I'd just like to be
able to tell whether I should wait a few days or whether I should plan
around having an M6.

Thanks,
SaM

On Tue, Apr 26, 2022 at 2:36 PM Olivier Lamy  wrote:

Hi
It looks there is a plan for early (ish) next week

cheers
Olivier

On Tue, 26 Apr 2022 at 9:48 pm, Samuel Le Berrigaud 

wrote:

Hello devs,

I'd just like to get an idea of when a potential 3.0.0-M6 of the
maven-release-plugin might happen.

I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
quick PR & merge. And now, obviously, I would love to be able to use a
regular build of the plugin.

Thanks for your help,
SaM

(1) https://issues.apache.org/jira/browse/MRELEASE-1022

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Hervé BOUTEMY]

https://issues.apache.org/jira/projects/MRELEASE/versions/12351336
3 issues to finish:
https://issues.apache.org/jira/browse/MRELEASE-955
https://issues.apache.org/jira/browse/MRELEASE-1084
https://issues.apache.org/jira/browse/MRELEASE-1087

Le mercredi 4 mai 2022, 14:51:21 CEST Samuel Le Berrigaud a écrit :
> Hello,
> 
> any news on this? Without putting any pressure, I'd just like to be
> able to tell whether I should wait a few days or whether I should plan
> around having an M6.
> 
> Thanks,
> SaM
> 
> On Tue, Apr 26, 2022 at 2:36 PM Olivier Lamy  wrote:
> > Hi
> > It looks there is a plan for early (ish) next week
> > 
> > cheers
> > Olivier
> > 
> > On Tue, 26 Apr 2022 at 9:48 pm, Samuel Le Berrigaud 
> > 
> > wrote:
> > > Hello devs,
> > > 
> > > I'd just like to get an idea of when a potential 3.0.0-M6 of the
> > > maven-release-plugin might happen.
> > > 
> > > I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> > > quick PR & merge. And now, obviously, I would love to be able to use a
> > > regular build of the plugin.
> > > 
> > > Thanks for your help,
> > > SaM
> > > 
> > > (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Samuel Le Berrigaud]

Hello,

any news on this? Without putting any pressure, I'd just like to be
able to tell whether I should wait a few days or whether I should plan
around having an M6.

Thanks,
SaM

On Tue, Apr 26, 2022 at 2:36 PM Olivier Lamy  wrote:
>
> Hi
> It looks there is a plan for early (ish) next week
>
> cheers
> Olivier
>
> On Tue, 26 Apr 2022 at 9:48 pm, Samuel Le Berrigaud 
> wrote:
>
> > Hello devs,
> >
> > I'd just like to get an idea of when a potential 3.0.0-M6 of the
> > maven-release-plugin might happen.
> >
> > I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> > quick PR & merge. And now, obviously, I would love to be able to use a
> > regular build of the plugin.
> >
> > Thanks for your help,
> > SaM
> >
> > (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Hervé BOUTEMY]

IIUC, the key aspect we need to solve to remove that milestone aspect is
https://issues.apache.org/jira/browse/MRELEASE-955 (and relatives)

if someone else knows other topics, please share, so we can focus

Regards,

Hervé

Le mardi 26 avril 2022, 21:14:39 CEST Jeff Jensen a écrit :
> M is for Milestone, an incremental release towards the eventual final
> release considered early production ready but incomplete for full planned
> features and implementation.
> 
> On Tue, Apr 26, 2022 at 2:10 PM Gary Gregory  wrote:
> > Can someone explain the M release meaning? Is it an alpha release? A beta
> > version? Is it production ready? Does it depend on the plugin (please say
> > no)?
> > 
> > Gary
> > 
> > On Tue, Apr 26, 2022, 07:49 Samuel Le Berrigaud 
> > 
> > wrote:
> > > Hello devs,
> > > 
> > > I'd just like to get an idea of when a potential 3.0.0-M6 of the
> > > maven-release-plugin might happen.
> > > 
> > > I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> > > quick PR & merge. And now, obviously, I would love to be able to use a
> > > regular build of the plugin.
> > > 
> > > Thanks for your help,
> > > SaM
> > > 
> > > (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> > > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Michael Osipov]

Am 2022-04-26 um 21:14 schrieb Jeff Jensen:

M is for Milestone, an incremental release towards the eventual final
release considered early production ready but incomplete for full planned
features and implementation.


To the point!

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin 3.0.0-M6

[Jeff Jensen]

M is for Milestone, an incremental release towards the eventual final
release considered early production ready but incomplete for full planned
features and implementation.


On Tue, Apr 26, 2022 at 2:10 PM Gary Gregory  wrote:

> Can someone explain the M release meaning? Is it an alpha release? A beta
> version? Is it production ready? Does it depend on the plugin (please say
> no)?
>
> Gary
>
> On Tue, Apr 26, 2022, 07:49 Samuel Le Berrigaud 
> wrote:
>
> > Hello devs,
> >
> > I'd just like to get an idea of when a potential 3.0.0-M6 of the
> > maven-release-plugin might happen.
> >
> > I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> > quick PR & merge. And now, obviously, I would love to be able to use a
> > regular build of the plugin.
> >
> > Thanks for your help,
> > SaM
> >
> > (1) https://issues.apache.org/jira/browse/MRELEASE-1022
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven Release Plugin 3.0.0-M6

[Gary Gregory]

Can someone explain the M release meaning? Is it an alpha release? A beta
version? Is it production ready? Does it depend on the plugin (please say
no)?

Gary

On Tue, Apr 26, 2022, 07:49 Samuel Le Berrigaud  wrote:

> Hello devs,
>
> I'd just like to get an idea of when a potential 3.0.0-M6 of the
> maven-release-plugin might happen.
>
> I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> quick PR & merge. And now, obviously, I would love to be able to use a
> regular build of the plugin.
>
> Thanks for your help,
> SaM
>
> (1) https://issues.apache.org/jira/browse/MRELEASE-1022
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Release Plugin 3.0.0-M6

[Olivier Lamy]

Hi
It looks there is a plan for early (ish) next week

cheers
Olivier

On Tue, 26 Apr 2022 at 9:48 pm, Samuel Le Berrigaud 
wrote:

> Hello devs,
>
> I'd just like to get an idea of when a potential 3.0.0-M6 of the
> maven-release-plugin might happen.
>
> I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> quick PR & merge. And now, obviously, I would love to be able to use a
> regular build of the plugin.
>
> Thanks for your help,
> SaM
>
> (1) https://issues.apache.org/jira/browse/MRELEASE-1022
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven release plugin

[Robert Scholte]

My current proposal:

the start situation is a folder containing several checked out projects.
the folder contains an aggregator pom, which is NOT under version control.

release:prepare should start as normal, but it should end with a  
commit+tag+commit on every checked out folder.


release:perform uses target/checkout, where you copy the aggregator-pom.
And you also check out the projects by tag. Ensure they're using the same  
directory-name.


That should be about it. The wording is probably easier compared to the  
implementation.


Have a look at project-utils[1]. It should help with determining what kind  
of project every pom is.
It hasn't been released yet, but it was written to help the  
maven-release-plugin


I hope this makes sense,
Robert

[1] http://svn.apache.org/repos/asf/maven/shared/trunk/maven-project-utils/

On Tue, 21 Nov 2017 10:31:07 +0100, Petar Tahchiev   
wrote:



Hi Robert,
i'll give it a try. Can you please summarize what needs to be done, or
perhaps point me the right direction?

2017-11-20 21:32 GMT+02:00 Robert Scholte :


Hi Petar,

would be great if you could pick this up.
There's enough work I want to finish first, maven-release-plugin is not
one of them right now.

thanks,
Robert


On Mon, 20 Nov 2017 18:38:56 +0100, Petar Tahchiev  


wrote:

Hi Robert,


any updates on the release-aggregator? Is there anything I can do to  
help?


2017-06-27 22:43 GMT+03:00 Robert Scholte :

Hi Petar,


This is a clear sign that ${project} should not be used to resolve  
this.
Instead the pom should be analyzed again and if there's a system  
property

matching the parent, it should be replaced before loading the parent.
That'll require quite some new lines of code :)
The suggested release-aggregator will require this same feature, so
sooner
or later this must be fixed.

Robert


On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev <
paranoia...@gmail.com>
wrote:

Hey guys,



my pull-request worked fine to not show the prompt to specify a  
version.

However, it fails to update snapshot dependency versions when you
resolve
the parent to a concrete version.
Particularly in my case:


[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]
   -module1 - platform:module1
   -module2 - platform:module2
     .
   - moduleN- platform:moduleN

The [BOM] defines in dependencyManagement section all the versions of
the
modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
without
specifying a version. During release what I do is I first release the
[BOM], then release the [PLATFORM] and up to here I see no problems.  
But
then I try to release the DEMO_STORE] and even though I specify on  
the

command line the version of the parent [BOM]:

-Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
-Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT


it still asks me for versions of dependencies which are specified in  
the
released [BOM]. I tried patching the code and specifying a new  
version

of
the parent

project.getParentArtifact().setVersion("1.5.2.RELEASE")

just to see if it works, but the problem is that the dependencies in  
the

project are already resolved: when I call project.getDependencies() I
get
the SNAPSHOT versions.

Is there any way to reload the project model after I specify a new
parentVersion()? So that It understands the [BOM] is no longer a
snapshot
version.

Thanks

2017-06-25 12:11 GMT+03:00 Robert Scholte :

MRELEASE-362[1] is probably the matching issue.


Be aware that some are talking about tagging every module. In most
situations I don't like that. If the structure is hierarchical and  
the

root
is tagged, then all the modules are already tagged. All tags must be
checked out during release:perform, keep that in mind.
I see options with a flat structure and with the release-aggregator.

Robert

[1] https://issues.apache.org/jira/browse/MRELEASE-362


On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <
paranoia...@gmail.com>
wrote:

Hi Paul,



I think you misunderstood. The [BOM] is a separate project and the
[PLATFORM] and [DEMO_STORE] are also separate projects, both of  
which

declare as their parent the [BOM].

@Robert: I have added the test-case:
https://github.com/apache/maven-release/pull/18/commits/
Release-aggregator is exactly what's missing. Is there an issue I  
can

subscribe and track?


2017-06-24 14:15 GMT+03:00 Robert Scholte :

What we're still missing is a release-aggregator, which can release

multiple release-roots at once. That would probably be the  
preferred

fix,
the suggested patch is just an easy work-around.
It is still on my todo-list.

Robert


On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant  

Re: Maven release plugin

[Petar Tahchiev]

Hi Robert,
i'll give it a try. Can you please summarize what needs to be done, or
perhaps point me the right direction?

2017-11-20 21:32 GMT+02:00 Robert Scholte :

> Hi Petar,
>
> would be great if you could pick this up.
> There's enough work I want to finish first, maven-release-plugin is not
> one of them right now.
>
> thanks,
> Robert
>
>
> On Mon, 20 Nov 2017 18:38:56 +0100, Petar Tahchiev 
> wrote:
>
> Hi Robert,
>>
>> any updates on the release-aggregator? Is there anything I can do to help?
>>
>> 2017-06-27 22:43 GMT+03:00 Robert Scholte :
>>
>> Hi Petar,
>>>
>>> This is a clear sign that ${project} should not be used to resolve this.
>>> Instead the pom should be analyzed again and if there's a system property
>>> matching the parent, it should be replaced before loading the parent.
>>> That'll require quite some new lines of code :)
>>> The suggested release-aggregator will require this same feature, so
>>> sooner
>>> or later this must be fixed.
>>>
>>> Robert
>>>
>>>
>>> On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev <
>>> paranoia...@gmail.com>
>>> wrote:
>>>
>>> Hey guys,
>>>

 my pull-request worked fine to not show the prompt to specify a version.
 However, it fails to update snapshot dependency versions when you
 resolve
 the parent to a concrete version.
 Particularly in my case:


 [BOM]
  /\
  [PLATFORM]  [DEMO_STORE]
-module1 - platform:module1
-module2 - platform:module2
  .
- moduleN- platform:moduleN

 The [BOM] defines in dependencyManagement section all the versions of
 the
 modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
 without
 specifying a version. During release what I do is I first release the
 [BOM], then release the [PLATFORM] and up to here I see no problems. But
 then I try to release the DEMO_STORE] and even though I specify on the
 command line the version of the parent [BOM]:

 -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
 -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT


 it still asks me for versions of dependencies which are specified in the
 released [BOM]. I tried patching the code and specifying a new version
 of
 the parent

 project.getParentArtifact().setVersion("1.5.2.RELEASE")

 just to see if it works, but the problem is that the dependencies in the
 project are already resolved: when I call project.getDependencies() I
 get
 the SNAPSHOT versions.

 Is there any way to reload the project model after I specify a new
 parentVersion()? So that It understands the [BOM] is no longer a
 snapshot
 version.

 Thanks

 2017-06-25 12:11 GMT+03:00 Robert Scholte :

 MRELEASE-362[1] is probably the matching issue.

> Be aware that some are talking about tagging every module. In most
> situations I don't like that. If the structure is hierarchical and the
> root
> is tagged, then all the modules are already tagged. All tags must be
> checked out during release:perform, keep that in mind.
> I see options with a flat structure and with the release-aggregator.
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/MRELEASE-362
>
>
> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <
> paranoia...@gmail.com>
> wrote:
>
> Hi Paul,
>
>
>> I think you misunderstood. The [BOM] is a separate project and the
>> [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
>> declare as their parent the [BOM].
>>
>> @Robert: I have added the test-case:
>> https://github.com/apache/maven-release/pull/18/commits/
>> Release-aggregator is exactly what's missing. Is there an issue I can
>> subscribe and track?
>>
>>
>> 2017-06-24 14:15 GMT+03:00 Robert Scholte :
>>
>> What we're still missing is a release-aggregator, which can release
>>
>> multiple release-roots at once. That would probably be the preferred
>>> fix,
>>> the suggested patch is just an easy work-around.
>>> It is still on my todo-list.
>>>
>>> Robert
>>>
>>>
>>> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant 
>>> wrote:
>>>
>>> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm
>>> not
>>>
>>> sure if 'BOM' should mean anything to me) that includes only
>>> 'platform'
>>>
 as
 a child module.

mvn release:prepare -PplatformOnly # etc

 Later when you're ready to do 

Re: Maven release plugin

[Robert Scholte]

Hi Petar,

would be great if you could pick this up.
There's enough work I want to finish first, maven-release-plugin is not  
one of them right now.


thanks,
Robert

On Mon, 20 Nov 2017 18:38:56 +0100, Petar Tahchiev   
wrote:



Hi Robert,

any updates on the release-aggregator? Is there anything I can do to  
help?


2017-06-27 22:43 GMT+03:00 Robert Scholte :


Hi Petar,

This is a clear sign that ${project} should not be used to resolve this.
Instead the pom should be analyzed again and if there's a system  
property

matching the parent, it should be replaced before loading the parent.
That'll require quite some new lines of code :)
The suggested release-aggregator will require this same feature, so  
sooner

or later this must be fixed.

Robert


On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev  


wrote:

Hey guys,


my pull-request worked fine to not show the prompt to specify a  
version.
However, it fails to update snapshot dependency versions when you  
resolve

the parent to a concrete version.
Particularly in my case:


[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]
   -module1 - platform:module1
   -module2 - platform:module2
     .
   - moduleN- platform:moduleN

The [BOM] defines in dependencyManagement section all the versions of  
the

modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
without
specifying a version. During release what I do is I first release the
[BOM], then release the [PLATFORM] and up to here I see no problems.  
But

then I try to release the DEMO_STORE] and even though I specify on the
command line the version of the parent [BOM]:

-Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
-Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT


it still asks me for versions of dependencies which are specified in  
the
released [BOM]. I tried patching the code and specifying a new version  
of

the parent

project.getParentArtifact().setVersion("1.5.2.RELEASE")

just to see if it works, but the problem is that the dependencies in  
the
project are already resolved: when I call project.getDependencies() I  
get

the SNAPSHOT versions.

Is there any way to reload the project model after I specify a new
parentVersion()? So that It understands the [BOM] is no longer a  
snapshot

version.

Thanks

2017-06-25 12:11 GMT+03:00 Robert Scholte :

MRELEASE-362[1] is probably the matching issue.

Be aware that some are talking about tagging every module. In most
situations I don't like that. If the structure is hierarchical and the
root
is tagged, then all the modules are already tagged. All tags must be
checked out during release:perform, keep that in mind.
I see options with a flat structure and with the release-aggregator.

Robert

[1] https://issues.apache.org/jira/browse/MRELEASE-362


On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <
paranoia...@gmail.com>
wrote:

Hi Paul,



I think you misunderstood. The [BOM] is a separate project and the
[PLATFORM] and [DEMO_STORE] are also separate projects, both of which
declare as their parent the [BOM].

@Robert: I have added the test-case:
https://github.com/apache/maven-release/pull/18/commits/
Release-aggregator is exactly what's missing. Is there an issue I can
subscribe and track?


2017-06-24 14:15 GMT+03:00 Robert Scholte :

What we're still missing is a release-aggregator, which can release


multiple release-roots at once. That would probably be the preferred
fix,
the suggested patch is just an easy work-around.
It is still on my todo-list.

Robert


On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant 
wrote:

Easy to fix.  Have a profile 'platformOnly' in the root module (I'm  
not


sure if 'BOM' should mean anything to me) that includes only  
'platform'

as
a child module.

   mvn release:prepare -PplatformOnly # etc

Later when you're ready to do the demo store release, use another
(from
root):

   mvn release:prepare -PdemoOnly # etc

Of course, you man not need to stuff demo in your
Artifactory/Nexus/etc
in
which case just do your deploy fu after an 'install' w/o the  
release

plugin
involved or that second profile.

- Paul


On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev <
paranoia...@gmail.com>
wrote:

Hey guys,



I'm facing a number of challenges when I release the project at my
company.
Here's my setup:

[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]

I have a master BOM project which holds all the version as defined
properties. This BOM is the parent to two other projects -  
[PLATFORM]

and
[DEMO_STORE], The [PLATFORM] is a project with more than 60  
modules

inside,
and the [DEMO_STORE] is a project that declares those modules 

Re: Maven release plugin

[Petar Tahchiev]

Hi Robert,

any updates on the release-aggregator? Is there anything I can do to help?

2017-06-27 22:43 GMT+03:00 Robert Scholte :

> Hi Petar,
>
> This is a clear sign that ${project} should not be used to resolve this.
> Instead the pom should be analyzed again and if there's a system property
> matching the parent, it should be replaced before loading the parent.
> That'll require quite some new lines of code :)
> The suggested release-aggregator will require this same feature, so sooner
> or later this must be fixed.
>
> Robert
>
>
> On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev 
> wrote:
>
> Hey guys,
>>
>> my pull-request worked fine to not show the prompt to specify a version.
>> However, it fails to update snapshot dependency versions when you resolve
>> the parent to a concrete version.
>> Particularly in my case:
>>
>>
>> [BOM]
>>  /\
>>  [PLATFORM]  [DEMO_STORE]
>>-module1 - platform:module1
>>-module2 - platform:module2
>>  .
>>- moduleN- platform:moduleN
>>
>> The [BOM] defines in dependencyManagement section all the versions of the
>> modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
>> without
>> specifying a version. During release what I do is I first release the
>> [BOM], then release the [PLATFORM] and up to here I see no problems. But
>> then I try to release the DEMO_STORE] and even though I specify on the
>> command line the version of the parent [BOM]:
>>
>> -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
>> -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT
>>
>>
>> it still asks me for versions of dependencies which are specified in the
>> released [BOM]. I tried patching the code and specifying a new version of
>> the parent
>>
>> project.getParentArtifact().setVersion("1.5.2.RELEASE")
>>
>> just to see if it works, but the problem is that the dependencies in the
>> project are already resolved: when I call project.getDependencies() I get
>> the SNAPSHOT versions.
>>
>> Is there any way to reload the project model after I specify a new
>> parentVersion()? So that It understands the [BOM] is no longer a snapshot
>> version.
>>
>> Thanks
>>
>> 2017-06-25 12:11 GMT+03:00 Robert Scholte :
>>
>> MRELEASE-362[1] is probably the matching issue.
>>> Be aware that some are talking about tagging every module. In most
>>> situations I don't like that. If the structure is hierarchical and the
>>> root
>>> is tagged, then all the modules are already tagged. All tags must be
>>> checked out during release:perform, keep that in mind.
>>> I see options with a flat structure and with the release-aggregator.
>>>
>>> Robert
>>>
>>> [1] https://issues.apache.org/jira/browse/MRELEASE-362
>>>
>>>
>>> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <
>>> paranoia...@gmail.com>
>>> wrote:
>>>
>>> Hi Paul,
>>>

 I think you misunderstood. The [BOM] is a separate project and the
 [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
 declare as their parent the [BOM].

 @Robert: I have added the test-case:
 https://github.com/apache/maven-release/pull/18/commits/
 Release-aggregator is exactly what's missing. Is there an issue I can
 subscribe and track?


 2017-06-24 14:15 GMT+03:00 Robert Scholte :

 What we're still missing is a release-aggregator, which can release

> multiple release-roots at once. That would probably be the preferred
> fix,
> the suggested patch is just an easy work-around.
> It is still on my todo-list.
>
> Robert
>
>
> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant 
> wrote:
>
> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
>
> sure if 'BOM' should mean anything to me) that includes only 'platform'
>> as
>> a child module.
>>
>>mvn release:prepare -PplatformOnly # etc
>>
>> Later when you're ready to do the demo store release, use another
>> (from
>> root):
>>
>>mvn release:prepare -PdemoOnly # etc
>>
>> Of course, you man not need to stuff demo in your
>> Artifactory/Nexus/etc
>> in
>> which case just do your deploy fu after an 'install' w/o the release
>> plugin
>> involved or that second profile.
>>
>> - Paul
>>
>>
>> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev <
>> paranoia...@gmail.com>
>> wrote:
>>
>> Hey guys,
>>
>>
>>> I'm facing a number of challenges when I release the project at my
>>> company.
>>> Here's my setup:
>>>
>>> [BOM]
>>>  /\
>>>  [PLATFORM] 

Re: maven-release-plugin and signing artifacts

[Robert Scholte]

On Sat, 05 Aug 2017 22:05:22 +0200, Karl Heinz Marbaise  
 wrote:



Hi Robert,

On 04/08/17 10:55, Robert Scholte wrote:

Hi Karl Heinz,
 this can happen when the plugin configuration contains a fixed value  
for arguments, i.e

-Dkey=value
 If you want arguments to be extended via commandline argument, you  
need to do this:

 -Dkey=value ${arguments}
 




Thanks for your explanations...

So that means the configuration for the maven-release-plugin must be  
done before to support expanding the arguments like I expected..


So on the other hand the maven-release-plugin documentation for the  
arguments property:

http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html

say only: "Additional arguments to pass to the Maven executions,  
separated by spaces.".


So I have expected to simply set the arguments property and the  
additional parameters would have been added to the Maven invocation..


So this looks like a documentation issue from my point of view...what do  
you think ?


This has nothing to do with the maven-release-plugin, this is how  
parameter resolution works in general.

I think you've been fooled by plexus-utils release compared to asf, see:

https://github.com/apache/maven-pom/blob/trunk/asf/pom.xml#L89
https://github.com/apache/maven-pom/blob/trunk/asf/pom.xml#L212

Robert



Kind regards
Karl Heinz Marbaise




 Robert
 On Thu, 03 Aug 2017 19:57:10 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

I have tried to make a release of the plexus-utils and was faced with  
a problem...which I currently don't understand...


I have started the release with:

mvn -Darguments='-Dgpg.keyname=kama' release:prepare release:perform


So I thought the gpg.keyname property will be given to the called  
maven process which will run the part in prepare...but based on my  
tests it looks like it is not the case...cause the given "arguments"  
not transfered or added to the Maven sub process...(Ok I though might  
be caused by an older maven-release-plugin so I tested the same with  
the newest 2.5.3 but the result keeps the same)..


Has someone being faced with the same situation or Am I doing  
something wrong / Or misunderstand a thing here?


A work a round at the moment is to use:

mvn -DpreparationGoals='-Dgpg.keyname=kama clean verify'  
release:prepare release:perform


instead...but from my point of view this does not feel right...


Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin and signing artifacts

[Karl Heinz Marbaise]

Hi Robert,

On 04/08/17 10:55, Robert Scholte wrote:

Hi Karl Heinz,

this can happen when the plugin configuration contains a fixed value for 
arguments, i.e

-Dkey=value

If you want arguments to be extended via commandline argument, you need 
to do this:


-Dkey=value ${arguments}






Thanks for your explanations...

So that means the configuration for the maven-release-plugin must be 
done before to support expanding the arguments like I expected..


So on the other hand the maven-release-plugin documentation for the 
arguments property:

http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html

say only: "Additional arguments to pass to the Maven executions, 
separated by spaces.".


So I have expected to simply set the arguments property and the 
additional parameters would have been added to the Maven invocation..


So this looks like a documentation issue from my point of view...what do 
you think ?


Kind regards
Karl Heinz Marbaise





Robert

On Thu, 03 Aug 2017 19:57:10 +0200, Karl Heinz Marbaise 
 wrote:



Hi,

I have tried to make a release of the plexus-utils and was faced with 
a problem...which I currently don't understand...


I have started the release with:

mvn -Darguments='-Dgpg.keyname=kama' release:prepare release:perform


So I thought the gpg.keyname property will be given to the called 
maven process which will run the part in prepare...but based on my 
tests it looks like it is not the case...cause the given "arguments" 
not transfered or added to the Maven sub process...(Ok I though might 
be caused by an older maven-release-plugin so I tested the same with 
the newest 2.5.3 but the result keeps the same)..


Has someone being faced with the same situation or Am I doing 
something wrong / Or misunderstand a thing here?


A work a round at the moment is to use:

mvn -DpreparationGoals='-Dgpg.keyname=kama clean verify' 
release:prepare release:perform


instead...but from my point of view this does not feel right...


Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin and signing artifacts

[Robert Scholte]

Hi Karl Heinz,

this can happen when the plugin configuration contains a fixed value for  
arguments, i.e

-Dkey=value

If you want arguments to be extended via commandline argument, you need to  
do this:


-Dkey=value ${arguments}


   


Robert

On Thu, 03 Aug 2017 19:57:10 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

I have tried to make a release of the plexus-utils and was faced with a  
problem...which I currently don't understand...


I have started the release with:

mvn -Darguments='-Dgpg.keyname=kama' release:prepare release:perform


So I thought the gpg.keyname property will be given to the called maven  
process which will run the part in prepare...but based on my tests it  
looks like it is not the case...cause the given "arguments" not  
transfered or added to the Maven sub process...(Ok I though might be  
caused by an older maven-release-plugin so I tested the same with the  
newest 2.5.3 but the result keeps the same)..


Has someone being faced with the same situation or Am I doing something  
wrong / Or misunderstand a thing here?


A work a round at the moment is to use:

mvn -DpreparationGoals='-Dgpg.keyname=kama clean verify' release:prepare  
release:perform


instead...but from my point of view this does not feel right...


Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin

[Robert Scholte]

Hi Petar,

This is a clear sign that ${project} should not be used to resolve this.
Instead the pom should be analyzed again and if there's a system property  
matching the parent, it should be replaced before loading the parent.  
That'll require quite some new lines of code :)
The suggested release-aggregator will require this same feature, so sooner  
or later this must be fixed.


Robert

On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev   
wrote:



Hey guys,

my pull-request worked fine to not show the prompt to specify a version.
However, it fails to update snapshot dependency versions when you resolve
the parent to a concrete version.
Particularly in my case:


[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]
   -module1 - platform:module1
   -module2 - platform:module2
     .
   - moduleN- platform:moduleN

The [BOM] defines in dependencyManagement section all the versions of the
modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them  
without

specifying a version. During release what I do is I first release the
[BOM], then release the [PLATFORM] and up to here I see no problems. But
then I try to release the DEMO_STORE] and even though I specify on the
command line the version of the parent [BOM]:

-Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
-Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT


it still asks me for versions of dependencies which are specified in the
released [BOM]. I tried patching the code and specifying a new version of
the parent

project.getParentArtifact().setVersion("1.5.2.RELEASE")

just to see if it works, but the problem is that the dependencies in the
project are already resolved: when I call project.getDependencies() I get
the SNAPSHOT versions.

Is there any way to reload the project model after I specify a new
parentVersion()? So that It understands the [BOM] is no longer a snapshot
version.

Thanks

2017-06-25 12:11 GMT+03:00 Robert Scholte :


MRELEASE-362[1] is probably the matching issue.
Be aware that some are talking about tagging every module. In most
situations I don't like that. If the structure is hierarchical and the  
root

is tagged, then all the modules are already tagged. All tags must be
checked out during release:perform, keep that in mind.
I see options with a flat structure and with the release-aggregator.

Robert

[1] https://issues.apache.org/jira/browse/MRELEASE-362


On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev  


wrote:

Hi Paul,


I think you misunderstood. The [BOM] is a separate project and the
[PLATFORM] and [DEMO_STORE] are also separate projects, both of which
declare as their parent the [BOM].

@Robert: I have added the test-case:
https://github.com/apache/maven-release/pull/18/commits/
Release-aggregator is exactly what's missing. Is there an issue I can
subscribe and track?


2017-06-24 14:15 GMT+03:00 Robert Scholte :

What we're still missing is a release-aggregator, which can release
multiple release-roots at once. That would probably be the preferred  
fix,

the suggested patch is just an easy work-around.
It is still on my todo-list.

Robert


On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant 
wrote:

Easy to fix.  Have a profile 'platformOnly' in the root module (I'm  
not


sure if 'BOM' should mean anything to me) that includes only  
'platform'

as
a child module.

   mvn release:prepare -PplatformOnly # etc

Later when you're ready to do the demo store release, use another  
(from

root):

   mvn release:prepare -PdemoOnly # etc

Of course, you man not need to stuff demo in your  
Artifactory/Nexus/etc

in
which case just do your deploy fu after an 'install' w/o the release
plugin
involved or that second profile.

- Paul


On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev  


wrote:

Hey guys,



I'm facing a number of challenges when I release the project at my
company.
Here's my setup:

[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]

I have a master BOM project which holds all the version as defined
properties. This BOM is the parent to two other projects -  
[PLATFORM]

and
[DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
inside,
and the [DEMO_STORE] is a project that declares those modules as
dependencies.

Now what I want is to release all three from Jenkins. I can release  
the
[BOM] with no problems, then I start release of the [PLATFORM] and  
all

of a
sudden Jenkins blocks because Maven asks me on the command line if I
want
to resolve the SNAPSHOT dependencies (remember the parent of the
[PLATFORM]
is the [BOM] SNAPSHOT version).

So I created this issue https://issues.apache.org/jira

Re: Maven release plugin

[Jörg Schaible]

Petar Tahchiev wrote:

> Hey guys,
> 
> my pull-request worked fine to not show the prompt to specify a version.
> However, it fails to update snapshot dependency versions when you resolve
> the parent to a concrete version.
> Particularly in my case:
> 
> 
> [BOM]
>  /\
>  [PLATFORM]  [DEMO_STORE]
>-module1 - platform:module1
>-module2 - platform:module2
>  .
>- moduleN- platform:moduleN
> 
> The [BOM] defines in dependencyManagement section all the versions of the
> modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
> without specifying a version. During release what I do is I first release
> the
> [BOM], then release the [PLATFORM] and up to here I see no problems. But
> then I try to release the DEMO_STORE] and even though I specify on the
> command line the version of the parent [BOM]:
> 
> -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
> -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT
> 
> 
> it still asks me for versions of dependencies which are specified in the
> released [BOM].

What you can do as workaround is to add an empty relativePath element to the 
[DEMO_STORE] as a temporary modification just for the release. Annoying, but 
that should limit the multi-project to the subtree.

> I tried patching the code and specifying a new version of
> the parent
> 
> project.getParentArtifact().setVersion("1.5.2.RELEASE")
> 
> just to see if it works, but the problem is that the dependencies in the
> project are already resolved: when I call project.getDependencies() I get
> the SNAPSHOT versions.
> 
> Is there any way to reload the project model after I specify a new
> parentVersion()? So that It understands the [BOM] is no longer a snapshot
> version.

Dependency resolution is too early for such modifications.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin

[Petar Tahchiev]

Hey guys,

my pull-request worked fine to not show the prompt to specify a version.
However, it fails to update snapshot dependency versions when you resolve
the parent to a concrete version.
Particularly in my case:


[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]
   -module1 - platform:module1
   -module2 - platform:module2
     .
   - moduleN- platform:moduleN

The [BOM] defines in dependencyManagement section all the versions of the
modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them without
specifying a version. During release what I do is I first release the
[BOM], then release the [PLATFORM] and up to here I see no problems. But
then I try to release the DEMO_STORE] and even though I specify on the
command line the version of the parent [BOM]:

-Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
-Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT


it still asks me for versions of dependencies which are specified in the
released [BOM]. I tried patching the code and specifying a new version of
the parent

project.getParentArtifact().setVersion("1.5.2.RELEASE")

just to see if it works, but the problem is that the dependencies in the
project are already resolved: when I call project.getDependencies() I get
the SNAPSHOT versions.

Is there any way to reload the project model after I specify a new
parentVersion()? So that It understands the [BOM] is no longer a snapshot
version.

Thanks

2017-06-25 12:11 GMT+03:00 Robert Scholte :

> MRELEASE-362[1] is probably the matching issue.
> Be aware that some are talking about tagging every module. In most
> situations I don't like that. If the structure is hierarchical and the root
> is tagged, then all the modules are already tagged. All tags must be
> checked out during release:perform, keep that in mind.
> I see options with a flat structure and with the release-aggregator.
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/MRELEASE-362
>
>
> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev 
> wrote:
>
> Hi Paul,
>>
>> I think you misunderstood. The [BOM] is a separate project and the
>> [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
>> declare as their parent the [BOM].
>>
>> @Robert: I have added the test-case:
>> https://github.com/apache/maven-release/pull/18/commits/
>> Release-aggregator is exactly what's missing. Is there an issue I can
>> subscribe and track?
>>
>>
>> 2017-06-24 14:15 GMT+03:00 Robert Scholte :
>>
>> What we're still missing is a release-aggregator, which can release
>>> multiple release-roots at once. That would probably be the preferred fix,
>>> the suggested patch is just an easy work-around.
>>> It is still on my todo-list.
>>>
>>> Robert
>>>
>>>
>>> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant 
>>> wrote:
>>>
>>> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
>>>
 sure if 'BOM' should mean anything to me) that includes only 'platform'
 as
 a child module.

mvn release:prepare -PplatformOnly # etc

 Later when you're ready to do the demo store release, use another (from
 root):

mvn release:prepare -PdemoOnly # etc

 Of course, you man not need to stuff demo in your Artifactory/Nexus/etc
 in
 which case just do your deploy fu after an 'install' w/o the release
 plugin
 involved or that second profile.

 - Paul


 On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
 wrote:

 Hey guys,

>
> I'm facing a number of challenges when I release the project at my
> company.
> Here's my setup:
>
> [BOM]
>  /\
>  [PLATFORM]  [DEMO_STORE]
>
> I have a master BOM project which holds all the version as defined
> properties. This BOM is the parent to two other projects - [PLATFORM]
> and
> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
> inside,
> and the [DEMO_STORE] is a project that declares those modules as
> dependencies.
>
> Now what I want is to release all three from Jenkins. I can release the
> [BOM] with no problems, then I start release of the [PLATFORM] and all
> of a
> sudden Jenkins blocks because Maven asks me on the command line if I
> want
> to resolve the SNAPSHOT dependencies (remember the parent of the
> [PLATFORM]
> is the [BOM] SNAPSHOT version).
>
> So I created this issue https://issues.apache.org/jira
> /browse/MRELEASE-985
> to be able to specify the [BOM] parent version when I start the release
> of
> [PLATFORM]. I think I also fixed it with 

Re: Maven release plugin

[Robert Scholte]

MRELEASE-362[1] is probably the matching issue.
Be aware that some are talking about tagging every module. In most  
situations I don't like that. If the structure is hierarchical and the  
root is tagged, then all the modules are already tagged. All tags must be  
checked out during release:perform, keep that in mind.

I see options with a flat structure and with the release-aggregator.

Robert

[1] https://issues.apache.org/jira/browse/MRELEASE-362

On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev   
wrote:



Hi Paul,

I think you misunderstood. The [BOM] is a separate project and the
[PLATFORM] and [DEMO_STORE] are also separate projects, both of which
declare as their parent the [BOM].

@Robert: I have added the test-case:
https://github.com/apache/maven-release/pull/18/commits/
Release-aggregator is exactly what's missing. Is there an issue I can
subscribe and track?


2017-06-24 14:15 GMT+03:00 Robert Scholte :


What we're still missing is a release-aggregator, which can release
multiple release-roots at once. That would probably be the preferred  
fix,

the suggested patch is just an easy work-around.
It is still on my todo-list.

Robert


On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant   
wrote:


Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
sure if 'BOM' should mean anything to me) that includes only  
'platform' as

a child module.

   mvn release:prepare -PplatformOnly # etc

Later when you're ready to do the demo store release, use another (from
root):

   mvn release:prepare -PdemoOnly # etc

Of course, you man not need to stuff demo in your  
Artifactory/Nexus/etc in

which case just do your deploy fu after an 'install' w/o the release
plugin
involved or that second profile.

- Paul


On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
wrote:

Hey guys,


I'm facing a number of challenges when I release the project at my
company.
Here's my setup:

[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]

I have a master BOM project which holds all the version as defined
properties. This BOM is the parent to two other projects - [PLATFORM]  
and

[DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
inside,
and the [DEMO_STORE] is a project that declares those modules as
dependencies.

Now what I want is to release all three from Jenkins. I can release  
the

[BOM] with no problems, then I start release of the [PLATFORM] and all
of a
sudden Jenkins blocks because Maven asks me on the command line if I  
want

to resolve the SNAPSHOT dependencies (remember the parent of the
[PLATFORM]
is the [BOM] SNAPSHOT version).

So I created this issue https://issues.apache.org/jira
/browse/MRELEASE-985
to be able to specify the [BOM] parent version when I start the  
release

of
[PLATFORM]. I think I also fixed it with this pull-request:
https://github.com/apache/maven-release/pull/18

Can someone have a look at this pull request and tell me if it is OK?

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin

[Paul Hammant]

Yup. I don't think I understand the problem, and shouldn't comment.

On Sat, Jun 24, 2017 at 4:59 PM, Petar Tahchiev 
wrote:

> Hi Paul,
>
> I think you misunderstood. The [BOM] is a separate project and the
> [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
> declare as their parent the [BOM].
>
> @Robert: I have added the test-case:
> https://github.com/apache/maven-release/pull/18/commits/
> Release-aggregator is exactly what's missing. Is there an issue I can
> subscribe and track?
>
>
> 2017-06-24 14:15 GMT+03:00 Robert Scholte :
>
> > What we're still missing is a release-aggregator, which can release
> > multiple release-roots at once. That would probably be the preferred fix,
> > the suggested patch is just an easy work-around.
> > It is still on my todo-list.
> >
> > Robert
> >
> >
> > On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant 
> wrote:
> >
> > Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
> >> sure if 'BOM' should mean anything to me) that includes only 'platform'
> as
> >> a child module.
> >>
> >>mvn release:prepare -PplatformOnly # etc
> >>
> >> Later when you're ready to do the demo store release, use another (from
> >> root):
> >>
> >>mvn release:prepare -PdemoOnly # etc
> >>
> >> Of course, you man not need to stuff demo in your Artifactory/Nexus/etc
> in
> >> which case just do your deploy fu after an 'install' w/o the release
> >> plugin
> >> involved or that second profile.
> >>
> >> - Paul
> >>
> >>
> >> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
> >> wrote:
> >>
> >> Hey guys,
> >>>
> >>> I'm facing a number of challenges when I release the project at my
> >>> company.
> >>> Here's my setup:
> >>>
> >>> [BOM]
> >>>  /\
> >>>  [PLATFORM]  [DEMO_STORE]
> >>>
> >>> I have a master BOM project which holds all the version as defined
> >>> properties. This BOM is the parent to two other projects - [PLATFORM]
> and
> >>> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
> >>> inside,
> >>> and the [DEMO_STORE] is a project that declares those modules as
> >>> dependencies.
> >>>
> >>> Now what I want is to release all three from Jenkins. I can release the
> >>> [BOM] with no problems, then I start release of the [PLATFORM] and all
> >>> of a
> >>> sudden Jenkins blocks because Maven asks me on the command line if I
> want
> >>> to resolve the SNAPSHOT dependencies (remember the parent of the
> >>> [PLATFORM]
> >>> is the [BOM] SNAPSHOT version).
> >>>
> >>> So I created this issue https://issues.apache.org/jira
> >>> /browse/MRELEASE-985
> >>> to be able to specify the [BOM] parent version when I start the release
> >>> of
> >>> [PLATFORM]. I think I also fixed it with this pull-request:
> >>> https://github.com/apache/maven-release/pull/18
> >>>
> >>> Can someone have a look at this pull request and tell me if it is OK?
> >>>
> >>> --
> >>> Regards, Petar!
> >>> Karlovo, Bulgaria.
> >>> ---
> >>> Public PGP Key at:
> >>> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Maven release plugin

[Petar Tahchiev]

Hi Paul,

I think you misunderstood. The [BOM] is a separate project and the
[PLATFORM] and [DEMO_STORE] are also separate projects, both of which
declare as their parent the [BOM].

@Robert: I have added the test-case:
https://github.com/apache/maven-release/pull/18/commits/
Release-aggregator is exactly what's missing. Is there an issue I can
subscribe and track?


2017-06-24 14:15 GMT+03:00 Robert Scholte :

> What we're still missing is a release-aggregator, which can release
> multiple release-roots at once. That would probably be the preferred fix,
> the suggested patch is just an easy work-around.
> It is still on my todo-list.
>
> Robert
>
>
> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant  wrote:
>
> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
>> sure if 'BOM' should mean anything to me) that includes only 'platform' as
>> a child module.
>>
>>mvn release:prepare -PplatformOnly # etc
>>
>> Later when you're ready to do the demo store release, use another (from
>> root):
>>
>>mvn release:prepare -PdemoOnly # etc
>>
>> Of course, you man not need to stuff demo in your Artifactory/Nexus/etc in
>> which case just do your deploy fu after an 'install' w/o the release
>> plugin
>> involved or that second profile.
>>
>> - Paul
>>
>>
>> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
>> wrote:
>>
>> Hey guys,
>>>
>>> I'm facing a number of challenges when I release the project at my
>>> company.
>>> Here's my setup:
>>>
>>> [BOM]
>>>  /\
>>>  [PLATFORM]  [DEMO_STORE]
>>>
>>> I have a master BOM project which holds all the version as defined
>>> properties. This BOM is the parent to two other projects - [PLATFORM] and
>>> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
>>> inside,
>>> and the [DEMO_STORE] is a project that declares those modules as
>>> dependencies.
>>>
>>> Now what I want is to release all three from Jenkins. I can release the
>>> [BOM] with no problems, then I start release of the [PLATFORM] and all
>>> of a
>>> sudden Jenkins blocks because Maven asks me on the command line if I want
>>> to resolve the SNAPSHOT dependencies (remember the parent of the
>>> [PLATFORM]
>>> is the [BOM] SNAPSHOT version).
>>>
>>> So I created this issue https://issues.apache.org/jira
>>> /browse/MRELEASE-985
>>> to be able to specify the [BOM] parent version when I start the release
>>> of
>>> [PLATFORM]. I think I also fixed it with this pull-request:
>>> https://github.com/apache/maven-release/pull/18
>>>
>>> Can someone have a look at this pull request and tell me if it is OK?
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven release plugin

[Robert Scholte]

What we're still missing is a release-aggregator, which can release  
multiple release-roots at once. That would probably be the preferred fix,  
the suggested patch is just an easy work-around.

It is still on my todo-list.

Robert

On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant  wrote:


Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
sure if 'BOM' should mean anything to me) that includes only 'platform'  
as

a child module.

   mvn release:prepare -PplatformOnly # etc

Later when you're ready to do the demo store release, use another (from
root):

   mvn release:prepare -PdemoOnly # etc

Of course, you man not need to stuff demo in your Artifactory/Nexus/etc  
in
which case just do your deploy fu after an 'install' w/o the release  
plugin

involved or that second profile.

- Paul


On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
wrote:


Hey guys,

I'm facing a number of challenges when I release the project at my  
company.

Here's my setup:

[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]

I have a master BOM project which holds all the version as defined
properties. This BOM is the parent to two other projects - [PLATFORM]  
and
[DEMO_STORE], The [PLATFORM] is a project with more than 60 modules  
inside,

and the [DEMO_STORE] is a project that declares those modules as
dependencies.

Now what I want is to release all three from Jenkins. I can release the
[BOM] with no problems, then I start release of the [PLATFORM] and all  
of a
sudden Jenkins blocks because Maven asks me on the command line if I  
want
to resolve the SNAPSHOT dependencies (remember the parent of the  
[PLATFORM]

is the [BOM] SNAPSHOT version).

So I created this issue  
https://issues.apache.org/jira/browse/MRELEASE-985
to be able to specify the [BOM] parent version when I start the release  
of

[PLATFORM]. I think I also fixed it with this pull-request:
https://github.com/apache/maven-release/pull/18

Can someone have a look at this pull request and tell me if it is OK?

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin

[Paul Hammant]

Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
sure if 'BOM' should mean anything to me) that includes only 'platform' as
a child module.

   mvn release:prepare -PplatformOnly # etc

Later when you're ready to do the demo store release, use another (from
root):

   mvn release:prepare -PdemoOnly # etc

Of course, you man not need to stuff demo in your Artifactory/Nexus/etc in
which case just do your deploy fu after an 'install' w/o the release plugin
involved or that second profile.

- Paul


On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev 
wrote:

> Hey guys,
>
> I'm facing a number of challenges when I release the project at my company.
> Here's my setup:
>
> [BOM]
>  /\
>  [PLATFORM]  [DEMO_STORE]
>
> I have a master BOM project which holds all the version as defined
> properties. This BOM is the parent to two other projects - [PLATFORM] and
> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules inside,
> and the [DEMO_STORE] is a project that declares those modules as
> dependencies.
>
> Now what I want is to release all three from Jenkins. I can release the
> [BOM] with no problems, then I start release of the [PLATFORM] and all of a
> sudden Jenkins blocks because Maven asks me on the command line if I want
> to resolve the SNAPSHOT dependencies (remember the parent of the [PLATFORM]
> is the [BOM] SNAPSHOT version).
>
> So I created this issue https://issues.apache.org/jira/browse/MRELEASE-985
> to be able to specify the [BOM] parent version when I start the release of
> [PLATFORM]. I think I also fixed it with this pull-request:
> https://github.com/apache/maven-release/pull/18
>
> Can someone have a look at this pull request and tell me if it is OK?
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Maven release plugin

[Robert Scholte]

Hi Peter,

This fix looks good to me, but I would appreciate one integration test to  
confirm it and to prevent regression in the future.


thanks,
Robert

On Sat, 24 Jun 2017 08:58:58 +0200, Petar Tahchiev   
wrote:



Hey guys,

I'm facing a number of challenges when I release the project at my  
company.

Here's my setup:

[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]

I have a master BOM project which holds all the version as defined
properties. This BOM is the parent to two other projects - [PLATFORM] and
[DEMO_STORE], The [PLATFORM] is a project with more than 60 modules  
inside,

and the [DEMO_STORE] is a project that declares those modules as
dependencies.

Now what I want is to release all three from Jenkins. I can release the
[BOM] with no problems, then I start release of the [PLATFORM] and all  
of a

sudden Jenkins blocks because Maven asks me on the command line if I want
to resolve the SNAPSHOT dependencies (remember the parent of the  
[PLATFORM]

is the [BOM] SNAPSHOT version).

So I created this issue  
https://issues.apache.org/jira/browse/MRELEASE-985
to be able to specify the [BOM] parent version when I start the release  
of

[PLATFORM]. I think I also fixed it with this pull-request:
https://github.com/apache/maven-release/pull/18

Can someone have a look at this pull request and tell me if it is OK?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin And A BOM

[Petar Tahchiev]

Yeah,

I guess I feel the same and that's why I wanted to consult the dev list
first before raising a JIRA.

2016-05-03 23:21 GMT+02:00 Jörg Schaible :

> Hi Petar,
>
> Petar Tahchiev wrote:
>
> > Hi all,
> >
> > @Uwe - the enforcer rules are great, but I don't think I need them.
> > @Jorg - Resolving the parent during release:prepare is fine. What I don't
> > like is that it also asks me to resolve the platform version.
>
> The point is, that Maven does not recreate the effective POM to build again
> the list of versions to resolve. It's simply a corner case. Some might
> argue
> it is undefined behavior, others might say it's a bug ;-)
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven Release Plugin And A BOM

[Jörg Schaible]

Hi Petar,

Petar Tahchiev wrote:

> Hi all,
> 
> @Uwe - the enforcer rules are great, but I don't think I need them.
> @Jorg - Resolving the parent during release:prepare is fine. What I don't
> like is that it also asks me to resolve the platform version.

The point is, that Maven does not recreate the effective POM to build again 
the list of versions to resolve. It's simply a corner case. Some might argue 
it is undefined behavior, others might say it's a bug ;-)

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin And A BOM

[Petar Tahchiev]

Hi all,

@Uwe - the enforcer rules are great, but I don't think I need them.
@Jorg - Resolving the parent during release:prepare is fine. What I don't
like is that it also asks me to resolve the platform version.

I'll go with Robert's suggestion.

2016-05-03 19:51 GMT+03:00 Jörg Schaible :

> Petar Tahchiev wrote:
>
> > Hi guys,
> >
> > I have a question regarding the release plugin. In my project I have a
> BOM
> > in which I declare a property and a dependencyManagement section:
> >
> > com.mycompany
> > my-bom
> > 1.0-SNAPSHOT
> >
> > 
> > 1.0-SNAPSHOT
> > 
> >
> > 
> >
> >   com.mycompany
> >   platform
> >   ${platform.version}
> >   
> > 
> >
> >
> > and I also have 3 different projects that declare this BOM as their
> > parent. All of these projects have the same version number (1.0-SNAPSHOT)
> > and when I make a release I always release all of them. This is how it
> > looks like: 1) I change platform.version property to 1.0, commit, push
> and
> > release the bom.
> > 2) I try to release first of my other projects and now the release plugin
> > is asking me to resolve the version of the BOM. Ok, fair enough, I
> resolve
> > it to 1.0 but then it asks me again to resolve the version of
> > com.mycompany:platform. This clearly is a bug right? I have changed it to
> > 1.0 before so it is no longer a SNAPSHOT???
> > If you think this is a problem, I will submit it in the JIRA and try to
> > fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
> > maybe that's how it is supposed to be.
>
> You mean, you let the release plugin resolve the parent? We always manually
> "resolved" the parent first...
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven Release Plugin And A BOM

[Jörg Schaible]

Petar Tahchiev wrote:

> Hi guys,
> 
> I have a question regarding the release plugin. In my project I have a BOM
> in which I declare a property and a dependencyManagement section:
> 
> com.mycompany
> my-bom
> 1.0-SNAPSHOT
> 
> 
> 1.0-SNAPSHOT
> 
> 
> 
>
>   com.mycompany
>   platform
>   ${platform.version}
>   
> 
> 
> 
> and I also have 3 different projects that declare this BOM as their
> parent. All of these projects have the same version number (1.0-SNAPSHOT)
> and when I make a release I always release all of them. This is how it
> looks like: 1) I change platform.version property to 1.0, commit, push and
> release the bom.
> 2) I try to release first of my other projects and now the release plugin
> is asking me to resolve the version of the BOM. Ok, fair enough, I resolve
> it to 1.0 but then it asks me again to resolve the version of
> com.mycompany:platform. This clearly is a bug right? I have changed it to
> 1.0 before so it is no longer a SNAPSHOT???
> If you think this is a problem, I will submit it in the JIRA and try to
> fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
> maybe that's how it is supposed to be.

You mean, you let the release plugin resolve the parent? We always manually 
"resolved" the parent first...

Cheers,
Jörg



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin And A BOM

[Uwe Barthel]

Hi Petar,

I found a very old enforcer rule at smartics and asked them to provide 
these as OS.

They did it two weeks ago at github under Apache Software License. :-)

Take a look at https://github.com/smartics/smartics-enforcer-rules

-- barthel



On May 3, 2016 4:25:55 PM Petar Tahchiev  wrote:


Hi Robert,

thank you for your comment. The idea behind the property was that I also
give the BOM to my clients and they declare it as their parent. So now if
they want to use a newer version of the platform, all they have to do
is redeclare the property  to be 1.2 or 1.5 or whatever
they want. Otherwise they will have to re-declare the whole dependency.

Now that I think about it I was wrong - if my clients want to update the
platform version all they have to do is update version of the parent BOM.

I still think though that this is a bug.


2016-05-03 16:17 GMT+02:00 Robert Patrick :


Why bother with the custom property?  Do this instead and the release
plugin is happy:

com.mycompany
my-bom
1.0-SNAPSHOT


   
  com.mycompany
  platform
  ${project.version}
  




-Original Message-
From: Petar Tahchiev [mailto:paranoia...@gmail.com]
Sent: Tuesday, May 03, 2016 9:10 AM
To: Maven Developers List
Subject: Maven Release Plugin And A BOM

Hi guys,

I have a question regarding the release plugin. In my project I have a BOM
in which I declare a property and a dependencyManagement section:

com.mycompany
my-bom
1.0-SNAPSHOT


1.0-SNAPSHOT



   
  com.mycompany
  platform
  ${platform.version}
  



and I also have 3 different projects that declare this BOM as their parent.
All of these projects have the same version number (1.0-SNAPSHOT) and when
I make a release I always release all of them. This is how it looks like:
1) I change platform.version property to 1.0, commit, push and release the
bom.
2) I try to release first of my other projects and now the release plugin
is asking me to resolve the version of the BOM. Ok, fair enough, I resolve
it to 1.0 but then it asks me again to resolve the version of
com.mycompany:platform. This clearly is a bug right? I have changed it to
1.0 before so it is no longer a SNAPSHOT???
If you think this is a problem, I will submit it in the JIRA and try to
fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
maybe that's how it is supposed to be.

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin And A BOM

[Petar Tahchiev]

Hi Robert,

thank you for your comment. The idea behind the property was that I also
give the BOM to my clients and they declare it as their parent. So now if
they want to use a newer version of the platform, all they have to do
is redeclare the property  to be 1.2 or 1.5 or whatever
they want. Otherwise they will have to re-declare the whole dependency.

Now that I think about it I was wrong - if my clients want to update the
platform version all they have to do is update version of the parent BOM.

I still think though that this is a bug.


2016-05-03 16:17 GMT+02:00 Robert Patrick :

> Why bother with the custom property?  Do this instead and the release
> plugin is happy:
>
> com.mycompany
> my-bom
> 1.0-SNAPSHOT
>
> 
>
>   com.mycompany
>   platform
>   ${project.version}
>   
> 
>
>
>
> -Original Message-
> From: Petar Tahchiev [mailto:paranoia...@gmail.com]
> Sent: Tuesday, May 03, 2016 9:10 AM
> To: Maven Developers List
> Subject: Maven Release Plugin And A BOM
>
> Hi guys,
>
> I have a question regarding the release plugin. In my project I have a BOM
> in which I declare a property and a dependencyManagement section:
>
> com.mycompany
> my-bom
> 1.0-SNAPSHOT
>
> 
> 1.0-SNAPSHOT
> 
>
> 
>
>   com.mycompany
>   platform
>   ${platform.version}
>   
> 
>
>
> and I also have 3 different projects that declare this BOM as their parent.
> All of these projects have the same version number (1.0-SNAPSHOT) and when
> I make a release I always release all of them. This is how it looks like:
> 1) I change platform.version property to 1.0, commit, push and release the
> bom.
> 2) I try to release first of my other projects and now the release plugin
> is asking me to resolve the version of the BOM. Ok, fair enough, I resolve
> it to 1.0 but then it asks me again to resolve the version of
> com.mycompany:platform. This clearly is a bug right? I have changed it to
> 1.0 before so it is no longer a SNAPSHOT???
> If you think this is a problem, I will submit it in the JIRA and try to
> fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
> maybe that's how it is supposed to be.
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

RE: Maven Release Plugin And A BOM

[Robert Patrick]

Why bother with the custom property?  Do this instead and the release plugin is 
happy:

com.mycompany
my-bom
1.0-SNAPSHOT


   
  com.mycompany
  platform
  ${project.version}
  

 


-Original Message-
From: Petar Tahchiev [mailto:paranoia...@gmail.com] 
Sent: Tuesday, May 03, 2016 9:10 AM
To: Maven Developers List
Subject: Maven Release Plugin And A BOM

Hi guys,

I have a question regarding the release plugin. In my project I have a BOM in 
which I declare a property and a dependencyManagement section:

com.mycompany
my-bom
1.0-SNAPSHOT


1.0-SNAPSHOT



   
  com.mycompany
  platform
  ${platform.version}
  



and I also have 3 different projects that declare this BOM as their parent.
All of these projects have the same version number (1.0-SNAPSHOT) and when I 
make a release I always release all of them. This is how it looks like:
1) I change platform.version property to 1.0, commit, push and release the bom.
2) I try to release first of my other projects and now the release plugin is 
asking me to resolve the version of the BOM. Ok, fair enough, I resolve it to 
1.0 but then it asks me again to resolve the version of com.mycompany:platform. 
This clearly is a bug right? I have changed it to
1.0 before so it is no longer a SNAPSHOT???
If you think this is a problem, I will submit it in the JIRA and try to fix it. 
I'm just not sure if it's a bug or maybe it's a known issue, or maybe that's 
how it is supposed to be.

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin with Git broken?

[Karl Heinz Marbaise]

Hi Robert,

Is this  a mult module project ? Have you defined the scm connection 
only in the root module ? Are you trying to release from the root of ?


Kind regards
Karl Heinz Marbaise

On 10/7/15 4:48 AM, Robert Patrick wrote:

Hi,



Sorry for the noise but it seems like the Maven Release Plugin 2.5.2 (with Maven 3.3.3) 
is not doing what I would have expected with a Git repo.  As you can see below, the 
"git push" command is mangling the repository by tacking the artifactId of my 
multi-module project onto the end of the connection url, which is causing our Gitlab 
server to rightfully complain that the repository does not exist.



[INFO] Checking in modified POMs...

[INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git add -- 
parent/pom.xml util/pom.xml consumer/pom.xml pom.xml

[INFO] Working directory: /scratch/rpatrick/snapshots-test

[INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git 
rev-parse --show-toplevel

[INFO] Working directory: /scratch/rpatrick/snapshots-test

[INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git status 
--porcelain .

[INFO] Working directory: /scratch/rpatrick/snapshots-test

[INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git commit 
--verbose -F /tmp/maven-scm-1310627247.commit parent/pom.xml util/pom.xml 
consumer/pom.xml pom.xml

[INFO] Working directory: /scratch/rpatrick/snapshots-test

[INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git 
symbolic-ref HEAD

[INFO] Working directory: /scratch/rpatrick/snapshots-test

[INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git push 
g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module 
refs/heads/master:refs/heads/master



My scm section of my parent pom (whjch all poms inherent from) looks like this:



   
 
scm:git:g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git
 
scm:git:g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git
   



So why is Maven trying to use HYPERLINK 
"mailto:g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module"g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module
 in the git push command?



Am I just doing something stupid or is this really busted?



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin with Git broken?

[Baptiste Mathus]

Hi Robert, not a developer list question, better use the users list for
that kind of questions.
Indeed, like what Karl-Heinz says, I suspect you're trying to release from
a submodule/subdirectory.

Cheers

2015-10-07 9:23 GMT+02:00 Karl Heinz Marbaise :

> Hi Robert,
>
> Is this  a mult module project ? Have you defined the scm connection only
> in the root module ? Are you trying to release from the root of ?
>
> Kind regards
> Karl Heinz Marbaise
>
> On 10/7/15 4:48 AM, Robert Patrick wrote:
>
>> Hi,
>>
>>
>>
>> Sorry for the noise but it seems like the Maven Release Plugin 2.5.2
>> (with Maven 3.3.3) is not doing what I would have expected with a Git
>> repo.  As you can see below, the "git push" command is mangling the
>> repository by tacking the artifactId of my multi-module project onto the
>> end of the connection url, which is causing our Gitlab server to rightfully
>> complain that the repository does not exist.
>>
>>
>>
>> [INFO] Checking in modified POMs...
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> add -- parent/pom.xml util/pom.xml consumer/pom.xml pom.xml
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> rev-parse --show-toplevel
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> status --porcelain .
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> commit --verbose -F /tmp/maven-scm-1310627247.commit parent/pom.xml
>> util/pom.xml consumer/pom.xml pom.xml
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> symbolic-ref HEAD
>>
>> [INFO] Working directory: /scratch/rpatrick/snapshots-test
>>
>> [INFO] Executing: /bin/sh -c cd /scratch/rpatrick/snapshots-test && git
>> push 
>> g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module
>> refs/heads/master:refs/heads/master
>>
>>
>>
>> My scm section of my parent pom (whjch all poms inherent from) looks like
>> this:
>>
>>
>>
>>
>>  scm:git:g...@orahub.oraclecorp.com:
>> robert.patrick/snapshots-test.git
>>  scm:git:g...@orahub.oraclecorp.com:
>> robert.patrick/snapshots-test.git
>>
>>
>>
>>
>> So why is Maven trying to use HYPERLINK "mailto:g...@orahub.oraclecorp.com
>> :robert.patrick/snapshots-test.git/snapshots-multi-module"g...@orahub.oraclecorp.com:robert.patrick/snapshots-test.git/snapshots-multi-module
>> in the git push command?
>>
>>
>>
>> Am I just doing something stupid or is this really busted?
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: maven-release-plugin: consolidating release:perform and release:stage

[Mirko Friedenhagen]

Concerning. @since, that's really easy then.

I had another thought: while pushChanges  does allow to defer pushing, you
have to do an extra execution of e.g. git push; git push --tags. What about
having a property pushChangesAfterDeploy in prepare and stage which would
do this in the release plugin?

Regards
Mirko
-- 
Sent from my mobile
On Mar 28, 2015 11:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:

 the annotation takes free text, then let's try a descrptive text:

 @since xxx in release:perform, yyy in release:stage

 Regards,

 Hervé

 Le mardi 24 mars 2015 21:15:20 Mirko Friedenhagen a écrit :
  Hello everybody,
 
  today I stumbled upon a difference between perform and stage:
  - while perform takes an parameter localCheckout, stage does not
  - I opened MRELEASE-901Goal stage should take parameter localCheckout
  as well [1].
  - while inspecting the code I found lot of duplicates.
  - so my idea is to pull up most of the code to AbstractReleaseMojo and
  consolidate most of the execute block and only differ while adding
  default goals resp. setting the alternativeDeployRepository.
  - one problem I see is, however, that some parameters were introduced
  later on, so how to handle the @since annotations here?
 
  Best Regards
  Mirko
 
  [1] http://jira.codehaus.org/browse/MRELEASE-901
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: consolidating release:perform and release:stage

[Hervé BOUTEMY]

the annotation takes free text, then let's try a descrptive text:

@since xxx in release:perform, yyy in release:stage

Regards,

Hervé

Le mardi 24 mars 2015 21:15:20 Mirko Friedenhagen a écrit :
 Hello everybody,
 
 today I stumbled upon a difference between perform and stage:
 - while perform takes an parameter localCheckout, stage does not
 - I opened MRELEASE-901Goal stage should take parameter localCheckout
 as well [1].
 - while inspecting the code I found lot of duplicates.
 - so my idea is to pull up most of the code to AbstractReleaseMojo and
 consolidate most of the execute block and only differ while adding
 default goals resp. setting the alternativeDeployRepository.
 - one problem I see is, however, that some parameters were introduced
 later on, so how to handle the @since annotations here?
 
 Best Regards
 Mirko
 
 [1] http://jira.codehaus.org/browse/MRELEASE-901
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Mirko Friedenhagen]

Hello,

further inspection of the problem leads to a possible solution:
- the shell script does retrieve M2_HOME, however, as it is not
exported it is not available furtheron.
- so a quick fix would be to export M2_HOME directly before invoking
exec $JAVACMD ...
- however this will not help with IDEs like Eclipse or Intellij which
use their own code to invoke stuff.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Mar 24, 2015 at 11:17 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello Robert,

 I see maven-shared-invoker was just released by you. I will take a look at
 MSHARED-261, which at least has a suggestion for a fix.

 Regards
 Mirko
 --
 Sent from my mobile

 On Mar 24, 2015 10:31 PM, Robert Scholte rfscho...@apache.org wrote:

 Hi Mirko,

 This confirms why Karl Heinz had issues with the Maven Invoker 2.2 (take
 1)
 On Windows there's no issue, the mvn.bat/mvn.cmd always sets M2_HOME if
 it's not there.

 We could add an AssumeThat-clause in this test as well...

 thanks,
 Robert


 Op Tue, 24 Mar 2015 22:16:59 +0100 schreef Mirko Friedenhagen
 mfriedenha...@apache.org:

 Hello,

 I just checked out the trunk (r1643023) and running mvn clean verify
 does not succeed neither with Maven 3.0.5, Maven 3.2.5 nor with Maven
 3.3.1 (OS X 10.10.2, JDK 1.7.0_76):

 The test
 org.apache.maven.shared.release.exec.InvokerMavenExecutorTest#testEncryptSettings
 is always failing with the following message from

 /maven-invoker-2.1-sources.jar!/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java:124

 java.lang.IllegalStateException: Maven application directory was not
 specified, and ${maven.home} is not provided in the system properties.
 Please specify at least on of these.

 When I set the M2_HOME variable on the command line manually, the tests
 succeed.

 Regards
 Mirko

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Mirko Friedenhagen]

What I do not understand is, that
https://builds.apache.org/view/All/job/maven-release/261/consoleFull
is just running fine with Maven 3.0.5. Two wild guesses:
- it is because we do not use a Jenkins freestyle job but a beloved by
Stephen ;-) Maven job.
- or maybe something changed with shellshock, where export of
environment variables did change.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 25, 2015 at 9:12 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Unfortunately, we may not use Assume in this testcase because it is
 derived from PlexusTestcase and this one does fail on
 AssumptionViolated as well. As a dirty workaround we could just return
 when System.getenv(M2_HOME) is null.
 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Wed, Mar 25, 2015 at 9:01 PM, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
 Hello,

 further inspection of the problem leads to a possible solution:
 - the shell script does retrieve M2_HOME, however, as it is not
 exported it is not available furtheron.
 - so a quick fix would be to export M2_HOME directly before invoking
 exec $JAVACMD ...
 - however this will not help with IDEs like Eclipse or Intellij which
 use their own code to invoke stuff.

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Tue, Mar 24, 2015 at 11:17 PM, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
 Hello Robert,

 I see maven-shared-invoker was just released by you. I will take a look at
 MSHARED-261, which at least has a suggestion for a fix.

 Regards
 Mirko
 --
 Sent from my mobile

 On Mar 24, 2015 10:31 PM, Robert Scholte rfscho...@apache.org wrote:

 Hi Mirko,

 This confirms why Karl Heinz had issues with the Maven Invoker 2.2 (take
 1)
 On Windows there's no issue, the mvn.bat/mvn.cmd always sets M2_HOME if
 it's not there.

 We could add an AssumeThat-clause in this test as well...

 thanks,
 Robert


 Op Tue, 24 Mar 2015 22:16:59 +0100 schreef Mirko Friedenhagen
 mfriedenha...@apache.org:

 Hello,

 I just checked out the trunk (r1643023) and running mvn clean verify
 does not succeed neither with Maven 3.0.5, Maven 3.2.5 nor with Maven
 3.3.1 (OS X 10.10.2, JDK 1.7.0_76):

 The test
 org.apache.maven.shared.release.exec.InvokerMavenExecutorTest#testEncryptSettings
 is always failing with the following message from

 /maven-invoker-2.1-sources.jar!/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java:124

 java.lang.IllegalStateException: Maven application directory was not
 specified, and ${maven.home} is not provided in the system properties.
 Please specify at least on of these.

 When I set the M2_HOME variable on the command line manually, the tests
 succeed.

 Regards
 Mirko

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Mirko Friedenhagen]

Hello there, I now have a workaround. I am setting:

 injectedMavenHome${maven.home}/injectedMavenHome

in  maven-release-manager/pom.xml and use this to set:
releaseEnvironment.setMavenHome( new File( System.getProperty(
injectedMavenHome ) ) );
in the testcase.

Works fine from the command line.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 25, 2015 at 10:04 PM, Bernd Eckenfels
e...@zusammenkunft.net wrote:
 Am Wed, 25 Mar 2015 21:01:53 +0100
 schrieb Mirko Friedenhagen mfriedenha...@gmail.com:
 - however this will not help with IDEs like Eclipse or Intellij which
 use their own code to invoke stuff.

 I guess it is better when you pass it as a system property:

 -Dmaven.home=${M2_HOME}

 that way you dont need to export it and the configuration is consistent
 (with the settings the IDEs typically set as well).

 Gruss
 Bernd

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Karl Heinz Marbaise]

Hi Mirko,

On 3/25/15 9:31 PM, Mirko Friedenhagen wrote:

What I do not understand is, that
https://builds.apache.org/view/All/job/maven-release/261/consoleFull
is just running fine with Maven 3.0.5. Two wild guesses:
- it is because we do not use a Jenkins freestyle job but a beloved by
Stephen ;-) Maven job.


Yes the beloved Maven Job...is used...


- or maybe something changed with shellshock, where export of
environment variables did change.


Hm...it's a though worth...

Kind regards
Karl Heinz Marbaise



Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 25, 2015 at 9:12 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:

Unfortunately, we may not use Assume in this testcase because it is
derived from PlexusTestcase and this one does fail on
AssumptionViolated as well. As a dirty workaround we could just return
when System.getenv(M2_HOME) is null.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 25, 2015 at 9:01 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:

Hello,

further inspection of the problem leads to a possible solution:
- the shell script does retrieve M2_HOME, however, as it is not
exported it is not available furtheron.
- so a quick fix would be to export M2_HOME directly before invoking
exec $JAVACMD ...
- however this will not help with IDEs like Eclipse or Intellij which
use their own code to invoke stuff.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Mar 24, 2015 at 11:17 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:

Hello Robert,

I see maven-shared-invoker was just released by you. I will take a look at
MSHARED-261, which at least has a suggestion for a fix.

Regards
Mirko
--
Sent from my mobile

On Mar 24, 2015 10:31 PM, Robert Scholte rfscho...@apache.org wrote:


Hi Mirko,

This confirms why Karl Heinz had issues with the Maven Invoker 2.2 (take
1)
On Windows there's no issue, the mvn.bat/mvn.cmd always sets M2_HOME if
it's not there.

We could add an AssumeThat-clause in this test as well...

thanks,
Robert


Op Tue, 24 Mar 2015 22:16:59 +0100 schreef Mirko Friedenhagen
mfriedenha...@apache.org:


Hello,

I just checked out the trunk (r1643023) and running mvn clean verify
does not succeed neither with Maven 3.0.5, Maven 3.2.5 nor with Maven
3.3.1 (OS X 10.10.2, JDK 1.7.0_76):

The test
org.apache.maven.shared.release.exec.InvokerMavenExecutorTest#testEncryptSettings
is always failing with the following message from

/maven-invoker-2.1-sources.jar!/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java:124

java.lang.IllegalStateException: Maven application directory was not
specified, and ${maven.home} is not provided in the system properties.
Please specify at least on of these.

When I set the M2_HOME variable on the command line manually, the tests
succeed.

Regards
Mirko


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Mirko Friedenhagen]

Unfortunately, we may not use Assume in this testcase because it is
derived from PlexusTestcase and this one does fail on
AssumptionViolated as well. As a dirty workaround we could just return
when System.getenv(M2_HOME) is null.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Mar 25, 2015 at 9:01 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 further inspection of the problem leads to a possible solution:
 - the shell script does retrieve M2_HOME, however, as it is not
 exported it is not available furtheron.
 - so a quick fix would be to export M2_HOME directly before invoking
 exec $JAVACMD ...
 - however this will not help with IDEs like Eclipse or Intellij which
 use their own code to invoke stuff.

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
 https://bitbucket.org/mfriedenhagen/


 On Tue, Mar 24, 2015 at 11:17 PM, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
 Hello Robert,

 I see maven-shared-invoker was just released by you. I will take a look at
 MSHARED-261, which at least has a suggestion for a fix.

 Regards
 Mirko
 --
 Sent from my mobile

 On Mar 24, 2015 10:31 PM, Robert Scholte rfscho...@apache.org wrote:

 Hi Mirko,

 This confirms why Karl Heinz had issues with the Maven Invoker 2.2 (take
 1)
 On Windows there's no issue, the mvn.bat/mvn.cmd always sets M2_HOME if
 it's not there.

 We could add an AssumeThat-clause in this test as well...

 thanks,
 Robert


 Op Tue, 24 Mar 2015 22:16:59 +0100 schreef Mirko Friedenhagen
 mfriedenha...@apache.org:

 Hello,

 I just checked out the trunk (r1643023) and running mvn clean verify
 does not succeed neither with Maven 3.0.5, Maven 3.2.5 nor with Maven
 3.3.1 (OS X 10.10.2, JDK 1.7.0_76):

 The test
 org.apache.maven.shared.release.exec.InvokerMavenExecutorTest#testEncryptSettings
 is always failing with the following message from

 /maven-invoker-2.1-sources.jar!/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java:124

 java.lang.IllegalStateException: Maven application directory was not
 specified, and ${maven.home} is not provided in the system properties.
 Please specify at least on of these.

 When I set the M2_HOME variable on the command line manually, the tests
 succeed.

 Regards
 Mirko

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Bernd Eckenfels]

Am Wed, 25 Mar 2015 21:01:53 +0100
schrieb Mirko Friedenhagen mfriedenha...@gmail.com:
 - however this will not help with IDEs like Eclipse or Intellij which
 use their own code to invoke stuff.

I guess it is better when you pass it as a system property:

-Dmaven.home=${M2_HOME}

that way you dont need to export it and the configuration is consistent
(with the settings the IDEs typically set as well).

Gruss
Bernd

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Mirko Friedenhagen]

Hello Robert,

I see maven-shared-invoker was just released by you. I will take a look at
MSHARED-261, which at least has a suggestion for a fix.

Regards
Mirko
-- 
Sent from my mobile
On Mar 24, 2015 10:31 PM, Robert Scholte rfscho...@apache.org wrote:

 Hi Mirko,

 This confirms why Karl Heinz had issues with the Maven Invoker 2.2 (take 1)
 On Windows there's no issue, the mvn.bat/mvn.cmd always sets M2_HOME if
 it's not there.

 We could add an AssumeThat-clause in this test as well...

 thanks,
 Robert


 Op Tue, 24 Mar 2015 22:16:59 +0100 schreef Mirko Friedenhagen 
 mfriedenha...@apache.org:

  Hello,

 I just checked out the trunk (r1643023) and running mvn clean verify
 does not succeed neither with Maven 3.0.5, Maven 3.2.5 nor with Maven
 3.3.1 (OS X 10.10.2, JDK 1.7.0_76):

 The test org.apache.maven.shared.release.exec.InvokerMavenExecutorTest#
 testEncryptSettings
 is always failing with the following message from
 /maven-invoker-2.1-sources.jar!/org/apache/maven/shared/invoker/
 MavenCommandLineBuilder.java:124

 java.lang.IllegalStateException: Maven application directory was not
 specified, and ${maven.home} is not provided in the system properties.
 Please specify at least on of these.

 When I set the M2_HOME variable on the command line manually, the tests
 succeed.

 Regards
 Mirko

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin does not build cleanly - M2_HOME is missing

[Robert Scholte]

Hi Mirko,

This confirms why Karl Heinz had issues with the Maven Invoker 2.2 (take 1)
On Windows there's no issue, the mvn.bat/mvn.cmd always sets M2_HOME if  
it's not there.


We could add an AssumeThat-clause in this test as well...

thanks,
Robert


Op Tue, 24 Mar 2015 22:16:59 +0100 schreef Mirko Friedenhagen  
mfriedenha...@apache.org:



Hello,

I just checked out the trunk (r1643023) and running mvn clean verify
does not succeed neither with Maven 3.0.5, Maven 3.2.5 nor with Maven
3.3.1 (OS X 10.10.2, JDK 1.7.0_76):

The test  
org.apache.maven.shared.release.exec.InvokerMavenExecutorTest#testEncryptSettings

is always failing with the following message from
/maven-invoker-2.1-sources.jar!/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java:124

java.lang.IllegalStateException: Maven application directory was not
specified, and ${maven.home} is not provided in the system properties.
Please specify at least on of these.

When I set the M2_HOME variable on the command line manually, the tests  
succeed.


Regards
Mirko

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin and Java 8 issue

[Robert Scholte]

Hi,

please only use the Maven users mailing list for these kind of questions.
The Maven Developers List is meant for development of Maven itself.

thanks,
Robert

Op Fri, 29 Aug 2014 09:05:30 +0200 schreef Vijaysenthil Veeriah  
vijaysent...@gmail.com:



Hi
  I apologize I'm kind of new to maven and I cant figure out how  get the
Maven Release plugin to work for a Java 8 project.  I'm using   maven
release plugin version 2.5 (The maven compiler plugin version is 3.1) .
When i just use the compiler plugin and do a compile it works fine, n  
fact

i can use most of the other plugins like deploy etc but when i try to use
the maven release plugin I get an invalid target(1.8) error(attached  
below)

, I'm running this in IntelliJ and the java_home and Maven runner are all
configured to use 1.8, Also like i said if i directly execute the maven
compiler plugin, it works fine


Any help is greatly appreciated
Thanks
Vijay



The info the is spitted out Before the run

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java
-Dmaven.home=/usr/share/apache-maven-3.2.2
-Dclassworlds.conf=/usr/share/apache-maven-3.2.2/bin/m2.conf
-Didea.launcher.port=7547  
-Didea.launcher.bin.path=/Applications/IntelliJ

IDEA 13.app/bin -Dfile.encoding=UTF-8 -classpath
/usr/share/apache-maven-3.2.2/boot/plexus-classworlds-2.5.1.jar:/Applications/IntelliJ
IDEA 13.app/lib/idea_rt.jar  
com.intellij.rt.execution.application.AppMain

org.codehaus.classworlds.Launcher -Didea.version=13.1.3 -e -X
release:prepare -DdryRun=true
Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
2014-06-17T06:51:42-07:00)
*Maven home: /usr/share/apache-maven-3.2.2*
*Java version: 1.8.0_05, vendor: Oracle Corporation*
*Java home:
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre*
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.9.4, arch: x86_64, family: mac



The error



 *Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project : Fatal error compiling: invalid target
release: 1.8 - [Help 1]*
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project : Fatal error compiling
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
[INFO] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
[INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
[INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
[INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
[INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
[INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO] at java.lang.reflect.Method.invoke(Method.java:597)
[INFO] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[INFO] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[INFO] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[INFO] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal
error compiling
[INFO] at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:796)
[INFO] at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
[INFO] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[INFO] ... 19 more
[INFO] Caused by: org.codehaus.plexus.compiler.CompilerException: invalid
target release: 1.8
[INFO] at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:191)
[INFO] at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
[INFO] at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785)
[INFO] ... 22 more
[INFO] Caused by: 

Re: Maven-release-plugin and scm site publication: need help

[Benson Margulies]

Never mind, I found the shell script left behind by the last person
who did this. I

On Sun, Feb 23, 2014 at 7:38 AM, Benson Margulies bimargul...@gmail.com wrote:
 I've staged 2.5 of the maven-release component. However, the
 documentation staging process is failing.

 mvn -Preporting site site:stage

 does not write into the ~/maven-sites directory where the scm plugin expects 
 it.

 Could some kind soul either checkout the tag and patch this up and
 stage it, or commit a fix, or give me a hint? I get on an airplane in
 7 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: Maven-release-plugin and scm site publication: need help

[Martin Gainty]

MGso in your instance why does'nt maven-scm-publish to ~/maven-sites ??

  


 Date: Sun, 23 Feb 2014 09:52:12 -0500
 Subject: Re: Maven-release-plugin and scm site publication: need help
 From: bimargul...@gmail.com
 To: dev@maven.apache.org
 
 Never mind, I found the shell script left behind by the last person
 who did this. I
 
 On Sun, Feb 23, 2014 at 7:38 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
  I've staged 2.5 of the maven-release component. However, the
  documentation staging process is failing.
 
  mvn -Preporting site site:stage
 
  does not write into the ~/maven-sites directory where the scm plugin 
  expects it.
 
  Could some kind soul either checkout the tag and patch this up and
  stage it, or commit a fix, or give me a hint? I get on an airplane in
  7 hours.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
  

Re: Maven-release-plugin and scm site publication: need help

[Benson Margulies]

If you look at the current parent poms, they generally set up so that
site:stage writes to ~/maven-sites/..., so that, later, the scm
publish plugin can read it from there.

On Sun, Feb 23, 2014 at 8:58 PM, Martin Gainty mgai...@hotmail.com wrote:
 MGso in your instance why does'nt maven-scm-publish to ~/maven-sites ??




 Date: Sun, 23 Feb 2014 09:52:12 -0500
 Subject: Re: Maven-release-plugin and scm site publication: need help
 From: bimargul...@gmail.com
 To: dev@maven.apache.org

 Never mind, I found the shell script left behind by the last person
 who did this. I

 On Sun, Feb 23, 2014 at 7:38 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
  I've staged 2.5 of the maven-release component. However, the
  documentation staging process is failing.
 
  mvn -Preporting site site:stage
 
  does not write into the ~/maven-sites directory where the scm plugin 
  expects it.
 
  Could some kind soul either checkout the tag and patch this up and
  stage it, or commit a fix, or give me a hint? I get on an airplane in
  7 hours.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

[Chris Graham]

Hi Mark.
Yes it is, just define them as dependencies of the maven-release-plugin in
your parent (or otherwise) pom.
-Chris


On Mon, Dec 9, 2013 at 3:23 PM, Mark Derricutt m...@talios.com wrote:

 Ok - so this looks to be an issue introduced in Git 1.8.5, from
 https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt

  * git status now omits the prefix to make its output a comment in a
commit log editor, which is not necessary for human consumption.
Scripts that parse the output of git status are advised to use
git status --porcelain instead, as its format is stable and easier
to parse.

 From looking at the git log of

 ./maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java
 I see that the has been using the newer git status --porcelain command
 for some time now, however from walking the dependencies of
 maven-release-plugin, I appear to find 1.7 being resolved ( at least via
 IntellliJ ).

 It looks like Olivier Lamy updated the git status support in [1] in git
 commit 5c58908896a1b82bc6ee0af005adf0d6ef326395

 Up until this week this didn't appear to be a problem, until Git 1.8.5 was
 released and removed the leading # from the status messages

 How do we get Maven to start using the newer releases of SCM - is that just
 a matter of declaring a dependency in my parent pom?

 Mark



 [1] [SCM-686] Maven SCM failed to parse git status output if git messages
 are translated - Submitted by Ralf Thielow.

 --
 Great artists are extremely selfish and arrogant things — Steven Wilson,
 Porcupine Tree


 On Mon, Dec 9, 2013 at 3:40 PM, Mark Derricutt m...@talios.com wrote:

  Hey all,
 
  Just encountered a strange issue with the maven-release-plugin, when
 doing
  a release:prepare from my machine using Maven 3.1.1, and
  maven-release-plugin 2.4.2 I get the following output:
 
  [INFO] Checking in modified POMs...
  [INFO] Executing: /bin/sh -c cd
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 add
  -- pom.xml
  [INFO] Working directory:
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
  [INFO] Executing: /bin/sh -c cd
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
  status
  [INFO] Working directory:
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
  [INFO] Tagging release with the label com.smxemail.translation-13.2.9...
  [INFO] Executing: /bin/sh -c cd
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 tag
  -F
 
 /var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit
  com.smxemail.translation-13.2.9
  [INFO] Working directory:
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
  [INFO] Executing: /bin/sh -c cd
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
  ls-files
  [INFO] Working directory:
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
  [INFO] Transforming 'com.smxemail.translation'...
  [INFO] Not removing release POMs
  [INFO] Checking in modified POMs...
  [INFO] Executing: /bin/sh -c cd
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 add
  -- pom.xml
  [INFO] Working directory:
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
  [INFO] Executing: /bin/sh -c cd
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
  status
  [INFO] Working directory:
  /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
  [INFO] Release preparation complete.
  [INFO]
  
  [INFO] BUILD SUCCESS
 
  You can see here that there are no git commit commands being run, this
  in turn breaks the build.
 
  A coworker who is still using Maven 3.0.4 was able to prepare and release
  the artefact fine however, so I'm wondering if there's some issue at the
  SCM layer of maven that's breaking when running under 3.1.1 that isn't an
  issue when using 3.0.4.
 
  Has anyone else seen any behaviour like this?
 
  Mark
 

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

[Mark Derricutt]

Ok - so this looks to be an issue introduced in Git 1.8.5, from
https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt

 * git status now omits the prefix to make its output a comment in a
   commit log editor, which is not necessary for human consumption.
   Scripts that parse the output of git status are advised to use
   git status --porcelain instead, as its format is stable and easier
   to parse.

From looking at the git log of
./maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java
I see that the has been using the newer git status --porcelain command
for some time now, however from walking the dependencies of
maven-release-plugin, I appear to find 1.7 being resolved ( at least via
IntellliJ ).

It looks like Olivier Lamy updated the git status support in [1] in git
commit 5c58908896a1b82bc6ee0af005adf0d6ef326395

Up until this week this didn't appear to be a problem, until Git 1.8.5 was
released and removed the leading # from the status messages

How do we get Maven to start using the newer releases of SCM - is that just
a matter of declaring a dependency in my parent pom?

Mark



[1] [SCM-686] Maven SCM failed to parse git status output if git messages
are translated - Submitted by Ralf Thielow.

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Mon, Dec 9, 2013 at 3:40 PM, Mark Derricutt m...@talios.com wrote:

 Hey all,

 Just encountered a strange issue with the maven-release-plugin, when doing
 a release:prepare from my machine using Maven 3.1.1, and
 maven-release-plugin 2.4.2 I get the following output:

 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Tagging release with the label com.smxemail.translation-13.2.9...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git tag
 -F
 /var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit
 com.smxemail.translation-13.2.9
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 ls-files
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Transforming 'com.smxemail.translation'...
 [INFO] Not removing release POMs
 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Release preparation complete.
 [INFO]
 
 [INFO] BUILD SUCCESS

 You can see here that there are no git commit commands being run, this
 in turn breaks the build.

 A coworker who is still using Maven 3.0.4 was able to prepare and release
 the artefact fine however, so I'm wondering if there's some issue at the
 SCM layer of maven that's breaking when running under 3.1.1 that isn't an
 issue when using 3.0.4.

 Has anyone else seen any behaviour like this?

 Mark

Re: maven-release-plugin: Is it possible to participate in the release phases by adding in you own extensions?

[Barrie Treloar]

On Sat, Aug 4, 2012 at 9:51 AM, Chris Graham chrisgw...@gmail.com wrote:
 On Fri, Aug 3, 2012 at 3:28 PM, Barrie Treloar baerr...@gmail.com wrote:

 On Fri, Aug 3, 2012 at 2:49 PM, Chris Graham chrisgw...@gmail.com wrote:
  Why make it so hard?
  Why cann't you filter the resources and/or package them via the assembly
 plugin.
 
  Remember that plugins still run during the release process, so why not
 use them?

 Because these are not things you can filter.
 They are Eclipse Manifest files, Feature files, etc and Eclipse needs
 to be able to read them.

 I'm missing something here. The above statement means that Eclipse needs
 to be able to read them *whilst* maven is building the package.

 Isn't Tyco for build eclipse modules? So read the end result, yes, but
 *whilst* building???

I meant Tycho (rather than Eclipse)

It needs to build the Eclipse Target Platform and it does so right at
the beginning of the lifecycle.

So there is no opportunity to filter resources.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: Is it possible to participate in the release phases by adding in you own extensions?

[Chris Graham]

On Fri, Aug 3, 2012 at 3:28 PM, Barrie Treloar baerr...@gmail.com wrote:

 On Fri, Aug 3, 2012 at 2:49 PM, Chris Graham chrisgw...@gmail.com wrote:
  Why make it so hard?
  Why cann't you filter the resources and/or package them via the assembly
 plugin.
 
  Remember that plugins still run during the release process, so why not
 use them?

 Because these are not things you can filter.
 They are Eclipse Manifest files, Feature files, etc and Eclipse needs
 to be able to read them.

 I'm missing something here. The above statement means that Eclipse needs
to be able to read them *whilst* maven is building the package.

Isn't Tyco for build eclipse modules? So read the end result, yes, but
*whilst* building???


  I don't see why you need extensions here (but then, I've just come back
 from my first loong lunch in ages!)

 Because I wanted to be able to click the Perform Maven Release in
 Jenkins and have everything taken care of.

 Otherwise I need to run a couple of things on the command line, and
 then manually tag and deploy.
 I can't use the release plugin because the pom and Eclipse files need
 to be kept in sync, and if I upgrade them to release versions outside
 of the release plugin then the release fails because there are no
 snapshots to transform.

 Admittedly this is a bunch of trivial steps I need to do to get this
 to work, but I am trying to automate and dumb down the steps.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: Is it possible to participate in the release phases by adding in you own extensions?

[Chris Graham]

Why make it so hard?
Why cann't you filter the resources and/or package them via the assembly plugin.

Remember that plugins still run during the release process, so why not use them?

I don't see why you need extensions here (but then, I've just come back from my 
first loong lunch in ages!)

-Chris

Sent from my iPhone

On 03/08/2012, at 1:41 PM, Barrie Treloar baerr...@gmail.com wrote:

 I'm almost after something like eclipse extensions here.
 My particular use case: Get
 org.eclipse.tycho:tycho-versions-plugin:set-version to update
 non-pom.xml artifacts to the release version.
 
 I'm wondering whether it is as simple as creating my own classes in a
 jar, setting up plexus, inject the dependency into
 maven-release-manager and it will find the new stuff.
 
 components-fragment.xml seems to define all the phases.
 I should be able to hook into
  phaserewrite-poms-for-release/phase
 ...
  phaserewrite-poms-for-development/phase
 
 I dont know anything about Plexus or whether what I am contemplating
 to attempt is sane.
 Thoughts welcome.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: Is it possible to participate in the release phases by adding in you own extensions?

[Hervé BOUTEMY]

isn't http://maven.apache.org/plugins/maven-release-plugin/examples/run-goals-
before-commit.html sufficient?

Le vendredi 3 août 2012 13:11:24 Barrie Treloar a écrit :
 I'm almost after something like eclipse extensions here.
 My particular use case: Get
 org.eclipse.tycho:tycho-versions-plugin:set-version to update
 non-pom.xml artifacts to the release version.
 
 I'm wondering whether it is as simple as creating my own classes in a
 jar, setting up plexus, inject the dependency into
 maven-release-manager and it will find the new stuff.
 
 components-fragment.xml seems to define all the phases.
 I should be able to hook into
   phaserewrite-poms-for-release/phase
 ...
   phaserewrite-poms-for-development/phase
 
 I dont know anything about Plexus or whether what I am contemplating
 to attempt is sane.
 Thoughts welcome.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: Is it possible to participate in the release phases by adding in you own extensions?

[Barrie Treloar]

On Fri, Aug 3, 2012 at 2:49 PM, Chris Graham chrisgw...@gmail.com wrote:
 Why make it so hard?
 Why cann't you filter the resources and/or package them via the assembly 
 plugin.

 Remember that plugins still run during the release process, so why not use 
 them?

Because these are not things you can filter.
They are Eclipse Manifest files, Feature files, etc and Eclipse needs
to be able to read them.

 I don't see why you need extensions here (but then, I've just come back from 
 my first loong lunch in ages!)

Because I wanted to be able to click the Perform Maven Release in
Jenkins and have everything taken care of.

Otherwise I need to run a couple of things on the command line, and
then manually tag and deploy.
I can't use the release plugin because the pom and Eclipse files need
to be kept in sync, and if I upgrade them to release versions outside
of the release plugin then the release fails because there are no
snapshots to transform.

Admittedly this is a bunch of trivial steps I need to do to get this
to work, but I am trying to automate and dumb down the steps.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: Is it possible to participate in the release phases by adding in you own extensions?

[Barrie Treloar]

On Fri, Aug 3, 2012 at 2:55 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 isn't http://maven.apache.org/plugins/maven-release-plugin/examples/run-goals-
 before-commit.html sufficient?

I think because the goal I want to run
  org.eclipse.tycho:tycho-versions-plugin:set-version
will also transform the pom files to release versions.
At which point the release plugin stops because it can't transform them.

And I am not sure how do pass in the version numbers I need from the
release plugin into the set-versions plugin.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven release plugin introducing scm urls into modified poms

[Ansgar Konermann]

Am 20.02.2012 06:51 schrieb Chris Graham chrisgw...@gmail.com:

 Hi All.

 I have a multi module project that I have working perfectly.

 In tracking down a reported problem, I ran the release plugin with the
 -DpreparationGoals=help:effective-pom clean verify

 In it, I can see that it has added a scm section into the poms in the
 modules. Although this is with Jazz, the same happens in SVN as well.

 The urls that are rewritten in the root pom are correctly. I've added
 the JazzScmTranslator into the release manager.

 It adds a /sub module name to the end of the URL, which in Jazz's
 case, makes no sense, but it will make sense for SVN - and it's
 correct.

 Is there a way to stop this?

Git also likes no submodule suffix in its scm urls. You could have a look
at the git scm provider how it's implemented there.

HTH

Ansgar


 This only becomes a problem, when there is a scm section in a pom in
 one of the modules, as when it is written out, it is incorrect.

 Or is this an unsupported configuration? Ie, undefined behaviour?

 -Chris

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[Ansgar Konermann]

Am 27.09.2011 14:48 schrieb David Blevins david.blev...@gmail.com:

 Is it a known issue that the release plugin does not honor the
-Darguments?

 Specifically, I'm attempting to:

  mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
 -DfailIfNoTests=false


Try:

mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
 -DfailIfNoTests=false

Notice the slightly different quoting (before -Darguments). Works well for
me.

Best regards

Ansgar

 It takes 40 minutes to get through a dryRun with tests on.  We still have
several kinks in the build to work out before the release plugin will work,
so obviously running with tests on every dryRun is just making a hard task
impossible.

 maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1


 -David


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[Benson Margulies]

This situation was discussed once before. The author of this pom, as I
recall, had pretty strong feelings about it.

You can work with it by making your own profile named apache_release
that has the additional stuff you want, or by overriding the execution
configuration in your pom to use your preferred arguments/.

On Thu, Dec 29, 2011 at 10:18 PM, David Blevins david.blev...@gmail.com wrote:
 On Tue, Sep 27, 2011 at 1:09 PM, David Blevins david.blev...@gmail.com 
 wrote:
 Did some more digging and it seems the issue is in the apache-10 parent pom. 
  If you alter it like so, the arguments are passed as expected:

    plugin
      groupIdorg.apache.maven.plugins/groupId
      artifactIdmaven-release-plugin/artifactId
      version2.1/version
      configuration
        useReleaseProfilefalse/useReleaseProfile
        goalsdeploy/goals
        !--arguments-Papache-release/arguments--
        arguments-Papache-release ${arguments}/arguments
      /configuration
    /plugin

 Seems this is just a mistake as the full config as reported via -X contains 
 quite a bit of foo${foo}/foo style declarations.  We likely just missed 
 it here.

 Going to use a hacked parent pom for the moment but it would be great if we 
 could get an apache-11 pom out soonish.

 This came up again.  Posting so I don't forget to deal with it when I
 have time.  Will file an issue with a patch tomorrow unless someone
 beats me to it.


 -David

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[David Blevins]

An FYI on the escaping/quoting as that's come up twice and isn't the issue.

public class Arguments {
public static void main(String[] args) {

for (String arg : args) {
System.out.printf([%s], arg);
}

System.out.println();
}
}


$ java Arguments mvn release:prepare -DdryRun=true 
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true 
-DfailIfNoTests=false]

$ java Arguments mvn release:prepare -DdryRun=true 
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true 
-DfailIfNoTests=false]

$ java Arguments mvn release:prepare -DdryRun=true 
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true 
-DfailIfNoTests=false]

$ java Arguments mvn release:prepare -DdryRun=true 
-Darguments=-DskipTests=true' '-DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true 
-DfailIfNoTests=false]

$ java Arguments mvn release:prepare -DdryRun=true 
-Darguments=-DskipTests=true\ -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true 
-DfailIfNoTests=false]

The next one just to be goofy :)

$ java Arguments mvn release:prepare -DdryRun=true 
-Dargum'en'ts=-Ds'k'ipTests=true\ -DfailIfNoTest's'=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true 
-DfailIfNoTests=false]

And finally an actually broken one:

$ java Arguments mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true 
-DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true][-DfailIfNoTests=false]


The problem isn't with the plugin but the Apache parent pom.  Thanks, Benson, 
for the feedback on that.  There're half dozen committers on that pom so I'm 
not sure who has the objection to allowing -Darguments to be used.

I've created this jira and attached a patch.  Hopefully we can either fix it or 
document it as intentionally not working and give reasons and workarounds like 
the ones you suggest.  I'm fine with either outcome.

  https://issues.apache.org/jira/browse/MPOM-35

On a side note,... Happy new year to all! :)


-David

On Dec 30, 2011, at 2:22 AM, Ansgar Konermann wrote:

 Am 27.09.2011 14:48 schrieb David Blevins david.blev...@gmail.com:
 
 Is it a known issue that the release plugin does not honor the
 -Darguments?
 
 Specifically, I'm attempting to:
 
 mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
 -DfailIfNoTests=false
 
 
 Try:
 
 mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
 -DfailIfNoTests=false
 
 Notice the slightly different quoting (before -Darguments). Works well for
 me.
 
 Best regards
 
 Ansgar
 
 It takes 40 minutes to get through a dryRun with tests on.  We still have
 several kinks in the build to work out before the release plugin will work,
 so obviously running with tests on every dryRun is just making a hard task
 impossible.
 
 maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
 
 
 -David
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[David Blevins]

On Tue, Sep 27, 2011 at 1:09 PM, David Blevins david.blev...@gmail.com wrote:
 Did some more digging and it seems the issue is in the apache-10 parent pom.  
 If you alter it like so, the arguments are passed as expected:

    plugin
      groupIdorg.apache.maven.plugins/groupId
      artifactIdmaven-release-plugin/artifactId
      version2.1/version
      configuration
        useReleaseProfilefalse/useReleaseProfile
        goalsdeploy/goals
        !--arguments-Papache-release/arguments--
        arguments-Papache-release ${arguments}/arguments
      /configuration
    /plugin

 Seems this is just a mistake as the full config as reported via -X contains 
 quite a bit of foo${foo}/foo style declarations.  We likely just missed 
 it here.

 Going to use a hacked parent pom for the moment but it would be great if we 
 could get an apache-11 pom out soonish.

This came up again.  Posting so I don't forget to deal with it when I
have time.  Will file an issue with a patch tomorrow unless someone
beats me to it.


-David

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Mirko Friedenhagen]

Hello,

I erroneously opened the issue in the SCM plugin
(https://jira.codehaus.org/browse/SCM-655), however it is an issue of
MRELEASE probably. Would someone with the according rights move it to
http://jira.codehaus.org/browse/MRELEASE, please?

Best regards Mirko

On Mon, Dec 19, 2011 at 22:56, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 Then it will have to be the tag name so...

 On 19 December 2011 21:28, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
 Hm, this will be a hard one. I know detected, that the rewrite of the
 SCM section happens in the maven-release-plugin
 (org.apache.maven.shared.release.phase.RewritePomsForReleasePhase).
 Two problemes I encountered now:
 - The maven-scm-plugin does not seem to implement the equivalent of
 scm:info (there is an implementation in the maven-scm-api, however).
 - Providing the hash value instead of the symbolic release tag is kind
 of a chicken-egg scenario: we know the hash only after the rewrite of
 the pom and the commit, modifying the  pom afterwards to include the
 hash as tag however does create a new hash. So inserting the hash
 seems to be impossible :-(.

 Any thoughts :-)?

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/



 On Mon, Dec 19, 2011 at 12:26, Olivier Lamy ol...@apache.org wrote:
 some scm providers have something implemented.

 for git it's : git rev-parse --verify HEAD
 for svn: svn info
 for hg: hg id

 more details on those providers in various Info command impls.

 2011/12/19 Stephen Connolly stephen.alan.conno...@gmail.com:
 On 19 December 2011 10:45, Mirko Friedenhagen mfriedenha...@gmail.com 
 wrote:
 As discussed on the user-list:

On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I know that with SVN the developerConnection and connection are
 updated to the real URL, that is when I invoke release:prepare
 with
 a URL like:
 https://SVNSERVER/svn/REPO/myproject/branches/release it will be
 replaced by
 https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
 which is fine because now I know which revision to checkout for
 building the release.

 With git there is no such possibility to realize this with
 rewriting
 the URL AFAIK. So I would have expected however, that maybe the
 tag
 element would be updated to reflect the fact, that the pom is 
 the
 one
 of release, either to the symbolic name myproject-1.0 or to 
 the
  hash
 of the tag.

 Regards Mirko

 I opened http://jira.codehaus.org/browse/SCM-655.
 As I want give it a try to implement this (at least for GIT) two 
 questions now:
 - What is preferable, symbolic tag name or hash?

 I fear it has to be hash but better would be to have it configurable

 - Is is feasible to implement such behavior in one provider only or
 should it be part of all (DVCS-)providers?

 When you've sent me the pony, then implement it for all DVCS providers
 and check that it is implemented for CVS too


 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Robert Scholte]

https://jira.codehaus.org/browse/MRELEASE-723 


 From: mfriedenha...@gmail.com
 Date: Tue, 20 Dec 2011 21:14:59 +0100
 Subject: Re: maven-release-plugin: using git where do I see the tag used to 
 build the release in the pom?
 To: dev@maven.apache.org
 
 Hello,
 
 I erroneously opened the issue in the SCM plugin
 (https://jira.codehaus.org/browse/SCM-655), however it is an issue of
 MRELEASE probably. Would someone with the according rights move it to
 http://jira.codehaus.org/browse/MRELEASE, please?
 
 Best regards Mirko
 
 On Mon, Dec 19, 2011 at 22:56, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  Then it will have to be the tag name so...
 
  On 19 December 2011 21:28, Mirko Friedenhagen mfriedenha...@gmail.com 
  wrote:
  Hm, this will be a hard one. I know detected, that the rewrite of the
  SCM section happens in the maven-release-plugin
  (org.apache.maven.shared.release.phase.RewritePomsForReleasePhase).
  Two problemes I encountered now:
  - The maven-scm-plugin does not seem to implement the equivalent of
  scm:info (there is an implementation in the maven-scm-api, however).
  - Providing the hash value instead of the symbolic release tag is kind
  of a chicken-egg scenario: we know the hash only after the rewrite of
  the pom and the commit, modifying the pom afterwards to include the
  hash as tag however does create a new hash. So inserting the hash
  seems to be impossible :-(.
 
  Any thoughts :-)?
 
  Regards Mirko
  --
  http://illegalstateexception.blogspot.com/
  https://github.com/mfriedenhagen/
  https://bitbucket.org/mfriedenhagen/
 
 
 
  On Mon, Dec 19, 2011 at 12:26, Olivier Lamy ol...@apache.org wrote:
  some scm providers have something implemented.
 
  for git it's : git rev-parse --verify HEAD
  for svn: svn info
  for hg: hg id
 
  more details on those providers in various Info command impls.
 
  2011/12/19 Stephen Connolly stephen.alan.conno...@gmail.com:
  On 19 December 2011 10:45, Mirko Friedenhagen mfriedenha...@gmail.com 
  wrote:
  As discussed on the user-list:
 
 On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
  Hello,
 
  I know that with SVN the developerConnection and connection 
  are
  updated to the real URL, that is when I invoke 
  release:prepare
  with
  a URL like:
  https://SVNSERVER/svn/REPO/myproject/branches/release it will 
  be
  replaced by
  https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
  which is fine because now I know which revision to checkout 
  for
  building the release.
 
  With git there is no such possibility to realize this with
  rewriting
  the URL AFAIK. So I would have expected however, that maybe 
  the
  tag
  element would be updated to reflect the fact, that the pom is 
  the
  one
  of release, either to the symbolic name myproject-1.0 or to 
  the
   hash
  of the tag.
 
  Regards Mirko
 
  I opened http://jira.codehaus.org/browse/SCM-655.
  As I want give it a try to implement this (at least for GIT) two 
  questions now:
  - What is preferable, symbolic tag name or hash?
 
  I fear it has to be hash but better would be to have it configurable
 
  - Is is feasible to implement such behavior in one provider only or
  should it be part of all (DVCS-)providers?
 
  When you've sent me the pony, then implement it for all DVCS providers
  and check that it is implemented for CVS too
 
 
  Regards Mirko
  --
  http://illegalstateexception.blogspot.com/
  https://github.com/mfriedenhagen/
  https://bitbucket.org/mfriedenhagen/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
  --
  Olivier Lamy
  Talend: http://coders.talend.com
  http://twitter.com/olamy | http://linkedin.com/in/olamy
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Mirko Friedenhagen]

As discussed on the user-list:

On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I know that with SVN the developerConnection and connection are
 updated to the real URL, that is when I invoke release:prepare
 with
 a URL like:
 https://SVNSERVER/svn/REPO/myproject/branches/release it will be
 replaced by
 https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
 which is fine because now I know which revision to checkout for
 building the release.

 With git there is no such possibility to realize this with
 rewriting
 the URL AFAIK. So I would have expected however, that maybe the
 tag
 element would be updated to reflect the fact, that the pom is the
 one
 of release, either to the symbolic name myproject-1.0 or to the
  hash
 of the tag.

 Regards Mirko

I opened http://jira.codehaus.org/browse/SCM-655.
As I want give it a try to implement this (at least for GIT) two questions now:
- What is preferable, symbolic tag name or hash?
- Is is feasible to implement such behavior in one provider only or
should it be part of all (DVCS-)providers?

Regards Mirko
-- 
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Stephen Connolly]

On 19 December 2011 10:45, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
 As discussed on the user-list:

On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I know that with SVN the developerConnection and connection are
 updated to the real URL, that is when I invoke release:prepare
 with
 a URL like:
 https://SVNSERVER/svn/REPO/myproject/branches/release it will be
 replaced by
 https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
 which is fine because now I know which revision to checkout for
 building the release.

 With git there is no such possibility to realize this with
 rewriting
 the URL AFAIK. So I would have expected however, that maybe the
 tag
 element would be updated to reflect the fact, that the pom is the
 one
 of release, either to the symbolic name myproject-1.0 or to the
  hash
 of the tag.

 Regards Mirko

 I opened http://jira.codehaus.org/browse/SCM-655.
 As I want give it a try to implement this (at least for GIT) two questions 
 now:
 - What is preferable, symbolic tag name or hash?

I fear it has to be hash but better would be to have it configurable

 - Is is feasible to implement such behavior in one provider only or
 should it be part of all (DVCS-)providers?

When you've sent me the pony, then implement it for all DVCS providers
and check that it is implemented for CVS too


 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Olivier Lamy]

some scm providers have something implemented.

for git it's : git rev-parse --verify HEAD
for svn: svn info
for hg: hg id

more details on those providers in various Info command impls.

2011/12/19 Stephen Connolly stephen.alan.conno...@gmail.com:
 On 19 December 2011 10:45, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
 As discussed on the user-list:

On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I know that with SVN the developerConnection and connection are
 updated to the real URL, that is when I invoke release:prepare
 with
 a URL like:
 https://SVNSERVER/svn/REPO/myproject/branches/release it will be
 replaced by
 https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
 which is fine because now I know which revision to checkout for
 building the release.

 With git there is no such possibility to realize this with
 rewriting
 the URL AFAIK. So I would have expected however, that maybe the
 tag
 element would be updated to reflect the fact, that the pom is the
 one
 of release, either to the symbolic name myproject-1.0 or to the
  hash
 of the tag.

 Regards Mirko

 I opened http://jira.codehaus.org/browse/SCM-655.
 As I want give it a try to implement this (at least for GIT) two questions 
 now:
 - What is preferable, symbolic tag name or hash?

 I fear it has to be hash but better would be to have it configurable

 - Is is feasible to implement such behavior in one provider only or
 should it be part of all (DVCS-)providers?

 When you've sent me the pony, then implement it for all DVCS providers
 and check that it is implemented for CVS too


 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Mirko Friedenhagen]

Hm, this will be a hard one. I know detected, that the rewrite of the
SCM section happens in the maven-release-plugin
(org.apache.maven.shared.release.phase.RewritePomsForReleasePhase).
Two problemes I encountered now:
- The maven-scm-plugin does not seem to implement the equivalent of
scm:info (there is an implementation in the maven-scm-api, however).
- Providing the hash value instead of the symbolic release tag is kind
of a chicken-egg scenario: we know the hash only after the rewrite of
the pom and the commit, modifying the  pom afterwards to include the
hash as tag however does create a new hash. So inserting the hash
seems to be impossible :-(.

Any thoughts :-)?

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/



On Mon, Dec 19, 2011 at 12:26, Olivier Lamy ol...@apache.org wrote:
 some scm providers have something implemented.

 for git it's : git rev-parse --verify HEAD
 for svn: svn info
 for hg: hg id

 more details on those providers in various Info command impls.

 2011/12/19 Stephen Connolly stephen.alan.conno...@gmail.com:
 On 19 December 2011 10:45, Mirko Friedenhagen mfriedenha...@gmail.com 
 wrote:
 As discussed on the user-list:

On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I know that with SVN the developerConnection and connection are
 updated to the real URL, that is when I invoke release:prepare
 with
 a URL like:
 https://SVNSERVER/svn/REPO/myproject/branches/release it will be
 replaced by
 https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
 which is fine because now I know which revision to checkout for
 building the release.

 With git there is no such possibility to realize this with
 rewriting
 the URL AFAIK. So I would have expected however, that maybe the
 tag
 element would be updated to reflect the fact, that the pom is the
 one
 of release, either to the symbolic name myproject-1.0 or to the
  hash
 of the tag.

 Regards Mirko

 I opened http://jira.codehaus.org/browse/SCM-655.
 As I want give it a try to implement this (at least for GIT) two questions 
 now:
 - What is preferable, symbolic tag name or hash?

 I fear it has to be hash but better would be to have it configurable

 - Is is feasible to implement such behavior in one provider only or
 should it be part of all (DVCS-)providers?

 When you've sent me the pony, then implement it for all DVCS providers
 and check that it is implemented for CVS too


 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom?

[Stephen Connolly]

Then it will have to be the tag name so...

On 19 December 2011 21:28, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
 Hm, this will be a hard one. I know detected, that the rewrite of the
 SCM section happens in the maven-release-plugin
 (org.apache.maven.shared.release.phase.RewritePomsForReleasePhase).
 Two problemes I encountered now:
 - The maven-scm-plugin does not seem to implement the equivalent of
 scm:info (there is an implementation in the maven-scm-api, however).
 - Providing the hash value instead of the symbolic release tag is kind
 of a chicken-egg scenario: we know the hash only after the rewrite of
 the pom and the commit, modifying the  pom afterwards to include the
 hash as tag however does create a new hash. So inserting the hash
 seems to be impossible :-(.

 Any thoughts :-)?

 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/



 On Mon, Dec 19, 2011 at 12:26, Olivier Lamy ol...@apache.org wrote:
 some scm providers have something implemented.

 for git it's : git rev-parse --verify HEAD
 for svn: svn info
 for hg: hg id

 more details on those providers in various Info command impls.

 2011/12/19 Stephen Connolly stephen.alan.conno...@gmail.com:
 On 19 December 2011 10:45, Mirko Friedenhagen mfriedenha...@gmail.com 
 wrote:
 As discussed on the user-list:

On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I know that with SVN the developerConnection and connection are
 updated to the real URL, that is when I invoke release:prepare
 with
 a URL like:
 https://SVNSERVER/svn/REPO/myproject/branches/release it will be
 replaced by
 https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
 which is fine because now I know which revision to checkout for
 building the release.

 With git there is no such possibility to realize this with
 rewriting
 the URL AFAIK. So I would have expected however, that maybe the
 tag
 element would be updated to reflect the fact, that the pom is the
 one
 of release, either to the symbolic name myproject-1.0 or to the
  hash
 of the tag.

 Regards Mirko

 I opened http://jira.codehaus.org/browse/SCM-655.
 As I want give it a try to implement this (at least for GIT) two questions 
 now:
 - What is preferable, symbolic tag name or hash?

 I fear it has to be hash but better would be to have it configurable

 - Is is feasible to implement such behavior in one provider only or
 should it be part of all (DVCS-)providers?

 When you've sent me the pony, then implement it for all DVCS providers
 and check that it is implemented for CVS too


 Regards Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[David Jencks]

IIRC you have to include your forked maven arguments in the release plugin 
configuration under
arguments-DskipTests=true  -DfailIfNoTests=false/arguments

Perhaps someone else can say _why_ the m-r-p is set up so you can't set this on 
the command line?

thanks
david jencks 

On Sep 27, 2011, at 5:40 AM, David Blevins wrote:

 Is it a known issue that the release plugin does not honor the -Darguments?
 
 Specifically, I'm attempting to:
 
  mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true  
 -DfailIfNoTests=false
 
 It takes 40 minutes to get through a dryRun with tests on.  We still have 
 several kinks in the build to work out before the release plugin will work, 
 so obviously running with tests on every dryRun is just making a hard task 
 impossible.
 
 maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
 
 
 -David
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[Stephen Connolly]

you can if you understand shell escaping.

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 27 Sep 2011 17:58, David Jencks david_jen...@yahoo.com wrote:
 IIRC you have to include your forked maven arguments in the release plugin
configuration under
 arguments-DskipTests=true -DfailIfNoTests=false/arguments

 Perhaps someone else can say _why_ the m-r-p is set up so you can't set
this on the command line?

 thanks
 david jencks

 On Sep 27, 2011, at 5:40 AM, David Blevins wrote:

 Is it a known issue that the release plugin does not honor the
-Darguments?

 Specifically, I'm attempting to:

 mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false

 It takes 40 minutes to get through a dryRun with tests on. We still have
several kinks in the build to work out before the release plugin will work,
so obviously running with tests on every dryRun is just making a hard task
impossible.

 maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1


 -David


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven release plugin not honoring -Darguments

[David Blevins]

That's not it, the quoting was fine.  Even with a single argument with no 
spaces to -Darguments it still does not work.

Did some more digging and it seems the issue is in the apache-10 parent pom.  
If you alter it like so, the arguments are passed as expected:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-release-plugin/artifactId
  version2.1/version
  configuration
useReleaseProfilefalse/useReleaseProfile
goalsdeploy/goals
!--arguments-Papache-release/arguments--
arguments-Papache-release ${arguments}/arguments
  /configuration
/plugin

Seems this is just a mistake as the full config as reported via -X contains 
quite a bit of foo${foo}/foo style declarations.  We likely just missed it 
here.

Going to use a hacked parent pom for the moment but it would be great if we 
could get an apache-11 pom out soonish.


-David


On Sep 27, 2011, at 10:54 AM, Stephen Connolly wrote:

 you can if you understand shell escaping.
 
 - Stephen
 
 ---
 Sent from my Android phone, so random spelling mistakes, random nonsense
 words and other nonsense are a direct result of using swype to type on the
 screen
 On 27 Sep 2011 17:58, David Jencks david_jen...@yahoo.com wrote:
 IIRC you have to include your forked maven arguments in the release plugin
 configuration under
 arguments-DskipTests=true -DfailIfNoTests=false/arguments
 
 Perhaps someone else can say _why_ the m-r-p is set up so you can't set
 this on the command line?
 
 thanks
 david jencks
 
 On Sep 27, 2011, at 5:40 AM, David Blevins wrote:
 
 Is it a known issue that the release plugin does not honor the
 -Darguments?
 
 Specifically, I'm attempting to:
 
 mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
 -DfailIfNoTests=false
 
 It takes 40 minutes to get through a dryRun with tests on. We still have
 several kinks in the build to work out before the release plugin will work,
 so obviously running with tests on every dryRun is just making a hard task
 impossible.
 
 maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
 
 
 -David
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Jörg Schaible]

Hi Brett,

Brett Porter wrote:

 
 
 On 17/09/2010, at 2:23 AM, Jörg Schaible wrote:
 
 Hi Baptiste,
 
 Baptiste MATHUS wrote:
 
 Well, from my understanding, this is not a regression.
 What Paul says in the end
 
 
http://jira.codehaus.org/browse/MNG-4687?focusedCommentId=235494page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-
 tabpanel#action_235494is
 not a workaround, but the right way to go.
 
 It *is* a regression with the release plugin, if you cannot release with
 such a pom. See the first comment.
 
 If I understand correctly, it's more that the release plugin doesn't yet
 understand relativePath/releativePath, which is something new in Maven
 3 to represent no relative path for the warning?

Yep. That's what the reporter in the first comment said.

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Baptiste MATHUS]

I answered that since I opened the attached test project, and I didn't see
any relativePath tag anywhere (though I might have missed it).

Cheers

2010/9/17 Jörg Schaible joerg.schai...@gmx.de

 Hi Brett,

 Brett Porter wrote:

 
 
  On 17/09/2010, at 2:23 AM, Jörg Schaible wrote:
 
  Hi Baptiste,
 
  Baptiste MATHUS wrote:
 
  Well, from my understanding, this is not a regression.
  What Paul says in the end
 
 

 http://jira.codehaus.org/browse/MNG-4687?focusedCommentId=235494page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-
  tabpanel#action_235494is
  not a workaround, but the right way to go.
 
  It *is* a regression with the release plugin, if you cannot release with
  such a pom. See the first comment.
 
  If I understand correctly, it's more that the release plugin doesn't yet
  understand relativePath/releativePath, which is something new in
 Maven
  3 to represent no relative path for the warning?

 Yep. That's what the reporter in the first comment said.

 - Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: maven-release-plugin release?

[Jörg Schaible]

Baptiste MATHUS wrote:

 I answered that since I opened the attached test project, and I didn't see
 any relativePath tag anywhere (though I might have missed it).

The problem is that the author of comment #1 did not open a new issue for 
the release plugin but used instead this maven issue to report a problem 
with the proposed solution. However, if a new release of the release plugin 
is coming, it should work now flawlessly with M3 (resp. the documented 
migration solutions).

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Brett Porter]

So... does someone want to open it? :)

On 17/09/2010, at 1:07 AM, Jörg Schaible wrote:

 Baptiste MATHUS wrote:
 
 I answered that since I opened the attached test project, and I didn't see
 any relativePath tag anywhere (though I might have missed it).
 
 The problem is that the author of comment #1 did not open a new issue for 
 the release plugin but used instead this maven issue to report a problem 
 with the proposed solution. However, if a new release of the release plugin 
 is coming, it should work now flawlessly with M3 (resp. the documented 
 migration solutions).
 
 - Jörg
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Brett Porter]

On 17/09/2010, at 1:07 AM, Jörg Schaible wrote:

 Baptiste MATHUS wrote:
 
 I answered that since I opened the attached test project, and I didn't see
 any relativePath tag anywhere (though I might have missed it).
 
 The problem is that the author of comment #1 did not open a new issue for 
 the release plugin but used instead this maven issue to report a problem 
 with the proposed solution. However, if a new release of the release plugin 
 is coming, it should work now flawlessly with M3 (resp. the documented 
 migration solutions).

Ok. Would someone familiar with the issue like to open it with the appropriate 
amount of detail?

Thanks,
Brett


--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Jörg Schaible]

Brett Porter wrote:

 
 On 15/09/2010, at 2:26 PM, Mark Derricutt wrote:
 
 Hey guys,
 
 I was wondering what was happening with the new release of the
 maven-release-plugin?  Things seemed to go quiet on that front this past
 week or so...
 
 I see that the SCM plugin got released tho, would be good to get the
 release plugin to come along for the ride as well...
 
 Yah, I lost the window of opportunity I had originally, and things have
 kept coming up since.
 
 I'm getting back to it now... there were nearly 30 issues with recent
 patches on them that I'd like to have a quick look at, then try for the
 release again.
 
 Beyond that, there's another 30 issues marked as having patches that are
 somewhat older that would be worth going through and a number of highly
 voted issues that seem fixable. Might be good for a follow up release.

There's also a regression reported in:
http://jira.codehaus.org/browse/MNG-4687

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Baptiste MATHUS]

Well, from my understanding, this is not a regression.
What Paul says in the end
http://jira.codehaus.org/browse/MNG-4687?focusedCommentId=235494page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_235494is
not a workaround, but the right way to go.

See also
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-ParentPOMResolutionor
http://docs.codehaus.org/display/MAVENUSER/Iron+Fist+of+Maven+3.0+transition+pack

Cheers.

2010/9/16 Jörg Schaible joerg.schai...@gmx.de

 Brett Porter wrote:

 
  On 15/09/2010, at 2:26 PM, Mark Derricutt wrote:
 
  Hey guys,
 
  I was wondering what was happening with the new release of the
  maven-release-plugin?  Things seemed to go quiet on that front this past
  week or so...
 
  I see that the SCM plugin got released tho, would be good to get the
  release plugin to come along for the ride as well...
 
  Yah, I lost the window of opportunity I had originally, and things have
  kept coming up since.
 
  I'm getting back to it now... there were nearly 30 issues with recent
  patches on them that I'd like to have a quick look at, then try for the
  release again.
 
  Beyond that, there's another 30 issues marked as having patches that are
  somewhat older that would be worth going through and a number of highly
  voted issues that seem fixable. Might be good for a follow up release.

 There's also a regression reported in:
 http://jira.codehaus.org/browse/MNG-4687

 - Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: maven-release-plugin release?

[Jörg Schaible]

Hi Baptiste,

Baptiste MATHUS wrote:

 Well, from my understanding, this is not a regression.
 What Paul says in the end
 
http://jira.codehaus.org/browse/MNG-4687?focusedCommentId=235494page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-
tabpanel#action_235494is
 not a workaround, but the right way to go.

It *is* a regression with the release plugin, if you cannot release with 
such a pom. See the first comment.

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Brett Porter]

On 17/09/2010, at 2:23 AM, Jörg Schaible wrote:

 Hi Baptiste,
 
 Baptiste MATHUS wrote:
 
 Well, from my understanding, this is not a regression.
 What Paul says in the end
 
 http://jira.codehaus.org/browse/MNG-4687?focusedCommentId=235494page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-
 tabpanel#action_235494is
 not a workaround, but the right way to go.
 
 It *is* a regression with the release plugin, if you cannot release with 
 such a pom. See the first comment.

If I understand correctly, it's more that the release plugin doesn't yet 
understand relativePath/releativePath, which is something new in Maven 3 to 
represent no relative path for the warning?

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-release-plugin release?

[Brett Porter]

On 15/09/2010, at 2:26 PM, Mark Derricutt wrote:

 Hey guys,
 
 I was wondering what was happening with the new release of the
 maven-release-plugin?  Things seemed to go quiet on that front this past
 week or so...
 
 I see that the SCM plugin got released tho, would be good to get the release
 plugin to come along for the ride as well...

Yah, I lost the window of opportunity I had originally, and things have kept 
coming up since.

I'm getting back to it now... there were nearly 30 issues with recent patches 
on them that I'd like to have a quick look at, then try for the release again.

Beyond that, there's another 30 issues marked as having patches that are 
somewhat older that would be worth going through and a number of highly voted 
issues that seem fixable. Might be good for a follow up release.

- Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Release Plugin Question

[Brian Fox]

You may want to take a look at the enforcer plugin and the rules, many
of the release criteria checks are already implemented as enforcer
rules. If you build something that could consume the enforcer rule
api, that would be pretty handy at least for the validation parts of
the release process.

On Tue, Aug 11, 2009 at 11:48 AM, Hubert Iwaniukneo...@kungfoo.pl wrote:
 Hi *,
 We've been trying to build our internal release tools based on maven-release
 infrastructure.
 We failed when we tried to add new properties to configuration.

 Now we are building maven plugin that will feature a bit extended concept of
 ReleasePhase
 (added dependencies between phases) and plugability (similar to
 MOJO/maven-plugin style).
 Once we are done users will be able to compose they own release procedures
 out of available
 release-plugins, and will have some default chains preconfigured.

 If we would port current maven-release infrastructure to our model, having
 as acceptance criteria integrations tests that
 are already available in maven-release, would you guys be interested in
 having this contribution?

 Regards,
   Hubert.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: maven-release-plugin: useReleaseProfile - how does this work to add sources and javadocs?

[Brian E. Fox]

The release profile is built into the superpom.
http://svn.eu.apache.org/viewvc/maven/components/branches/maven-2.1.x/ma
ven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml?vi
ew=markup

-Original Message-
From: Barrie Treloar [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 10, 2008 9:29 PM
To: Maven Developers List
Subject: maven-release-plugin: useReleaseProfile - how does this work to
add sources and javadocs?

I'm looking at the code for maven-release-plugin and I can't see how
it add sources and javadocs.

RunPerformGoalsPhase is about the only interesting place that
isUseReleaseProfile() is used and all it does is add
-DperformRelease=true to additionalArguments which is then passed
into mavenExecutor.executeGoals()

But nothing has modified the pom internally to add the sources/javadocs
plugins.

It looks like I need to add my own profile to my pom which is
activated on performRelease=true to hook in sources and javadocs.

Any de-mystifying guidance out there?
Cheers
Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-release-plugin: useReleaseProfile - how does this work to add sources and javadocs?

[Barrie Treloar]

On Tue, Nov 11, 2008 at 1:23 PM, Brian E. Fox [EMAIL PROTECTED] wrote:
 The release profile is built into the superpom.
 http://svn.eu.apache.org/viewvc/maven/components/branches/maven-2.1.x/ma
 ven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml?vi
 ew=markup

Thanks.

Now I have to remember why I wanted this information.
Probably to see if I could hook into this profile for adding my own stuff.

Cheers

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-release-plugin svn branch command failed

[Arnaud HERITIER]

The beta-8 was just released but I didn't notice this bug when I tried it.

You can try the 2.0-beta-7

If it doesn't solve your problem you can try to change you're svn version
like Borut proposes.
If it solves it, you can open an issue ;-)

On Tue, Nov 4, 2008 at 3:11 PM, Peter Nedonosko 
[EMAIL PROTECTED] wrote:

 Hi,

 Thank you for fast feedback!

 2008/11/4 Arnaud HERITIER [EMAIL PROTECTED]

 Hi Peter,

   which version of the release plugin are you using? We just released a
 new version, perhaps there's an issue in it ?


 I use 2.0-beta-8 version of the plugin.
 Which version do you release?



   If you didn't change your version of the plugin it's probably an issue
 in svn because you are reproducing the issue with the svn command line.
   There are several problems to create tags with svn 1.5.x. I thought it
 was fixed, but I'm not sure. There was several threads about this on this
 mailing list.

 cheers

 Arnaud


 On Tue, Nov 4, 2008 at 1:59 PM, Peter Nedonosko 
 [EMAIL PROTECTED] wrote:

 Hi guys!

 I try to use maven-release-plugin on WindowsXP SP2 with maven 2.0.8, Java
 1.5.0_15 and svn 1.5.4.

 I cannot run release:branch goal from trunk successful.
 Branch commit failed on command
   svn --non-interactive copy --file D:\Tmp\maven-scm-1276451448.commit .

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC

 I have tried this command manually
  svn copy .

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC
 it fails too.

 But if I replace '.' on full path of the trunk it will works
  svn copy
 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/trunk

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC

 I feel it's a bug, but may be I do smth wrong here?
 Anybody can help or comment the usecase?


 Full error message

 [INFO]
 
 [INFO] Building eXo Kernel
 [INFO]task-segment: [release:branch] (aggregator-style)
 [INFO]
 
 [INFO] [release:branch]
 [INFO] Verifying that there are no local modifications...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive status
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 What is the new working copy version for eXo Kernel?
 (org.exoplatform.kernel:config) 2.0.5-SNAPSHOT: :
 [INFO] Transforming 'eXo Kernel'...
 [INFO] Transforming 'eXo Kernel Commons'...
 [INFO] Transforming 'eXo Container'...
 [INFO] Updating exo.kernel.commons to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Common service'...
 [INFO] Updating exo.kernel.container to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Remote service implementation'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Cache service api'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Updating exo.kernel.component.remote to 2.0.4-SNAPSHOT
 [INFO] Updating exo.kernel.container to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Command service impl'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Checking in modified POMs...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive commit --file
 D:\Tmp\maven-scm-142291247.commit --targets
 D:\Tmp\maven-scm-61108-targets
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 [INFO] Branching release with the label 2.0.4-RC...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive copy --file
 D:\Tmp\maven-scm-1276451448.commit .
 http://svn.exoplatform.org/svnroot/exoplatform/projects/
 kernel-new/branches/2.0.4-RChttp://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC
 
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
 branch SCM
 Provider message:
 The svn branch command failed.
 Command output:
 svn: Commit failed (details follow):
 svn: File

 '/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC/commons/pom.xml'
 already exists

at

 org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
at

 org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
at

 org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
at

 org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
at

 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at

 

Re: maven-release-plugin svn branch command failed

[Peter Nedonosko]

Hi,

Thank you for fast feedback!

2008/11/4 Arnaud HERITIER [EMAIL PROTECTED]

 Hi Peter,

   which version of the release plugin are you using? We just released a new
 version, perhaps there's an issue in it ?


I use 2.0-beta-8 version of the plugin.
Which version do you release?



   If you didn't change your version of the plugin it's probably an issue in
 svn because you are reproducing the issue with the svn command line.
   There are several problems to create tags with svn 1.5.x. I thought it
 was fixed, but I'm not sure. There was several threads about this on this
 mailing list.

 cheers

 Arnaud


 On Tue, Nov 4, 2008 at 1:59 PM, Peter Nedonosko 
 [EMAIL PROTECTED] wrote:

 Hi guys!

 I try to use maven-release-plugin on WindowsXP SP2 with maven 2.0.8, Java
 1.5.0_15 and svn 1.5.4.

 I cannot run release:branch goal from trunk successful.
 Branch commit failed on command
   svn --non-interactive copy --file D:\Tmp\maven-scm-1276451448.commit .

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC

 I have tried this command manually
  svn copy .

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC
 it fails too.

 But if I replace '.' on full path of the trunk it will works
  svn copy
 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/trunk

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC

 I feel it's a bug, but may be I do smth wrong here?
 Anybody can help or comment the usecase?


 Full error message

 [INFO]
 
 [INFO] Building eXo Kernel
 [INFO]task-segment: [release:branch] (aggregator-style)
 [INFO]
 
 [INFO] [release:branch]
 [INFO] Verifying that there are no local modifications...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive status
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 What is the new working copy version for eXo Kernel?
 (org.exoplatform.kernel:config) 2.0.5-SNAPSHOT: :
 [INFO] Transforming 'eXo Kernel'...
 [INFO] Transforming 'eXo Kernel Commons'...
 [INFO] Transforming 'eXo Container'...
 [INFO] Updating exo.kernel.commons to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Common service'...
 [INFO] Updating exo.kernel.container to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Remote service implementation'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Cache service api'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Updating exo.kernel.component.remote to 2.0.4-SNAPSHOT
 [INFO] Updating exo.kernel.container to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Command service impl'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Checking in modified POMs...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive commit --file
 D:\Tmp\maven-scm-142291247.commit --targets
 D:\Tmp\maven-scm-61108-targets
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 [INFO] Branching release with the label 2.0.4-RC...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive copy --file
 D:\Tmp\maven-scm-1276451448.commit .
 http://svn.exoplatform.org/svnroot/exoplatform/projects/
 kernel-new/branches/2.0.4-RChttp://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC
 
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
 branch SCM
 Provider message:
 The svn branch command failed.
 Command output:
 svn: Commit failed (details follow):
 svn: File

 '/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC/commons/pom.xml'
 already exists

at

 org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
at

 org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
at

 org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
at

 org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
at

 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at

 

Re: maven-release-plugin svn branch command failed

[Arnaud HERITIER]

Hi Peter,

  which version of the release plugin are you using? We just released a new
version, perhaps there's an issue in it ?
  If you didn't change your version of the plugin it's probably an issue in
svn because you are reproducing the issue with the svn command line.
  There are several problems to create tags with svn 1.5.x. I thought it was
fixed, but I'm not sure. There was several threads about this on this
mailing list.

cheers

Arnaud

On Tue, Nov 4, 2008 at 1:59 PM, Peter Nedonosko 
[EMAIL PROTECTED] wrote:

 Hi guys!

 I try to use maven-release-plugin on WindowsXP SP2 with maven 2.0.8, Java
 1.5.0_15 and svn 1.5.4.

 I cannot run release:branch goal from trunk successful.
 Branch commit failed on command
   svn --non-interactive copy --file D:\Tmp\maven-scm-1276451448.commit .

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC

 I have tried this command manually
  svn copy .

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC
 it fails too.

 But if I replace '.' on full path of the trunk it will works
  svn copy
 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/trunk

 http://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC

 I feel it's a bug, but may be I do smth wrong here?
 Anybody can help or comment the usecase?


 Full error message

 [INFO]
 
 [INFO] Building eXo Kernel
 [INFO]task-segment: [release:branch] (aggregator-style)
 [INFO]
 
 [INFO] [release:branch]
 [INFO] Verifying that there are no local modifications...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive status
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 What is the new working copy version for eXo Kernel?
 (org.exoplatform.kernel:config) 2.0.5-SNAPSHOT: :
 [INFO] Transforming 'eXo Kernel'...
 [INFO] Transforming 'eXo Kernel Commons'...
 [INFO] Transforming 'eXo Container'...
 [INFO] Updating exo.kernel.commons to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Common service'...
 [INFO] Updating exo.kernel.container to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Remote service implementation'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Cache service api'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Updating exo.kernel.component.remote to 2.0.4-SNAPSHOT
 [INFO] Updating exo.kernel.container to 2.0.4-SNAPSHOT
 [INFO] Transforming 'Command service impl'...
 [INFO] Updating exo.kernel.component.common to 2.0.4-SNAPSHOT
 [INFO] Checking in modified POMs...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive commit --file
 D:\Tmp\maven-scm-142291247.commit --targets D:\Tmp\maven-scm-61108-targets
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 [INFO] Branching release with the label 2.0.4-RC...
 [INFO] Executing: cmd.exe /X /C svn --non-interactive copy --file
 D:\Tmp\maven-scm-1276451448.commit .
 http://svn.exoplatform.org/svnroot/exoplatform/projects/
 kernel-new/branches/2.0.4-RChttp://svn.exoplatform.org/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC
 
 [INFO] Working directory:
 D:\Projects\eXo\dev\projects\projects-lab\kernel-new\trunk
 org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
 branch SCM
 Provider message:
 The svn branch command failed.
 Command output:
 svn: Commit failed (details follow):
 svn: File

 '/svnroot/exoplatform/projects/kernel-new/branches/2.0.4-RC/commons/pom.xml'
 already exists

at

 org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
at

 org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
at

 org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
at

 org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
at

 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
   

[Fwd: Re: maven-release-plugin not able to locate extensions]

[Sahoo]

Any comments??? Please 'cc' me in the response as I am not in this alias.

Thanks,
Sahoo
---BeginMessage---

Wendy Smoak wrote:

On Wed, Oct 15, 2008 at 3:50 AM, Sahoo [EMAIL PROTECTED] wrote:

  

As you can see, it uses a packaging type called distribution-fragment, which
is understood by our own extension called
org.glassfish.build:maven-glassfish-extension. We build the extension as
part of the same reactor.



Try configuring the release plugin to run all the way through
'install' rather than through 'integration-test' which is the default.

This isn't ideal, as you're building the artifact with the released
version in the filename _before_ the 'perform release' step, but there
are certain situations where it can't find things in the reactor.

  
First of all, thank you very much for taking the time to read my email 
and suggesting something. I tried your suggestion as shown below:
mvn -o release:prepare -DautoVersionSubmodules=true -DdryRun=true 
-DpreparationGoals=clean install

, but it fails with same error.

Thanks,
Sahoo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---End Message---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven release plugin

[Rémy Sanlaville]

Hi,

ping again...

2008/9/25 Olivier Lamy [EMAIL PROTECTED]

 Oups (it looks my name here in the previous email :-) ).

 I can but first I'd like to release invoker plugin 1.3.


Now that maven invoker plugin 1.3  is released (cf.
http://www.nabble.com/-ANN--Maven-Invoker-Plugin-1.3-Released-td19727479.html#a19727479),
is that possible to release maven release plugin ?

Thanks,

Rémy

Re: Maven release plugin

[Olivier Lamy]

Hi,
I have a current vote pending for maven-resources-plugin.
And there is 3 issues open for release [1].
IMHO we can move this to a next version.
And for MRELEASE-3, perso I'd like to mark it as won't fix or move it
to MNG (there is a workaround and IMHO it's not a release plugin
issue).
Others ?
--
Olivier
[1] 
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=11144fixfor=13812

2008/10/15 Rémy Sanlaville [EMAIL PROTECTED]:
 Hi,

 ping again...

 2008/9/25 Olivier Lamy [EMAIL PROTECTED]

 Oups (it looks my name here in the previous email :-) ).

 I can but first I'd like to release invoker plugin 1.3.


 Now that maven invoker plugin 1.3  is released (cf.
 http://www.nabble.com/-ANN--Maven-Invoker-Plugin-1.3-Released-td19727479.html#a19727479),
 is that possible to release maven release plugin ?

 Thanks,

 Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven release plugin

[Olivier Lamy]

Oups (it looks my name here in the previous email :-) ).

I can but first I'd like to release invoker plugin 1.3.

--
Olivier

2008/9/24 Arnaud HERITIER [EMAIL PROTECTED]:
 Someone wants to take the lead ?
 there are 2 issues to fix in the roadmap

 Arnaud

 On Wed, Sep 24, 2008 at 6:36 PM, Zucchi Alessandro 
 [EMAIL PROTECTED] wrote:


 Olivier Lamy said:

 Hi,
 Personnaly, I have planned to do it near end of September. 

 I hope will be so.
 Bye







 Remy Sanlaville wrote:
 
  Hi,
 
  ping: Someone know when the  2.0-beta-8 of maven release plugin will be
  released ?
  We are really waiting for it.
 
  Thanks,
 
  Rémy
 
 

 --
 View this message in context:
 http://www.nabble.com/Maven-release-plugin-tp19269992p19652882.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 ..
 Arnaud HERITIER
 ..
 OCTO Technology - aheritier AT octo DOT com
 www.octo.com | blog.octo.com
 ..
 ASF - aheritier AT apache DOT org
 www.apache.org | maven.apache.org
 ...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven release plugin

[Wendy Smoak]

On Wed, Sep 24, 2008 at 10:04 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote:
 Someone wants to take the lead ?
 there are 2 issues to fix in the roadmap

If they are not regressions, and no one is actively working on them,
then let's push them out to the next version and get the work that's
already been done, released.

-- 
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven release plugin

[Arnaud HERITIER]

Someone wants to take the lead ?
there are 2 issues to fix in the roadmap

Arnaud

On Wed, Sep 24, 2008 at 6:36 PM, Zucchi Alessandro 
[EMAIL PROTECTED] wrote:


 Olivier Lamy said:

 Hi,
 Personnaly, I have planned to do it near end of September. 

 I hope will be so.
 Bye







 Remy Sanlaville wrote:
 
  Hi,
 
  ping: Someone know when the  2.0-beta-8 of maven release plugin will be
  released ?
  We are really waiting for it.
 
  Thanks,
 
  Rémy
 
 

 --
 View this message in context:
 http://www.nabble.com/Maven-release-plugin-tp19269992p19652882.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: Maven Release Plugin - 2.0-beta-7 and MRELEASE-326

[hirowla]

Any updates on this?


hirowla wrote:
 
 Is anybody working on this but not updated in JIRA? This problem prevents 
 any automated use of the plugin.
 
 Thanks,
 
 Ian
 
 
 
 
 Disclaimer: The information transmitted is intended only for the person or
 entity to which it is addressed and may contain confidential and/or
 privileged material. Any review, retransmission, dissemination or other
 use of, or taking of any action in reliance upon, this information by
 persons or entities other than the intended recipient is prohibited. If
 you received this in error, please contact the sender and delete the
 material from your computer.
 Privacy: If you are responding to this email or providing personal
 information to the SRO for the purposes of one of the Acts it administers,
 such information  is used only for the purpose for which it was collected
 (administration of SRO legislation ) and is protected by the Information
 Privacy Act 2000 and secrecy provisions contained in legislation
 administered by SRO. It is not disclosed otherwise than in accordance with
 the law. If you would like a copy of the SRO Privacy Policy please refer
 to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and
 request a copy.
 

-- 
View this message in context: 
http://www.nabble.com/Maven-Release-Plugin---2.0-beta-7-and-MRELEASE-326-tp17860402p17998598.html
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven release plugin question

[Paul Gier]

I tested the plugin without the requiresDependencyResolution parameter, and it 
was still able to find test scope snapshots.  So I don't think it needs that to 
find snapshot versions.


I looked into the issue a bit more, and I was wrong about the cause of the 
problem.  Maven tricked me!  The issue is actually caused by a bug in the maven 
jar plugin (setting the wrong artifact type), and it occurs anytime you have 
test-jar inter-module dependencies and you try to run something like mvn 
verify without the test jar installed locally.


Can someone unlink the MNG-2277 issue dependency?  It looks like this problem 
will go away with the next release of the jar plugin.


Thanks!


Brian E. Fox wrote:

Maybe they want to check that no test dependencies are snapshots either?

-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 22, 2007 5:36 PM

To: Maven Developers List
Subject: Maven release plugin question

Hi All,
Does anyone know why the release plugin requires test scope dependency 
resolution?  I was looking into this issue:

http://jira.codehaus.org/browse/MRELEASE-285

And I found that if I remove this:
@requiresDependencyResolution test

The issue is resolved and all of the unit tests still pass.  This issue
is a 
PITA for me because it means that any multi-module project with test
scope 
intermodule deps cannot use the release plugin.


Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven release plugin question

[Brian E. Fox]

Done.

-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 23, 2007 3:54 PM
To: Maven Developers List
Cc: Brian E. Fox
Subject: Re: Maven release plugin question

I tested the plugin without the requiresDependencyResolution parameter,
and it 
was still able to find test scope snapshots.  So I don't think it needs
that to 
find snapshot versions.

I looked into the issue a bit more, and I was wrong about the cause of
the 
problem.  Maven tricked me!  The issue is actually caused by a bug in
the maven 
jar plugin (setting the wrong artifact type), and it occurs anytime you
have 
test-jar inter-module dependencies and you try to run something like
mvn 
verify without the test jar installed locally.

Can someone unlink the MNG-2277 issue dependency?  It looks like this
problem 
will go away with the next release of the jar plugin.

Thanks!


Brian E. Fox wrote:
 Maybe they want to check that no test dependencies are snapshots
either?
 
 -Original Message-
 From: Paul Gier [mailto:[EMAIL PROTECTED] 
 Sent: Monday, October 22, 2007 5:36 PM
 To: Maven Developers List
 Subject: Maven release plugin question
 
 Hi All,
 Does anyone know why the release plugin requires test scope dependency

 resolution?  I was looking into this issue:
 http://jira.codehaus.org/browse/MRELEASE-285
 
 And I found that if I remove this:
 @requiresDependencyResolution test
 
 The issue is resolved and all of the unit tests still pass.  This
issue
 is a 
 PITA for me because it means that any multi-module project with test
 scope 
 intermodule deps cannot use the release plugin.
 
 Thanks!
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Maven release plugin question

[Brian E. Fox]

Maybe they want to check that no test dependencies are snapshots either?

-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 22, 2007 5:36 PM
To: Maven Developers List
Subject: Maven release plugin question

Hi All,
Does anyone know why the release plugin requires test scope dependency 
resolution?  I was looking into this issue:
http://jira.codehaus.org/browse/MRELEASE-285

And I found that if I remove this:
@requiresDependencyResolution test

The issue is resolved and all of the unit tests still pass.  This issue
is a 
PITA for me because it means that any multi-module project with test
scope 
intermodule deps cannot use the release plugin.

Thanks!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]