Re: Maven Release Plugin - Reopen MRELEASE-282

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 con

Re: Maven Release Plugin 3.0.0-M6

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.

Re: Maven Release Plugin 3.0.0-M6

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.apach

Re: Maven Release Plugin 3.0.0-M6

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 th

Re: Maven Release Plugin 3.0.0-M6

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/jir

Re: Maven Release Plugin 3.0.0-M6

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 Berrigau

Re: Maven Release Plugin 3.0.0-M6

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 > >

Re: Maven Release Plugin 3.0.0-M6

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 Mil

Re: Maven Release Plugin 3.0.0-M6

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! ---

Re: Maven Release Plugin 3.0.0-M6

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

Re: Maven Release Plugin 3.0.0-M6

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

Re: Maven Release Plugin 3.0.0-M6

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 MRELEA

Re: [maven-release] branch master updated: update to 3.0.18 (#48)

I reverted this commit, because it broke the master build https://builds.apache.org/job/maven-box/job/maven-release/job/master/ On 12-4-2020 21:47:02, elh...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. elharo pushed a commit to branch master in reposito

Re: Maven release procedure website is broken

Looks like that has moved to https://infra.apache.org/maven-releases.html On Sat, Mar 28, 2020 at 12:50 PM Enrico Olivelli wrote: > > Hi, > it looks like we have problems on the website > https://maven.apache.org/developers/release/maven-project-release-procedure.html > > the link to > https://w

Re: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

I wrote an extra integration test, it confirms still change is indeed required to match the original requirements. Robert On 27-10-2019 20:26:37, Petar Tahchiev wrote: I think it's fine. I don't think it's going to break anything. For some reason these changes got left behind and I had to add t

Re: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

I think it's fine. I don't think it's going to break anything. For some reason these changes got left behind and I had to add them. На нд, 27.10.2019 г. в 21:00 ч. Robert Scholte написа: > I thought this was already fixed (as the issue is closed). I remember we > had a discussion about the solut

Re: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

I thought this was already fixed (as the issue is closed). I remember we had a discussion about the solution, just want to be sure you don't break anything. This should already have been covered by an integrationtest, so I'm suprised by this change. On 27-10-2019 19:46:25, Petar Tahchiev wrote:

Re: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

Hi Robert, yes I noticed today it somehow was left behind. As the message in the commit says it is for MRELEASE-985 and we need it to be able to override certain dependency versions from command line. На нд, 27.10.2019 г. в 20:35 ч. Robert Scholte написа: > Hi Petar, > > Is this related to http

Re: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

Hi Petar,  Is this related to https://issues.apache.org/jira/browse/MRELEASE-985 [https://issues.apache.org/jira/browse/MRELEASE-985] ?  Robert On 27-10-2019 08:22:12, ptahch...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. ptahchiev pushed a commit to b

Re: Maven release plugin

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:per

Re: Maven release plugin

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 >

Re: Maven release plugin

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 anythi

Re: Maven release plugin

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 >

Re: maven-release-plugin and signing artifacts

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 arg

Re: maven-release-plugin and signing artifacts

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} Tha

Re: maven-release-plugin and signing artifacts

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 Ma

Re: Maven release plugin

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 rele

Re: Maven release plugin

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] >

Re: Maven release plugin

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] /\

Re: Maven release plugin

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:perfo

Re: Maven release plugin

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

Re: Maven release plugin

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

Re: Maven release plugin

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 t

Re: Maven release plugin

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 rel

Re: Maven release plugin

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

Re: Maven Release Plugin And A BOM

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 - Resolv

Re: Maven Release Plugin And A BOM

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 recreat

Re: Maven Release Plugin And A BOM

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 : > Peta

Re: Maven Release Plugin And A BOM

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 > plat

Re: Maven Release Plugin And A BOM

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

Re: Maven Release Plugin And A BOM

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. Oth

RE: Maven Release Plugin And A BOM

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,

Re: Maven Release Version Policy

> ok, then what could be done is only a check afterwards that the version > chosen > by the user is consistent with measures on code evolutions So we are back on version policy I think. Only check and stop the release based on the policy. > another idea: perhaps we should have the API propose mu

Re: Maven Release Version Policy

vanaf Samsung Mobile. > > > > Oorspronkelijk bericht Van: Uwe Barthel > > > Datum:31-10-2015 > 05:45 (GMT-08:00) > > Aan: Maven Developers List > > > Onderwerp: Re: Maven Release Version Policy > > > > great: what is the

Re: Maven Release Version Policy

; > Robert > > Verzonden vanaf Samsung Mobile. > > Oorspronkelijk bericht Van: Uwe Barthel > Datum:31-10-2015 05:45 (GMT-08:00) > Aan: Maven Developers List > Onderwerp: Re: Maven Release Version Policy > > great: what is the bundle-maven-plugin feat

Re: Maven Release Version Policy

ung Mobile. Oorspronkelijk bericht Van: Stephen Connolly Datum:31-10-2015 12:16 (GMT-08:00) Aan: Maven Developers List Onderwerp: Re: Maven Release Version Policy On Saturday 31 October 2015, Hervé BOUTEMY wrote: > if there is a regression, why not just open a Jira issue and f

Re: Maven Release Version Policy

On Saturday 31 October 2015, Hervé BOUTEMY wrote: > if there is a regression, why not just open a Jira issue and fix it? IIRC when I pointed out the bug 6-9 months ago Robert or somebody said that the new behaviour was by design... > > I had a look at code, and it seems there is not any unit

Re: Maven Release Version Policy

if there is a regression, why not just open a Jira issue and fix it? I had a look at code, and it seems there is not any unit test against default version policy Regards, Hervé Le samedi 31 octobre 2015 17:41:45 Stephen Connolly a écrit : > On Saturday 31 October 2015, Hervé BOUTEMY wrote: >

Re: Maven Release Version Policy

On Saturday 31 October 2015, Hervé BOUTEMY wrote: > I don't know what "Cloudbees conventions" are, and how they are superior to > everything else = what I understand from the README I jusj had to put a readme quickly. It is basically increment the least significant segment (which is what the r

Re: Maven Release Version Policy

ok great! IIUC, it calculates version per package, based on automatic API comparison for release plugin, we need to calculate a version of the whole artifact. And since it's java, not OSGi, then there is no strict separation between API and internal details, I fear such approach won't give a g

Re: Maven Release Version Policy

Barthel Datum:31-10-2015 05:45 (GMT-08:00) Aan: Maven Developers List Onderwerp: Re: Maven Release Version Policy > great: what is the bundle-maven-plugin feature you're talking about? The ‘baseline’[1] goal. It based on the BND Tool[2] (by Peter Kriens), gets the previous release (!) a

Re: Maven Release Version Policy

> great: what is the bundle-maven-plugin feature you're talking about? The ‘baseline’[1] goal. It based on the BND Tool[2] (by Peter Kriens), gets the previous release (!) and check the difference between the byte code. Following semver, any new method (new feature) requires a new minor change. C

Re: Maven Release Version Policy

great: what is the bundle-maven-plugin feature you're talking about? Regards, Hervé Le samedi 31 octobre 2015 13:18:35 Uwe Barthel a écrit : > > I'm not sure "strict semver" can be automated: functional change can't be > > easily detected if there is no API change > > The bundle-maven-plugin be

Re: Maven Release Version Policy

> I'm not sure "strict semver" can be automated: functional change can't be > easily detected if there is no API change The bundle-maven-plugin behaviour is a good base to discuss about I think. mit freundlichen Grüßen Uwe Barthel -- bart...@x-reizend.de > On 31 Oct 2015, at 12:32, Hervé BOUT

Re: Maven Release Version Policy

> by that you mean you expect a version policy implementation that runs a > bytecode check against previous version (like clirr) then chooses to increase > major minor or patch digit? Why not. But not choose automatically instead of warning or break the release. I’m use the bundle-maven-plugin

Re: Maven Release Version Policy

I'm not sure "strict semver" can be automated: functional change can't be easily detected if there is no API change semver is a great buzzword, but we should try to explain more precisely what can be automated in the plugin to try to follow the buzzword Regards, Hervé Le samedi 31 octobre 201

Re: Maven Release Version Policy

by that you mean you expect a version policy implementation that runs a bytecode check against previous version (like clirr) then chooses to increase major minor or patch digit? Regards, Hervé Le vendredi 30 octobre 2015 07:33:45 Jason van Zyl a écrit : > I would prefer to move toward standard

Re: Maven Release Version Policy

Hi, I’m with Jason to move Maven forward to use (strict) semver as default version strategy. I understand the 'cloudbee' strategy as a more exotic way. But I'm interested in more than one strategy, configurable via plugin or providing by default plugin. mit freundlichen Grüßen Uwe Barthel --

Re: Maven Release Version Policy

I don't know what "Cloudbees conventions" are, and how they are superior to everything else = what I understand from the README if we were able to better describe this policy, and compare different policies, that would give a meaning to adding more and providing them by default in the plugin to

Re: Maven Release Version Policy

Robert, Before the introduction of the plugable policy the release plugin would transform a version number like 1.8.0-1.7.1.0-alpha-1 to 1.8.0-1.7.1.0-alpha-2-SNAPSHOT whereas since sometime after m-r-p 2.2 it now does 1.8.0-1.7.1.0-alpha-1 to 1.8.0-2.7.1.0-alpha-1-SNAPSHOT which is a major pain i

Re: Maven Release Version Policy

Here are some thoughts I had on semver: http://javaadventure.blogspot.ie/2014/09/version-numbers.html In any case this code is just to provide a strategy that people can choose to turn on. I am not saying that this strategy should be the default, only that it should be one of the *defaultS* that

Re: Maven Release Version Policy

Stephen, you are saying that the implementation of the default version policy has changed? That would be a bug. CloudBees implementation looks natural,although Aether is aware of more classifiers , not just alpha and beta. Robert Verzonden vanaf Samsung Mobile. Oorspronkelijk bericht

Re: Maven Release Version Policy

I would prefer to move toward standard semver and identify where we’re not strictly adhering. Is it strict semver? > On Oct 30, 2015, at 5:16 AM, Stephen Connolly > wrote: > > Hey, so... > > Do we want to accept this implementation I knocked together: > https://github.com/CloudBees-community/

Re: Maven Release Plugin with Git broken?

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 proj

Re: Maven Release Plugin with Git broken?

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 Plu

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

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 plugi

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

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 perfor

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

Hello there, I now have a workaround. I am setting: ${maven.home} 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://illegals

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

Am Wed, 25 Mar 2015 21:01:53 +0100 schrieb Mirko Friedenhagen : > - 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

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

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 ;

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

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,

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

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:/

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

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

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

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" wrote: > Hi Mirko, > > This confirms why Karl Heinz had issues with t

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

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

Re: Maven Release Plugin and Java 8 issue

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 : Hi I apologize I'm kind of new to maven and I cant figure out

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

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

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

MG>so 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 f

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

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 wrote: > I've staged 2.5 of the maven-release component. However, the > documentation staging process is failing. > > mvn -Preporting site site:stage > > does

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

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 wrote: > Ok - so this looks to be an issue introduced in Git 1.8.5, from > https://raw.github.com/git/git/master/Documentatio

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

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 th

Re: maven-release-manager/src/main/components-fragment.xml

Hi Chris, The http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/resources/META-INF/plexus/components.xml refers to MNG-4384[1] by its role-hints. That's the only option you have to decrypt passwords with Maven 2.2.0+. This can be removed once the maven-releas

Re: maven-release-manager/src/main/components-fragment.xml

Thanks for the explanation! Ah, annotations, that also threw me. But what really threw me, was that there is already a components.xml where it should be, META-INF/plexus/components.xml ie: http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/resources/META-INF/plex

Re: maven-release-manager/src/main/components-fragment.xml

Hi Chris, Although I haven't introduced this file, I can think of the reasons of the filename and its location. The components-fragment is only a small part of the plexus configuration. It defines all release phases per goal and also configures all these phases (some of them have the same

Re: maven-release-manager/src/main/components-fragment.xml

On 9 July 2013 07:19, Olivier Lamy wrote: > see the pom: > http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/pom.xml Maybe add a comment to the file referring to the POM ? > plexus-maven-plugin merge the content > I agree that's not the usual place :-) > > 2013/7/9 Chris

Re: maven-release-manager/src/main/components-fragment.xml

:-) I totally missed that. Thanks now it makes perfect sense. I'll have a closer look tomorrow. -Chris Sent from my iPhone On 09/07/2013, at 4:19 PM, Olivier Lamy wrote: > see the pom: > http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/pom.xml > > plexus-maven-plug

Re: maven-release-manager/src/main/components-fragment.xml

see the pom: http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/pom.xml plexus-maven-plugin merge the content I agree that's not the usual place :-) 2013/7/9 Chris Graham : > Hi All. > > The full path is: > http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-

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

On Sat, Aug 4, 2012 at 9:51 AM, Chris Graham wrote: > On Fri, Aug 3, 2012 at 3:28 PM, Barrie Treloar wrote: > >> On Fri, Aug 3, 2012 at 2:49 PM, Chris Graham wrote: >> > Why make it so hard? >> > Why cann't you filter the resources and/or package them via the assembly >> plugin. >> > >> > Rememb

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

On Fri, Aug 3, 2012 at 3:28 PM, Barrie Treloar wrote: > On Fri, Aug 3, 2012 at 2:49 PM, Chris Graham 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 n

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

On Fri, Aug 3, 2012 at 2:55 PM, Hervé BOUTEMY 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

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

On Fri, Aug 3, 2012 at 2:49 PM, Chris Graham 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. The

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

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

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

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!)

Re: maven release plugin introducing scm urls into modified poms

Am 20.02.2012 06:51 schrieb "Chris Graham" : > > 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 se

Re: Maven release plugin not honoring -Darguments

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();

Re: Maven release plugin not honoring -Darguments

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 pref

Re: Maven release plugin not honoring -Darguments

Am 27.09.2011 14:48 schrieb "David Blevins" : > > 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

Re: Maven release plugin not honoring -Darguments

On Tue, Sep 27, 2011 at 1:09 PM, David Blevins 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: > >     >      org.apache.maven.plugins >      maven-release-plugin >      2.1 >       >        fa

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

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, >

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

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,

  1   2   >