Re: Plexus Archiver / Plexus Components
Excellent proposal Hervé, but how do we deal with jira-based submissions ? I am probably @author of half my committs and @committer of the rest ? Kristian 2014-09-11 8:10 GMT+02:00 Hervé BOUTEMY : > to me, it's clear we need some formal attribution to ASF from each major > contributor, since the code was committed to Codehaus, not ASF, and Codehaus > is not an antity that can transfer the result to ASF > > for the formal part, without being a lawyer, I suppose each constributor has > to confirm he is the author of the code and that he gives the code to ASF: > I'll > start a new thread on the ML, asking for every contributor to reply. > > I need your help, my frenglish comes short for the invitation, please send me > proposals in private so I can add every good idea without polluting the ML :) > > for the notion of "major" contributor, we have 13 components each with its own > contributor list: we'll see which components are fully covered, then can be > moved easily immediately, and which ones will need more legal advice > > Let's keep up the good work together: not sure we'll get 100% success, but we > can't completely fail and the situation will be improved even if not perfect. > > Regards, > > Hervé > > Le lundi 8 septembre 2014 20:38:27 Benson Margulies a écrit : >> On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY wrote: >> > here is the new version with csv files and committers deduplicate >> > http://people.apache.org/~hboutemy/codehaus/summary.html >> > >> > now we need to ask for everybody's attribution of his contributions, and >> > we'll see how much we cover from each component >> > >> > some components should be easy to cover fully, like plexus-cli >> > some will be harder... >> > >> > to start, I'm ready to give ASF all my contributions: how should I >> > proceed? >> > some formal e-mail on this ML? >> >> Yes, mail to this list contributing your contributions to that repo to >> the project. >> >> > Regards, >> > >> > Hervé >> > >> > Le dimanche 7 septembre 2014 23:22:39 Hervé BOUTEMY a écrit : >> >> improved the automatic summary >> >> http://people.apache.org/~hboutemy/codehaus/summary.html >> >> >> >> I suppose the next step will be to create a csv to be able to work on >> >> figures with a spreadsheet >> >> >> >> I have no time at the moment, will try tomorrow if nobody beats me >> >> >> >> Regards, >> >> >> >> Hervé >> >> >> >> Le dimanche 7 septembre 2014 15:01:58 Benson Margulies a écrit : >> >> > On Sun, Sep 7, 2014 at 2:24 PM, Kristian Rosenvold < >> >> > >> >> > kristian.rosenv...@gmail.com> wrote: >> >> > > But I still assume we need to get some kind of idea of how good is >> >> > > good enough. At some point there's going to be a significant >> >> > > contributor we won't be able to get hold of. We might be able to work >> >> > > around this by removing code or similar, but I don't think there is >> >> > > any point in starting a massive search for people if 100% is the only >> >> > > permitted result. >> >> > > >> >> > > Is there any way we could get some idea of what kind of requirement >> >> > > we'd be facing ? Can we acceptably simply delete contributions from >> >> > > people we can't get hold of (that may work in some cases) ? We >> >> > > usually operate on a "200 line" quota for requiring a CLA; can we >> >> > > disregard people with smaller contributions ? (And if so, would that >> >> > > be *total* 200 lines or "per submission" ...?) >> >> > >> >> > Yes, you can open a JIRA at LEGAL, and/or communicate with the board. I >> >> > recommend completing the survey first. No one there likes to answer >> >> > hypothetical questions; having an actual set of facts will grossly >> >> > improve >> >> > the conversation. >> >> > >> >> > > Kristian >> >> > > >> >> > > 2014-09-07 1:01 GMT+02:00 Jason van Zyl : >> >> > > > Cool, with your tool can you aggregate that into a single list of >> >> > > >> >> > > userIds/Names and then remove us. >> >> > > >> >> > > > I recognize most of the non-us and with that list we can contact >> >> > > > them >> >> > > >> >> > > all at once if we want. >> >> > > >> >> > > > On Sep 6, 2014, at 5:05 PM, Hervé BOUTEMY >> > >> > wrote: >> >> > > >> here are more accurate statistics: >> >> > > >> http://people.apache.org/~hboutemy/codehaus >> >> > > >> >> >> > > >> Le samedi 6 septembre 2014 09:39:20 Hervé BOUTEMY a écrit : >> >> > > >>> I satrted to write down the count of contributors done by github, >> >> > > >>> with >> >> > > >> >> > > link, >> >> > > >> >> > > >>> on >> >> > > >> >> > > https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies >> >> > > >> >> > > >>> I'm not sure figures are relevant: >> >> > > >>> - missing contributions? it seems so, I looked at plexus-velocity >> >> > > >>> and >> >> > > >> >> > > older >> >> > > >> >> > > >>> commits are not counted... >> >> > > >>> - every contribution has to be taken into account? >> >> > > >>> >> >> > > >>> we'll probably need to do more manual work: will need to dispatch >> >> >
Re: Plexus Archiver / Plexus Components
I agree that it is about projects migrating dependencies - which can take awhile, to put it mildly. However, migrating package names at the same time as migrating groupIDs can go a long way towards avoiding ClassCastExceptions. That would - in turn - imply that a new major version number is required, so ... oldGAV_oldPackageName vs. newGAV_newPackageName should not cause too much of a problem? 2014-09-11 8:29 GMT+02:00 Anders Hammar : > When/if we move these components I assume they will get a new groupId? Will > that not cause issues with duplicated plexus libraries (due to two > different sets of GA) until "everything" has moved over to the new > dependencies? > > /Anders > > On Thu, Sep 11, 2014 at 8:10 AM, Hervé BOUTEMY > wrote: > > > to me, it's clear we need some formal attribution to ASF from each major > > contributor, since the code was committed to Codehaus, not ASF, and > > Codehaus > > is not an antity that can transfer the result to ASF > > > > for the formal part, without being a lawyer, I suppose each constributor > > has > > to confirm he is the author of the code and that he gives the code to > ASF: > > I'll > > start a new thread on the ML, asking for every contributor to reply. > > > > I need your help, my frenglish comes short for the invitation, please > send > > me > > proposals in private so I can add every good idea without polluting the > ML > > :) > > > > for the notion of "major" contributor, we have 13 components each with > its > > own > > contributor list: we'll see which components are fully covered, then can > be > > moved easily immediately, and which ones will need more legal advice > > > > Let's keep up the good work together: not sure we'll get 100% success, > but > > we > > can't completely fail and the situation will be improved even if not > > perfect. > > > > Regards, > > > > Hervé > > > > Le lundi 8 septembre 2014 20:38:27 Benson Margulies a écrit : > > > On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY > > wrote: > > > > here is the new version with csv files and committers deduplicate > > > > http://people.apache.org/~hboutemy/codehaus/summary.html > > > > > > > > now we need to ask for everybody's attribution of his contributions, > > and > > > > we'll see how much we cover from each component > > > > > > > > some components should be easy to cover fully, like plexus-cli > > > > some will be harder... > > > > > > > > to start, I'm ready to give ASF all my contributions: how should I > > > > proceed? > > > > some formal e-mail on this ML? > > > > > > Yes, mail to this list contributing your contributions to that repo to > > > the project. > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > Le dimanche 7 septembre 2014 23:22:39 Hervé BOUTEMY a écrit : > > > >> improved the automatic summary > > > >> http://people.apache.org/~hboutemy/codehaus/summary.html > > > >> > > > >> I suppose the next step will be to create a csv to be able to work > on > > > >> figures with a spreadsheet > > > >> > > > >> I have no time at the moment, will try tomorrow if nobody beats me > > > >> > > > >> Regards, > > > >> > > > >> Hervé > > > >> > > > >> Le dimanche 7 septembre 2014 15:01:58 Benson Margulies a écrit : > > > >> > On Sun, Sep 7, 2014 at 2:24 PM, Kristian Rosenvold < > > > >> > > > > >> > kristian.rosenv...@gmail.com> wrote: > > > >> > > But I still assume we need to get some kind of idea of how good > is > > > >> > > good enough. At some point there's going to be a significant > > > >> > > contributor we won't be able to get hold of. We might be able to > > work > > > >> > > around this by removing code or similar, but I don't think there > > is > > > >> > > any point in starting a massive search for people if 100% is the > > only > > > >> > > permitted result. > > > >> > > > > > >> > > Is there any way we could get some idea of what kind of > > requirement > > > >> > > we'd be facing ? Can we acceptably simply delete contributions > > from > > > >> > > people we can't get hold of (that may work in some cases) ? We > > > >> > > usually operate on a "200 line" quota for requiring a CLA; can > we > > > >> > > disregard people with smaller contributions ? (And if so, would > > that > > > >> > > be *total* 200 lines or "per submission" ...?) > > > >> > > > > >> > Yes, you can open a JIRA at LEGAL, and/or communicate with the > > board. I > > > >> > recommend completing the survey first. No one there likes to > answer > > > >> > hypothetical questions; having an actual set of facts will grossly > > > >> > improve > > > >> > the conversation. > > > >> > > > > >> > > Kristian > > > >> > > > > > >> > > 2014-09-07 1:01 GMT+02:00 Jason van Zyl : > > > >> > > > Cool, with your tool can you aggregate that into a single list > > of > > > >> > > > > > >> > > userIds/Names and then remove us. > > > >> > > > > > >> > > > I recognize most of the non-us and with that list we can > contact > > > >> > > > them > > > >> > > > > > >> > > all at once if we want. > > > >> > > > > > >>
Re: Plexus Archiver / Plexus Components
When/if we move these components I assume they will get a new groupId? Will that not cause issues with duplicated plexus libraries (due to two different sets of GA) until "everything" has moved over to the new dependencies? /Anders On Thu, Sep 11, 2014 at 8:10 AM, Hervé BOUTEMY wrote: > to me, it's clear we need some formal attribution to ASF from each major > contributor, since the code was committed to Codehaus, not ASF, and > Codehaus > is not an antity that can transfer the result to ASF > > for the formal part, without being a lawyer, I suppose each constributor > has > to confirm he is the author of the code and that he gives the code to ASF: > I'll > start a new thread on the ML, asking for every contributor to reply. > > I need your help, my frenglish comes short for the invitation, please send > me > proposals in private so I can add every good idea without polluting the ML > :) > > for the notion of "major" contributor, we have 13 components each with its > own > contributor list: we'll see which components are fully covered, then can be > moved easily immediately, and which ones will need more legal advice > > Let's keep up the good work together: not sure we'll get 100% success, but > we > can't completely fail and the situation will be improved even if not > perfect. > > Regards, > > Hervé > > Le lundi 8 septembre 2014 20:38:27 Benson Margulies a écrit : > > On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY > wrote: > > > here is the new version with csv files and committers deduplicate > > > http://people.apache.org/~hboutemy/codehaus/summary.html > > > > > > now we need to ask for everybody's attribution of his contributions, > and > > > we'll see how much we cover from each component > > > > > > some components should be easy to cover fully, like plexus-cli > > > some will be harder... > > > > > > to start, I'm ready to give ASF all my contributions: how should I > > > proceed? > > > some formal e-mail on this ML? > > > > Yes, mail to this list contributing your contributions to that repo to > > the project. > > > > > Regards, > > > > > > Hervé > > > > > > Le dimanche 7 septembre 2014 23:22:39 Hervé BOUTEMY a écrit : > > >> improved the automatic summary > > >> http://people.apache.org/~hboutemy/codehaus/summary.html > > >> > > >> I suppose the next step will be to create a csv to be able to work on > > >> figures with a spreadsheet > > >> > > >> I have no time at the moment, will try tomorrow if nobody beats me > > >> > > >> Regards, > > >> > > >> Hervé > > >> > > >> Le dimanche 7 septembre 2014 15:01:58 Benson Margulies a écrit : > > >> > On Sun, Sep 7, 2014 at 2:24 PM, Kristian Rosenvold < > > >> > > > >> > kristian.rosenv...@gmail.com> wrote: > > >> > > But I still assume we need to get some kind of idea of how good is > > >> > > good enough. At some point there's going to be a significant > > >> > > contributor we won't be able to get hold of. We might be able to > work > > >> > > around this by removing code or similar, but I don't think there > is > > >> > > any point in starting a massive search for people if 100% is the > only > > >> > > permitted result. > > >> > > > > >> > > Is there any way we could get some idea of what kind of > requirement > > >> > > we'd be facing ? Can we acceptably simply delete contributions > from > > >> > > people we can't get hold of (that may work in some cases) ? We > > >> > > usually operate on a "200 line" quota for requiring a CLA; can we > > >> > > disregard people with smaller contributions ? (And if so, would > that > > >> > > be *total* 200 lines or "per submission" ...?) > > >> > > > >> > Yes, you can open a JIRA at LEGAL, and/or communicate with the > board. I > > >> > recommend completing the survey first. No one there likes to answer > > >> > hypothetical questions; having an actual set of facts will grossly > > >> > improve > > >> > the conversation. > > >> > > > >> > > Kristian > > >> > > > > >> > > 2014-09-07 1:01 GMT+02:00 Jason van Zyl : > > >> > > > Cool, with your tool can you aggregate that into a single list > of > > >> > > > > >> > > userIds/Names and then remove us. > > >> > > > > >> > > > I recognize most of the non-us and with that list we can contact > > >> > > > them > > >> > > > > >> > > all at once if we want. > > >> > > > > >> > > > On Sep 6, 2014, at 5:05 PM, Hervé BOUTEMY < > herve.bout...@free.fr> > > > > > > wrote: > > >> > > >> here are more accurate statistics: > > >> > > >> http://people.apache.org/~hboutemy/codehaus > > >> > > >> > > >> > > >> Le samedi 6 septembre 2014 09:39:20 Hervé BOUTEMY a écrit : > > >> > > >>> I satrted to write down the count of contributors done by > github, > > >> > > >>> with > > >> > > > > >> > > link, > > >> > > > > >> > > >>> on > > >> > > > > >> > > > https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies > > >> > > > > >> > > >>> I'm not sure figures are relevant: > > >> > > >>> - missing contributions? it seems so, I looked at > plexus-velocity > > >> > > >>> and
Re: Plexus Archiver / Plexus Components
to me, it's clear we need some formal attribution to ASF from each major contributor, since the code was committed to Codehaus, not ASF, and Codehaus is not an antity that can transfer the result to ASF for the formal part, without being a lawyer, I suppose each constributor has to confirm he is the author of the code and that he gives the code to ASF: I'll start a new thread on the ML, asking for every contributor to reply. I need your help, my frenglish comes short for the invitation, please send me proposals in private so I can add every good idea without polluting the ML :) for the notion of "major" contributor, we have 13 components each with its own contributor list: we'll see which components are fully covered, then can be moved easily immediately, and which ones will need more legal advice Let's keep up the good work together: not sure we'll get 100% success, but we can't completely fail and the situation will be improved even if not perfect. Regards, Hervé Le lundi 8 septembre 2014 20:38:27 Benson Margulies a écrit : > On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY wrote: > > here is the new version with csv files and committers deduplicate > > http://people.apache.org/~hboutemy/codehaus/summary.html > > > > now we need to ask for everybody's attribution of his contributions, and > > we'll see how much we cover from each component > > > > some components should be easy to cover fully, like plexus-cli > > some will be harder... > > > > to start, I'm ready to give ASF all my contributions: how should I > > proceed? > > some formal e-mail on this ML? > > Yes, mail to this list contributing your contributions to that repo to > the project. > > > Regards, > > > > Hervé > > > > Le dimanche 7 septembre 2014 23:22:39 Hervé BOUTEMY a écrit : > >> improved the automatic summary > >> http://people.apache.org/~hboutemy/codehaus/summary.html > >> > >> I suppose the next step will be to create a csv to be able to work on > >> figures with a spreadsheet > >> > >> I have no time at the moment, will try tomorrow if nobody beats me > >> > >> Regards, > >> > >> Hervé > >> > >> Le dimanche 7 septembre 2014 15:01:58 Benson Margulies a écrit : > >> > On Sun, Sep 7, 2014 at 2:24 PM, Kristian Rosenvold < > >> > > >> > kristian.rosenv...@gmail.com> wrote: > >> > > But I still assume we need to get some kind of idea of how good is > >> > > good enough. At some point there's going to be a significant > >> > > contributor we won't be able to get hold of. We might be able to work > >> > > around this by removing code or similar, but I don't think there is > >> > > any point in starting a massive search for people if 100% is the only > >> > > permitted result. > >> > > > >> > > Is there any way we could get some idea of what kind of requirement > >> > > we'd be facing ? Can we acceptably simply delete contributions from > >> > > people we can't get hold of (that may work in some cases) ? We > >> > > usually operate on a "200 line" quota for requiring a CLA; can we > >> > > disregard people with smaller contributions ? (And if so, would that > >> > > be *total* 200 lines or "per submission" ...?) > >> > > >> > Yes, you can open a JIRA at LEGAL, and/or communicate with the board. I > >> > recommend completing the survey first. No one there likes to answer > >> > hypothetical questions; having an actual set of facts will grossly > >> > improve > >> > the conversation. > >> > > >> > > Kristian > >> > > > >> > > 2014-09-07 1:01 GMT+02:00 Jason van Zyl : > >> > > > Cool, with your tool can you aggregate that into a single list of > >> > > > >> > > userIds/Names and then remove us. > >> > > > >> > > > I recognize most of the non-us and with that list we can contact > >> > > > them > >> > > > >> > > all at once if we want. > >> > > > >> > > > On Sep 6, 2014, at 5:05 PM, Hervé BOUTEMY > > > > wrote: > >> > > >> here are more accurate statistics: > >> > > >> http://people.apache.org/~hboutemy/codehaus > >> > > >> > >> > > >> Le samedi 6 septembre 2014 09:39:20 Hervé BOUTEMY a écrit : > >> > > >>> I satrted to write down the count of contributors done by github, > >> > > >>> with > >> > > > >> > > link, > >> > > > >> > > >>> on > >> > > > >> > > https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies > >> > > > >> > > >>> I'm not sure figures are relevant: > >> > > >>> - missing contributions? it seems so, I looked at plexus-velocity > >> > > >>> and > >> > > > >> > > older > >> > > > >> > > >>> commits are not counted... > >> > > >>> - every contribution has to be taken into account? > >> > > >>> > >> > > >>> we'll probably need to do more manual work: will need to dispatch > >> > > > >> > > components > >> > > > >> > > >>> to avoid one to do the work for everything > >> > > >>> > >> > > >>> then we'll need to figure out the process details: I read > >> > > >>> http://incubator.apache.org/ip-clearance/index.html, I suppose > >> > > >>> I'll > >> > > > >> > > have as > >> >
[VOTE] Release Apache Shared Component Maven Dependency Analyzer version 1.5
Hi, We solved 4 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=19151 http://jira.codehaus.org/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20and%20component%20%3D%20maven-dependency-analyzer%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1055 http://repository.apache.org/content/repositories/maven-1055/org/apache/maven/shared/maven-dependency-analyzer/1.5/maven-dependency-analyzer-1.5-source-release.zip Source release checksum(s): maven-dependency-analyzer-1.5-source-release.zip sha1: 609404dd2cb2315c896c2867f22be2ff06c8e59d Staging site: http://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 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: [VOTE] Release Apache Maven RAR Plugin version 2.4
+1 On 9 September 2014 05:47, Karl Heinz Marbaise wrote: > Hi, > > We solved 5 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11143&version=18707 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/issues/?jql=project%20%3D%20MRAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1053 > > http://repository.apache.org/content/repositories/maven-1053/org/apache/maven/plugins/maven-rar-plugin/2.4/maven-rar-plugin-2.4-source-release.zip > > Source release checksum(s): > maven-rar-plugin-source-release.zip sha1: > e38b3f99f203d690b5de863710ba978d1c145566 > > Staging site: > http://maven.apache.org/plugins-archives/maven-rar-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl-Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy 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
[VOTE] Apache Wagon 2.7
Hi, I'd like to release Apache Wagon 2.7 We fixed 4 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=20560&styleName=Text&projectId=10335&Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-1054/ Staging site: http://maven.apache.org/wagon-archives/wagon-LATEST/ Vote open for 72H [+1] [0] [-1] Cheers -- Olivier Lamy 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: [VOTE] Release Apache Maven RAR Plugin version 2.4
+1 Regards, Hervé Le lundi 8 septembre 2014 21:47:06 Karl Heinz Marbaise a écrit : > Hi, > > We solved 5 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11143&version=187 > 07 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/issues/?jql=project%20%3D%20MRAR%20AND%20status%20% > 3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1053 > > http://repository.apache.org/content/repositories/maven-1053/org/apache/mave > n/plugins/maven-rar-plugin/2.4/maven-rar-plugin-2.4-source-release.zip > > Source release checksum(s): > maven-rar-plugin-source-release.zip sha1: > e38b3f99f203d690b5de863710ba978d1c145566 > > Staging site: > http://maven.apache.org/plugins-archives/maven-rar-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > 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: https://github.com/apache/maven-scm/pull/17
Sorry, I thought that the plugins, the scm ones in this case, had moved to git? Still in SVN? If so, then no issues. -Chris On Thu, Sep 11, 2014 at 11:43 AM, Benson Margulies wrote: > For plugins, you need mostly to make an account on Codehaus JIRA, then you > svn checkout as per the information in the plugin's page, and then you can > attach a patch to a JIRA. > > > > On Wed, Sep 10, 2014 at 9:37 PM, Chris Graham > wrote: > > > Whilst not strictly related to this thread... > > > > Is there a document that tells us what we need to do to contribute? > > How/what repos we need to clone/setup, how to generate a patch/pull > request > > etc? > > > > Thanks, > > > > -Chris > > > > On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies > > > wrote: > > > > > Of course; I'm just trying to help you get off the ground; is there > > > something else you'd like me to do? > > > > > > On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte > > > wrote: > > > > > > > I don't want to depend on external systems. > > > > you could add me (rfscholte) but that'll only be for reproducing the > > > issue. > > > > and then I need isolate the problem and translate it to a unittest. > > > > > > > > > > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies < > > > > bimargul...@gmail.com>: > > > > > > > > > > > > Well, you'll need to push a clone where you can write, or tell me > your > > > >> github ID so I can add you as a collaborator. > > > >> > > > >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte < > rfscho...@apache.org > > > > > > >> wrote: > > > >> > > > >> The first step already fails on my machine. > > > >>> > > > >>> mvn release:prepare release:perform -B -DpushChanges=false > > > >>> > > > >>> I'm a bit surprised, because I see: > > > >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com: > > bimargulies/ > > > >>> pom-file-name-tc.git > > > >>> refs/heads/master:refs/heads/master" > > > >>> > > > >>> Actual failure: > > > >>> [ERROR] Failed to execute goal org.apache.maven.plugins: > > > >>> maven-release-plugin:2.5:prepare (default-cli) on project > > > >>> pom-file-name-tc: Unable to commit files > > > >>> [ERROR] Provider message: > > > >>> [ERROR] The git-push command failed. > > > >>> [ERROR] Command output: > > > >>> [ERROR] Warning: Permanently added the RSA host key for IP address > > > >>> '192.30.252.131' to the list of known hosts. > > > >>> [ERROR] Permission denied (publickey). > > > >>> [ERROR] fatal: Could not read from remote repository. > > > >>> [ERROR] > > > >>> [ERROR] Please make sure you have the correct access rights > > > >>> [ERROR] and the repository exists. > > > >>> > > > >>> As said: I want to create a *unittest* > > > >>> If I'm correct, the status-call has the wrong arguments. So what > > should > > > >>> it > > > >>> look like? What's the result of this (so I can mock the consumer) > and > > > >>> what > > > >>> should the next call be? > > > >>> > > > >>> Robert > > > >>> > > > >>> Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies < > > > >>> bimargul...@gmail.com>: > > > >>> > > > >>> > > > >>> Step 1: in the top level dir of the example, run mvn --batch-mode > > > >>> > > > release:prepare release:perform. All will be well. A repo will > > > populate > > > in > > > /tmp. > > > > > > Step 2: modify pom in 'second' directory to use the just-release > > > parent > > > pom, commit, push. > > > > > > Step 3: mvn release:prepare in second directory. > > > > > > No errors, but the pom.xml will be sitting there modified, and > there > > > will > > > be a tag pointing to the wrong place. > > > > > > > > > > > > On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte < > > rfscho...@apache.org > > > > > > > wrote: > > > > > > that's just the beginning... > > > > > > > so: how did you execute it? what did you get? what would you > > expect? > > > > > > > > Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < > > > > bimargul...@gmail.com>: > > > > > > > > > > > > Aha, I have one for you. https://github.com/ > > > > bimargulies/pom-file-name-tc. > > > > > > > > I > > > >> attached it to a dup JIRA which I closed, or you can take it as > > you > > > >> see > > > >> it. > > > >> You may in general find MRELEASE-887 helpful in this respect. > > > >> > > > >> On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte < > > > rfscho...@apache.org > > > >> > > > > >> wrote: > > > >> > > > >> Hi, > > > >> > > > >> > > > >>> IIRC I didn't have enough info to make a unittest, i.e. > reproduce > > > >>> what > > > >>> they get right now and what they would expect to be able to fix > > it. > > > >>> That would take me too much time to find out, so I left this > one > > > open > > > >>> for > > > >>> now. > > > >>> > > > >>> thanks, > > > >>> Robert > > > >>> > >
Re: https://github.com/apache/maven-scm/pull/17
For plugins, you need mostly to make an account on Codehaus JIRA, then you svn checkout as per the information in the plugin's page, and then you can attach a patch to a JIRA. On Wed, Sep 10, 2014 at 9:37 PM, Chris Graham wrote: > Whilst not strictly related to this thread... > > Is there a document that tells us what we need to do to contribute? > How/what repos we need to clone/setup, how to generate a patch/pull request > etc? > > Thanks, > > -Chris > > On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies > wrote: > > > Of course; I'm just trying to help you get off the ground; is there > > something else you'd like me to do? > > > > On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte > > wrote: > > > > > I don't want to depend on external systems. > > > you could add me (rfscholte) but that'll only be for reproducing the > > issue. > > > and then I need isolate the problem and translate it to a unittest. > > > > > > > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies < > > > bimargul...@gmail.com>: > > > > > > > > > Well, you'll need to push a clone where you can write, or tell me your > > >> github ID so I can add you as a collaborator. > > >> > > >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte > > > >> wrote: > > >> > > >> The first step already fails on my machine. > > >>> > > >>> mvn release:prepare release:perform -B -DpushChanges=false > > >>> > > >>> I'm a bit surprised, because I see: > > >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com: > bimargulies/ > > >>> pom-file-name-tc.git > > >>> refs/heads/master:refs/heads/master" > > >>> > > >>> Actual failure: > > >>> [ERROR] Failed to execute goal org.apache.maven.plugins: > > >>> maven-release-plugin:2.5:prepare (default-cli) on project > > >>> pom-file-name-tc: Unable to commit files > > >>> [ERROR] Provider message: > > >>> [ERROR] The git-push command failed. > > >>> [ERROR] Command output: > > >>> [ERROR] Warning: Permanently added the RSA host key for IP address > > >>> '192.30.252.131' to the list of known hosts. > > >>> [ERROR] Permission denied (publickey). > > >>> [ERROR] fatal: Could not read from remote repository. > > >>> [ERROR] > > >>> [ERROR] Please make sure you have the correct access rights > > >>> [ERROR] and the repository exists. > > >>> > > >>> As said: I want to create a *unittest* > > >>> If I'm correct, the status-call has the wrong arguments. So what > should > > >>> it > > >>> look like? What's the result of this (so I can mock the consumer) and > > >>> what > > >>> should the next call be? > > >>> > > >>> Robert > > >>> > > >>> Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies < > > >>> bimargul...@gmail.com>: > > >>> > > >>> > > >>> Step 1: in the top level dir of the example, run mvn --batch-mode > > >>> > > release:prepare release:perform. All will be well. A repo will > > populate > > in > > /tmp. > > > > Step 2: modify pom in 'second' directory to use the just-release > > parent > > pom, commit, push. > > > > Step 3: mvn release:prepare in second directory. > > > > No errors, but the pom.xml will be sitting there modified, and there > > will > > be a tag pointing to the wrong place. > > > > > > > > On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte < > rfscho...@apache.org > > > > > wrote: > > > > that's just the beginning... > > > > > so: how did you execute it? what did you get? what would you > expect? > > > > > > Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < > > > bimargul...@gmail.com>: > > > > > > > > > Aha, I have one for you. https://github.com/ > > > bimargulies/pom-file-name-tc. > > > > > > I > > >> attached it to a dup JIRA which I closed, or you can take it as > you > > >> see > > >> it. > > >> You may in general find MRELEASE-887 helpful in this respect. > > >> > > >> On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte < > > rfscho...@apache.org > > >> > > > >> wrote: > > >> > > >> Hi, > > >> > > >> > > >>> IIRC I didn't have enough info to make a unittest, i.e. reproduce > > >>> what > > >>> they get right now and what they would expect to be able to fix > it. > > >>> That would take me too much time to find out, so I left this one > > open > > >>> for > > >>> now. > > >>> > > >>> thanks, > > >>> Robert > > >>> > > >>> Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < > > >>> bimargul...@gmail.com>: > > >>> > > >>> > > >>> Yes, the remarks which dribbled off pointed to adapting the fix > > back > > >>> into > > >>> > > >>> the m-r-p. > > >>> > > > > > > On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise < > > khmarba...@gmx.de > > > > > wrote: > > > > Hi Benson, > > > > > > >>
Re: https://github.com/apache/maven-scm/pull/17
Whilst not strictly related to this thread... Is there a document that tells us what we need to do to contribute? How/what repos we need to clone/setup, how to generate a patch/pull request etc? Thanks, -Chris On Thu, Sep 11, 2014 at 7:04 AM, Benson Margulies wrote: > Of course; I'm just trying to help you get off the ground; is there > something else you'd like me to do? > > On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte > wrote: > > > I don't want to depend on external systems. > > you could add me (rfscholte) but that'll only be for reproducing the > issue. > > and then I need isolate the problem and translate it to a unittest. > > > > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies < > > bimargul...@gmail.com>: > > > > > > Well, you'll need to push a clone where you can write, or tell me your > >> github ID so I can add you as a collaborator. > >> > >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte > >> wrote: > >> > >> The first step already fails on my machine. > >>> > >>> mvn release:prepare release:perform -B -DpushChanges=false > >>> > >>> I'm a bit surprised, because I see: > >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com:bimargulies/ > >>> pom-file-name-tc.git > >>> refs/heads/master:refs/heads/master" > >>> > >>> Actual failure: > >>> [ERROR] Failed to execute goal org.apache.maven.plugins: > >>> maven-release-plugin:2.5:prepare (default-cli) on project > >>> pom-file-name-tc: Unable to commit files > >>> [ERROR] Provider message: > >>> [ERROR] The git-push command failed. > >>> [ERROR] Command output: > >>> [ERROR] Warning: Permanently added the RSA host key for IP address > >>> '192.30.252.131' to the list of known hosts. > >>> [ERROR] Permission denied (publickey). > >>> [ERROR] fatal: Could not read from remote repository. > >>> [ERROR] > >>> [ERROR] Please make sure you have the correct access rights > >>> [ERROR] and the repository exists. > >>> > >>> As said: I want to create a *unittest* > >>> If I'm correct, the status-call has the wrong arguments. So what should > >>> it > >>> look like? What's the result of this (so I can mock the consumer) and > >>> what > >>> should the next call be? > >>> > >>> Robert > >>> > >>> Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies < > >>> bimargul...@gmail.com>: > >>> > >>> > >>> Step 1: in the top level dir of the example, run mvn --batch-mode > >>> > release:prepare release:perform. All will be well. A repo will > populate > in > /tmp. > > Step 2: modify pom in 'second' directory to use the just-release > parent > pom, commit, push. > > Step 3: mvn release:prepare in second directory. > > No errors, but the pom.xml will be sitting there modified, and there > will > be a tag pointing to the wrong place. > > > > On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte > > wrote: > > that's just the beginning... > > > so: how did you execute it? what did you get? what would you expect? > > > > Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < > > bimargul...@gmail.com>: > > > > > > Aha, I have one for you. https://github.com/ > > bimargulies/pom-file-name-tc. > > > > I > >> attached it to a dup JIRA which I closed, or you can take it as you > >> see > >> it. > >> You may in general find MRELEASE-887 helpful in this respect. > >> > >> On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte < > rfscho...@apache.org > >> > > >> wrote: > >> > >> Hi, > >> > >> > >>> IIRC I didn't have enough info to make a unittest, i.e. reproduce > >>> what > >>> they get right now and what they would expect to be able to fix it. > >>> That would take me too much time to find out, so I left this one > open > >>> for > >>> now. > >>> > >>> thanks, > >>> Robert > >>> > >>> Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < > >>> bimargul...@gmail.com>: > >>> > >>> > >>> Yes, the remarks which dribbled off pointed to adapting the fix > back > >>> into > >>> > >>> the m-r-p. > >>> > > > On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise < > khmarba...@gmx.de > > > wrote: > > Hi Benson, > > > > Is anyone working on a fix to MRELEASE-875? > > > > > > > > Based on JIRA it is assigned to Dominik Bartholdi which > requested > > > >> > >> reviews > >> > > from others on Github... > > > > BTW: Not working on that... > > > > Kind regards > > Karl-Heinz Marbaise > > > > > > > > > > > > > > > > - > > To unsu
Re: [jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
Ideally yes, it would be wonderful to be able to create a WI as a part if the
release.
The problem Jazz/RTC at least is that there is no command line tool to
manipulate WI's. There is a feature request to do so, but it has not been
started.
That issue aside, there is also the case where the WI needs to be created
beforehand. This is also the easiest case to solve.
I'm still very interested to hear from those who have worked with similar
systems to see how they do/want to do it.
-Chris
Sent from my iPhone
On 11/09/2014, at 2:05 AM, David Jencks wrote:
> Sorry for the reply on list, my codehaus jira credentials seem to have gotten
> messed up….
>
> I would expect the best normal workflow would be to have the release plugin
> create the work item, then attach the change sets to it. I have some
> evidence that it is possible for external programs to do stuff like this, but
> I have no idea how.
>
> david jencks
>
> On Sep 10, 2014, at 8:51 AM, "AShit Shah (JIRA)" wrote:
>
>>
>> [
>> https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352607#comment-352607
>> ]
>>
>> AShit Shah commented on SCM-775:
>>
>>
>> Both options are fine.
>>
>> I think ANT have it via build.xml. I personally would prefer to have it via
>> a -D option at command line and not hard-coded in pom.xml.
>>
>> I was thinking of creating one release build WI for every agile sprint. Not
>> sue if this is right approach though.
>>
>>> Request for new optional parameter RTC (workItem) with release:prepare to
>>> associate workitem with changesets got created during build process
>>> -
>>>
>>> Key: SCM-775
>>> URL: https://jira.codehaus.org/browse/SCM-775
>>> Project: Maven SCM
>>>Issue Type: Improvement
>>>Components: maven-scm-provider-jazz
>>> Affects Versions: 1.9.1
>>> Reporter: AShit Shah
>>>
>>> Maven {{release:prepare}} command is failing with below error while
>>> delivering updated pom.xml to the stream due to Preconditions configured in
>>> RTC to have comments and associated work item with every delivery.
>>> [ERROR] Name: Deliver
>>> [ERROR] Participant Reports:
>>> [ERROR] Name: Require Work items and Comments
>>> [ERROR] A work item must be associated with the change set.`
>>> [ERROR] At least one of the associated work items must specify that the
>>> work is planned for the current iteration.
>>> [ERROR] At least one of the associated work items must be assigned to you.
>>> [ERROR] Problem running 'deliver':
>>> [ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
>>> be associated with the change set.
>>> [ERROR] -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>>> goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare
>>> (default-cli) on project junit-ext: Unable to commit files
>>> Provider message:
>>> Error code for Jazz SCM deliver command - 17
>>> I can not find any optional parameters on
>>> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
>>> for release:prepare command which I can use and pass the RTC workitem
>>> number on command line.
>>> Suggestion:
>>> It will be great if you can provide optional parameters like "workItem"
>>> which I can use and pass RTC workitem number with release:prepare at
>>> command line.
>>> Example: mvn -PmyProfile release:prepare -DworkItem=123456
>>> So build process should associate change sets created by release:prepare
>>> with work item 123456 and deliver change sets to the stream.
>>> As of now I have to use "-DpushChanges=false" parameter to block delivery
>>> process and I have to manually find the change sets, associate them with
>>> work item and deliver them before I run release:perform.
>>> Thanks.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.1.6#6162)
>
>
> -
> 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 Jar Signer Timestamp authority option
For accomplishing this task, your configuration can be like this
org.apache.maven.plugins
maven-jarsigner-plugin
1.2
sign webcontent jars
prepare-package
sign
${project.build.directory}/projectname-webcontent/applets
*.jar
Keystore
alias
pass
-tsa
http://tsa.tecxoft.com/test
--
View this message in context:
http://maven.40175.n5.nabble.com/Maven-Jar-Signer-Timestamp-authority-option-tp4396564p5804467.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: https://github.com/apache/maven-scm/pull/17
Of course; I'm just trying to help you get off the ground; is there something else you'd like me to do? On Wed, Sep 10, 2014 at 4:58 PM, Robert Scholte wrote: > I don't want to depend on external systems. > you could add me (rfscholte) but that'll only be for reproducing the issue. > and then I need isolate the problem and translate it to a unittest. > > > Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > > Well, you'll need to push a clone where you can write, or tell me your >> github ID so I can add you as a collaborator. >> >> On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte >> wrote: >> >> The first step already fails on my machine. >>> >>> mvn release:prepare release:perform -B -DpushChanges=false >>> >>> I'm a bit surprised, because I see: >>> [INFO] Executing: cmd.exe /X /C "git push g...@github.com:bimargulies/ >>> pom-file-name-tc.git >>> refs/heads/master:refs/heads/master" >>> >>> Actual failure: >>> [ERROR] Failed to execute goal org.apache.maven.plugins: >>> maven-release-plugin:2.5:prepare (default-cli) on project >>> pom-file-name-tc: Unable to commit files >>> [ERROR] Provider message: >>> [ERROR] The git-push command failed. >>> [ERROR] Command output: >>> [ERROR] Warning: Permanently added the RSA host key for IP address >>> '192.30.252.131' to the list of known hosts. >>> [ERROR] Permission denied (publickey). >>> [ERROR] fatal: Could not read from remote repository. >>> [ERROR] >>> [ERROR] Please make sure you have the correct access rights >>> [ERROR] and the repository exists. >>> >>> As said: I want to create a *unittest* >>> If I'm correct, the status-call has the wrong arguments. So what should >>> it >>> look like? What's the result of this (so I can mock the consumer) and >>> what >>> should the next call be? >>> >>> Robert >>> >>> Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies < >>> bimargul...@gmail.com>: >>> >>> >>> Step 1: in the top level dir of the example, run mvn --batch-mode >>> release:prepare release:perform. All will be well. A repo will populate in /tmp. Step 2: modify pom in 'second' directory to use the just-release parent pom, commit, push. Step 3: mvn release:prepare in second directory. No errors, but the pom.xml will be sitting there modified, and there will be a tag pointing to the wrong place. On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte wrote: that's just the beginning... > so: how did you execute it? what did you get? what would you expect? > > Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > > Aha, I have one for you. https://github.com/ > bimargulies/pom-file-name-tc. > > I >> attached it to a dup JIRA which I closed, or you can take it as you >> see >> it. >> You may in general find MRELEASE-887 helpful in this respect. >> >> On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte > > >> wrote: >> >> Hi, >> >> >>> IIRC I didn't have enough info to make a unittest, i.e. reproduce >>> what >>> they get right now and what they would expect to be able to fix it. >>> That would take me too much time to find out, so I left this one open >>> for >>> now. >>> >>> thanks, >>> Robert >>> >>> Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < >>> bimargul...@gmail.com>: >>> >>> >>> Yes, the remarks which dribbled off pointed to adapting the fix back >>> into >>> >>> the m-r-p. >>> On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise < khmarba...@gmx.de > wrote: Hi Benson, > Is anyone working on a fix to MRELEASE-875? > > > > Based on JIRA it is assigned to Dominik Bartholdi which requested > >> >> reviews >> > from others on Github... > > BTW: Not working on that... > > 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 >>> >>> >>> >>> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache
Re: https://github.com/apache/maven-scm/pull/17
I don't want to depend on external systems. you could add me (rfscholte) but that'll only be for reproducing the issue. and then I need isolate the problem and translate it to a unittest. Op Wed, 10 Sep 2014 22:53:38 +0200 schreef Benson Margulies : Well, you'll need to push a clone where you can write, or tell me your github ID so I can add you as a collaborator. On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte wrote: The first step already fails on my machine. mvn release:prepare release:perform -B -DpushChanges=false I'm a bit surprised, because I see: [INFO] Executing: cmd.exe /X /C "git push g...@github.com:bimargulies/pom-file-name-tc.git refs/heads/master:refs/heads/master" Actual failure: [ERROR] Failed to execute goal org.apache.maven.plugins: maven-release-plugin:2.5:prepare (default-cli) on project pom-file-name-tc: Unable to commit files [ERROR] Provider message: [ERROR] The git-push command failed. [ERROR] Command output: [ERROR] Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts. [ERROR] Permission denied (publickey). [ERROR] fatal: Could not read from remote repository. [ERROR] [ERROR] Please make sure you have the correct access rights [ERROR] and the repository exists. As said: I want to create a *unittest* If I'm correct, the status-call has the wrong arguments. So what should it look like? What's the result of this (so I can mock the consumer) and what should the next call be? Robert Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies < bimargul...@gmail.com>: Step 1: in the top level dir of the example, run mvn --batch-mode release:prepare release:perform. All will be well. A repo will populate in /tmp. Step 2: modify pom in 'second' directory to use the just-release parent pom, commit, push. Step 3: mvn release:prepare in second directory. No errors, but the pom.xml will be sitting there modified, and there will be a tag pointing to the wrong place. On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte wrote: that's just the beginning... so: how did you execute it? what did you get? what would you expect? Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < bimargul...@gmail.com>: Aha, I have one for you. https://github.com/ bimargulies/pom-file-name-tc. I attached it to a dup JIRA which I closed, or you can take it as you see it. You may in general find MRELEASE-887 helpful in this respect. On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte wrote: Hi, IIRC I didn't have enough info to make a unittest, i.e. reproduce what they get right now and what they would expect to be able to fix it. That would take me too much time to find out, so I left this one open for now. thanks, Robert Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < bimargul...@gmail.com>: Yes, the remarks which dribbled off pointed to adapting the fix back into the m-r-p. On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise < khmarba...@gmx.de > wrote: Hi Benson, > Is anyone working on a fix to MRELEASE-875? Based on JIRA it is assigned to Dominik Bartholdi which requested reviews from others on Github... BTW: Not working on that... 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 - 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: https://github.com/apache/maven-scm/pull/17
Well, you'll need to push a clone where you can write, or tell me your github ID so I can add you as a collaborator. On Wed, Sep 10, 2014 at 4:45 PM, Robert Scholte wrote: > The first step already fails on my machine. > > mvn release:prepare release:perform -B -DpushChanges=false > > I'm a bit surprised, because I see: > [INFO] Executing: cmd.exe /X /C "git push > g...@github.com:bimargulies/pom-file-name-tc.git > refs/heads/master:refs/heads/master" > > Actual failure: > [ERROR] Failed to execute goal org.apache.maven.plugins: > maven-release-plugin:2.5:prepare (default-cli) on project > pom-file-name-tc: Unable to commit files > [ERROR] Provider message: > [ERROR] The git-push command failed. > [ERROR] Command output: > [ERROR] Warning: Permanently added the RSA host key for IP address > '192.30.252.131' to the list of known hosts. > [ERROR] Permission denied (publickey). > [ERROR] fatal: Could not read from remote repository. > [ERROR] > [ERROR] Please make sure you have the correct access rights > [ERROR] and the repository exists. > > As said: I want to create a *unittest* > If I'm correct, the status-call has the wrong arguments. So what should it > look like? What's the result of this (so I can mock the consumer) and what > should the next call be? > > Robert > > Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > > Step 1: in the top level dir of the example, run mvn --batch-mode >> release:prepare release:perform. All will be well. A repo will populate in >> /tmp. >> >> Step 2: modify pom in 'second' directory to use the just-release parent >> pom, commit, push. >> >> Step 3: mvn release:prepare in second directory. >> >> No errors, but the pom.xml will be sitting there modified, and there will >> be a tag pointing to the wrong place. >> >> >> >> On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte >> wrote: >> >> that's just the beginning... >>> so: how did you execute it? what did you get? what would you expect? >>> >>> Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < >>> bimargul...@gmail.com>: >>> >>> >>> Aha, I have one for you. https://github.com/ >>> bimargulies/pom-file-name-tc. >>> I attached it to a dup JIRA which I closed, or you can take it as you see it. You may in general find MRELEASE-887 helpful in this respect. On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte wrote: Hi, > > IIRC I didn't have enough info to make a unittest, i.e. reproduce what > they get right now and what they would expect to be able to fix it. > That would take me too much time to find out, so I left this one open > for > now. > > thanks, > Robert > > Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > > Yes, the remarks which dribbled off pointed to adapting the fix back > into > > the m-r-p. >> >> >> On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise < >> khmarba...@gmx.de >> > >> wrote: >> >> Hi Benson, >> >> >>> > Is anyone working on a fix to MRELEASE-875? >>> >>> >>> >>> Based on JIRA it is assigned to Dominik Bartholdi which requested reviews >>> from others on Github... >>> >>> BTW: Not working on that... >>> >>> 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 > > > - >>> 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: https://github.com/apache/maven-scm/pull/17
The first step already fails on my machine. mvn release:prepare release:perform -B -DpushChanges=false I'm a bit surprised, because I see: [INFO] Executing: cmd.exe /X /C "git push g...@github.com:bimargulies/pom-file-name-tc.git refs/heads/master:refs/heads/master" Actual failure: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli) on project pom-file-name-tc: Unable to commit files [ERROR] Provider message: [ERROR] The git-push command failed. [ERROR] Command output: [ERROR] Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts. [ERROR] Permission denied (publickey). [ERROR] fatal: Could not read from remote repository. [ERROR] [ERROR] Please make sure you have the correct access rights [ERROR] and the repository exists. As said: I want to create a *unittest* If I'm correct, the status-call has the wrong arguments. So what should it look like? What's the result of this (so I can mock the consumer) and what should the next call be? Robert Op Wed, 10 Sep 2014 21:17:10 +0200 schreef Benson Margulies : Step 1: in the top level dir of the example, run mvn --batch-mode release:prepare release:perform. All will be well. A repo will populate in /tmp. Step 2: modify pom in 'second' directory to use the just-release parent pom, commit, push. Step 3: mvn release:prepare in second directory. No errors, but the pom.xml will be sitting there modified, and there will be a tag pointing to the wrong place. On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte wrote: that's just the beginning... so: how did you execute it? what did you get? what would you expect? Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < bimargul...@gmail.com>: Aha, I have one for you. https://github.com/bimargulies/pom-file-name-tc. I attached it to a dup JIRA which I closed, or you can take it as you see it. You may in general find MRELEASE-887 helpful in this respect. On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte wrote: Hi, IIRC I didn't have enough info to make a unittest, i.e. reproduce what they get right now and what they would expect to be able to fix it. That would take me too much time to find out, so I left this one open for now. thanks, Robert Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < bimargul...@gmail.com>: Yes, the remarks which dribbled off pointed to adapting the fix back into the m-r-p. On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise > wrote: Hi Benson, > Is anyone working on a fix to MRELEASE-875? Based on JIRA it is assigned to Dominik Bartholdi which requested reviews from others on Github... BTW: Not working on that... 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 - 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: SCM Providers
Hi Chris, I had to dive deep in my mail archive, but it seems that the day after my attempt a colleague managed to release with my initial setup. So it probably had to do with my rights, configuration or whatever. I'll ask the status of that project and if the still can release successfully. It would be nice if we could collect a couple of usecases with workitems and with different scm's if possible and come with a good strategy to solve this. thanks, Robert Op Wed, 10 Sep 2014 07:39:10 +0200 schreef Chris Graham : Hi Robert! From a thread a long time ago! This issue has popped up again. https://jira.codehaus.org/browse/SCM-775 Did you/How did you ever end up solving the issue for TFS? You're right, a general solution would be preferable. I think the workflow around the (re)use of a Work Item would be determined by the client, and I'd rather not force their hand on that one. -Chris On Thu, Jul 25, 2013 at 4:27 AM, Robert Scholte wrote: Hi, Recently I had a look at Microsoft Team Foundation Server and faced the same kind of issue. I'm not sure if you could/should reuse a WorkItem. For the maven-release-plugin this could very well be acceptable, but for commits in general? I don't think so. If it is static, then you can make it part of the SCM-URL If it is a system-wide setting, then create a specific scm-settings.xml. This latter is not very well documented, or it is hard to find. In the past I've written a setup-maven-plugin[1], with which you could create such files and which has a link to the original documentation. If the workitem is variable, then the -D option is probably the best. Would be nice if we could think of a general solution. Robert [1] http://mojo.codehaus.org/setup/setup-maven-plugin/plugin-info.html Op Wed, 24 Jul 2013 01:35:43 +0200 schreef Chris Graham < chrisgw...@gmail.com>: Hey All. In the RTC/Jazz forum, a request came up for the ability to associate a Work Item with the commits that the SCM plugin does. On the Jazz side, I think that I've worked things out. However, I am unsure as to how to best do this on the maven and scm provider side. The generic question boils down to: How can we supply a scm specific parameter to a specific scm provider? One that is not applicable to all providers. I really do not want to add a -D option. :-) Thoughts/comments/suggestions? -Chris - 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: https://github.com/apache/maven-scm/pull/17
Step 1: in the top level dir of the example, run mvn --batch-mode release:prepare release:perform. All will be well. A repo will populate in /tmp. Step 2: modify pom in 'second' directory to use the just-release parent pom, commit, push. Step 3: mvn release:prepare in second directory. No errors, but the pom.xml will be sitting there modified, and there will be a tag pointing to the wrong place. On Wed, Sep 10, 2014 at 3:10 PM, Robert Scholte wrote: > that's just the beginning... > so: how did you execute it? what did you get? what would you expect? > > Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > > Aha, I have one for you. https://github.com/bimargulies/pom-file-name-tc. >> I >> attached it to a dup JIRA which I closed, or you can take it as you see >> it. >> You may in general find MRELEASE-887 helpful in this respect. >> >> On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte >> wrote: >> >> Hi, >>> >>> IIRC I didn't have enough info to make a unittest, i.e. reproduce what >>> they get right now and what they would expect to be able to fix it. >>> That would take me too much time to find out, so I left this one open for >>> now. >>> >>> thanks, >>> Robert >>> >>> Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < >>> bimargul...@gmail.com>: >>> >>> >>> Yes, the remarks which dribbled off pointed to adapting the fix back >>> into >>> the m-r-p. On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise >>> > wrote: Hi Benson, > > > Is anyone working on a fix to MRELEASE-875? > > > >> Based on JIRA it is assigned to Dominik Bartholdi which requested >> > reviews > from others on Github... > > BTW: Not working on that... > > 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 >>> >>> > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Keeping Plexus component states persisted accross plugin executions
I am going back and forth on this topic and its reference, and still not
able to get my singleton belonging to a jar to be shared across plugins.
Dirk how are you doing at your side?
Thanks
-Dan
On Fri, Aug 1, 2014 at 9:21 AM, Dan Tran wrote:
> So far it looks to me it is as simple as setting
> true to my project's build-->plugins-->plugin ( in
> this case maven-scm-plugin ). It not working. Perhaps I need to do some
> MANIFEST setup at my component?
>
> -D
>
> here the Herve' s response at mojo-dev
>
> you use either build/extensions/extension[1] or plugin/extensions[2]
>
> build/extensions is used in multiple mojo projects (just grep to find
> them) to
> add an extension to site plugin (which IMHO should not be done with such
> extension but just as m-site-p dependency)
>
> I couldn't find any exemple of plugin/extension, and the doc isn't clear.
> But since there is a Maven Core IT [3] for MNG-4381 [4] that explains
> exactly
> what you are trying to do ("Test that extension plugins can contribute non-
> core components that can be accessed by other plugins in the same project
> and
> in projects with the same extension"), this should contain a working
> example
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/ref/3.2.2/maven-model/maven.html#class_build
>
> [2] http://maven.apache.org/ref/3.2.2/maven-model/maven.html#class_plugin
>
> [3] http://jira.codehaus.org/browse/MNG-4381
>
> [4]
> http://maven.apache.org/core-its/core-it-suite/xref-test/org/apache/maven/it/MavenITmng4381ExtensionSingletonComponentTest.html
>
> Le vendredi 1 août 2014 01:55:59 vous avez écrit :
>
>
> On Fri, Aug 1, 2014 at 2:24 AM, Hervé BOUTEMY
> wrote:
>
>> I replied on mojo (didn't see the cross-post)
>>
>> any help appreciated to improve the documentation :)
>>
>> Regards,
>>
>> Hervé
>>
>> Le vendredi 1 août 2014 11:05:43 dirk.mah...@buschmais.com a écrit :
>> > +1 from my side (see my questi.
>> >
>> > I tried using an extension for the question I asked some days ago
>> > (
>> http://mail-archives.apache.org/mod_mbox/maven-dev/201407.mbox/%3Ca2133e028
>> > cf3c18c539eac4d6cf42ed9.squirrel%40webmail.buschmais.com%3E) but it
>> seems
>> > not trivial - I ran into several classloading issues. Thus an example
>> would
>> > be very helpful.
>> >
>> > Best regards and thanks in advance
>> >
>> > Dirk
>> >
>> > > Ping
>> > >
>> > > On Thursday, July 31, 2014, Dan Tran wrote:
>> > >> Hi
>> > >>
>> > >> my P4Maven - a Maven SCM providers - has plexus component singleton
>> with
>> > >> states, and I would like to have the states to persist across
>> multiple
>> > >> plugins executions ( maven-scm-plugin, maven-release-plugin,
>> > >> buildnumber-maven-plugin, etc)
>> > >>
>> > >> I think using maven extension is way to go, but not sure how to get
>> this
>> > >> to work. Do you have a code sample somewhere?
>> > >>
>> > >> Huge thanks ahead
>> > >>
>> > >> -Dan
>> >
>> > -
>> > 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: https://github.com/apache/maven-scm/pull/17
that's just the beginning... so: how did you execute it? what did you get? what would you expect? Op Wed, 10 Sep 2014 20:54:49 +0200 schreef Benson Margulies : Aha, I have one for you. https://github.com/bimargulies/pom-file-name-tc. I attached it to a dup JIRA which I closed, or you can take it as you see it. You may in general find MRELEASE-887 helpful in this respect. On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte wrote: Hi, IIRC I didn't have enough info to make a unittest, i.e. reproduce what they get right now and what they would expect to be able to fix it. That would take me too much time to find out, so I left this one open for now. thanks, Robert Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < bimargul...@gmail.com>: Yes, the remarks which dribbled off pointed to adapting the fix back into the m-r-p. On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise wrote: Hi Benson, > Is anyone working on a fix to MRELEASE-875? Based on JIRA it is assigned to Dominik Bartholdi which requested reviews from others on Github... BTW: Not working on that... 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: https://github.com/apache/maven-scm/pull/17
Aha, I have one for you. https://github.com/bimargulies/pom-file-name-tc. I attached it to a dup JIRA which I closed, or you can take it as you see it. You may in general find MRELEASE-887 helpful in this respect. On Wed, Sep 10, 2014 at 2:53 PM, Robert Scholte wrote: > Hi, > > IIRC I didn't have enough info to make a unittest, i.e. reproduce what > they get right now and what they would expect to be able to fix it. > That would take me too much time to find out, so I left this one open for > now. > > thanks, > Robert > > Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > > Yes, the remarks which dribbled off pointed to adapting the fix back into >> the m-r-p. >> >> >> On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise >> wrote: >> >> Hi Benson, >>> >>> > Is anyone working on a fix to MRELEASE-875? >>> >>> Based on JIRA it is assigned to Dominik Bartholdi which requested >>> reviews >>> from others on Github... >>> >>> BTW: Not working on that... >>> >>> 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: https://github.com/apache/maven-scm/pull/17
Hi, IIRC I didn't have enough info to make a unittest, i.e. reproduce what they get right now and what they would expect to be able to fix it. That would take me too much time to find out, so I left this one open for now. thanks, Robert Op Wed, 10 Sep 2014 20:23:07 +0200 schreef Benson Margulies : Yes, the remarks which dribbled off pointed to adapting the fix back into the m-r-p. On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise wrote: Hi Benson, > Is anyone working on a fix to MRELEASE-875? Based on JIRA it is assigned to Dominik Bartholdi which requested reviews from others on Github... BTW: Not working on that... 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: https://github.com/apache/maven-scm/pull/17
Yes, the remarks which dribbled off pointed to adapting the fix back into the m-r-p. On Wed, Sep 10, 2014 at 2:21 PM, Karl Heinz Marbaise wrote: > Hi Benson, > > > Is anyone working on a fix to MRELEASE-875? > >> >> > Based on JIRA it is assigned to Dominik Bartholdi which requested reviews > from others on Github... > > BTW: Not working on that... > > 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: https://github.com/apache/maven-scm/pull/17
Hi Benson, > Is anyone working on a fix to MRELEASE-875? Based on JIRA it is assigned to Dominik Bartholdi which requested reviews from others on Github... BTW: Not working on that... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
https://github.com/apache/maven-scm/pull/17
Is anyone working on a fix to MRELEASE-875?
Re: [jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
Sorry for the reply on list, my codehaus jira credentials seem to have gotten
messed up….
I would expect the best normal workflow would be to have the release plugin
create the work item, then attach the change sets to it. I have some evidence
that it is possible for external programs to do stuff like this, but I have no
idea how.
david jencks
On Sep 10, 2014, at 8:51 AM, "AShit Shah (JIRA)" wrote:
>
>[
> https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352607#comment-352607
> ]
>
> AShit Shah commented on SCM-775:
>
>
> Both options are fine.
>
> I think ANT have it via build.xml. I personally would prefer to have it via a
> -D option at command line and not hard-coded in pom.xml.
>
> I was thinking of creating one release build WI for every agile sprint. Not
> sue if this is right approach though.
>
>> Request for new optional parameter RTC (workItem) with release:prepare to
>> associate workitem with changesets got created during build process
>> -
>>
>>Key: SCM-775
>>URL: https://jira.codehaus.org/browse/SCM-775
>>Project: Maven SCM
>> Issue Type: Improvement
>> Components: maven-scm-provider-jazz
>> Affects Versions: 1.9.1
>> Reporter: AShit Shah
>>
>> Maven {{release:prepare}} command is failing with below error while
>> delivering updated pom.xml to the stream due to Preconditions configured in
>> RTC to have comments and associated work item with every delivery.
>> [ERROR] Name: Deliver
>> [ERROR] Participant Reports:
>> [ERROR] Name: Require Work items and Comments
>> [ERROR] A work item must be associated with the change set.`
>> [ERROR] At least one of the associated work items must specify that the work
>> is planned for the current iteration.
>> [ERROR] At least one of the associated work items must be assigned to you.
>> [ERROR] Problem running 'deliver':
>> [ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
>> be associated with the change set.
>> [ERROR] -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>> goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
>> on project junit-ext: Unable to commit files
>> Provider message:
>> Error code for Jazz SCM deliver command - 17
>> I can not find any optional parameters on
>> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
>> for release:prepare command which I can use and pass the RTC workitem number
>> on command line.
>> Suggestion:
>> It will be great if you can provide optional parameters like "workItem"
>> which I can use and pass RTC workitem number with release:prepare at command
>> line.
>> Example: mvn -PmyProfile release:prepare -DworkItem=123456
>> So build process should associate change sets created by release:prepare
>> with work item 123456 and deliver change sets to the stream.
>> As of now I have to use "-DpushChanges=false" parameter to block delivery
>> process and I have to manually find the change sets, associate them with
>> work item and deliver them before I run release:perform.
>> Thanks.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1.6#6162)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven RAR Plugin version 2.4
Here my +1 Kind regards Karl-Heinz Marbaise On 9/8/14 9:47 PM, Karl Heinz Marbaise wrote: Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11143&version=18707 There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MRAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1053 http://repository.apache.org/content/repositories/maven-1053/org/apache/maven/plugins/maven-rar-plugin/2.4/maven-rar-plugin-2.4-source-release.zip Source release checksum(s): maven-rar-plugin-source-release.zip sha1: e38b3f99f203d690b5de863710ba978d1c145566 Staging site: http://maven.apache.org/plugins-archives/maven-rar-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
