Brilliant! Ta! Now, to find the VM I was using... :)
-Chris On Wed, Mar 4, 2015 at 8:18 AM, Robert Scholte <rfscho...@apache.org> wrote: > We're already preparing a solution for Jira. So as long as Jira isn't > read-only, all issues and comments should be safe and will be included with > the migration. > > Robert > > Op Tue, 03 Mar 2015 22:11:18 +0100 schreef Chris Graham < > chrisgw...@gmail.com>: > > > Excellent! Jazz/RTC it's optional as well. UCM Clearcase is, but not >> ClearQuest Enabled UCM Clearcase (but that's the point of CQ!). >> >> Ok, I'll roll my sleeves up! >> >> So what is the current issue tracker now? Given that codehaus's is going >> away? >> >> I'll manually copy the live issues if need be. >> >> >> On Wed, Mar 4, 2015 at 7:54 AM, Robert Scholte <rfscho...@apache.org> >> wrote: >> >> Hi Chris, >>> >>> It seems like these are the only systems (only retweets of my question, >>> no >>> responses). >>> AFAIK for TFS is is optional, depending on how you configured it on your >>> server. >>> I haven't found a general term for this concept, so I would go for >>> workitem. >>> It looks indeed like the pushChanges option, so let's see if such an >>> implementation would fit. >>> >>> thanks, >>> Robert >>> >>> Op Thu, 26 Feb 2015 01:10:43 +0100 schreef Chris Graham < >>> chrisgw...@gmail.com>: >>> >>> >>> Hi Robert. >>> >>>> >>>> Yes, it's time that I think we should. :) >>>> >>>> I may have some time shortly to look into fixing the outstanding Jazz >>>> issues. >>>> >>>> Firstly, what do we call the >>>> workitemId/ticketNo/whateverelsethingsarecalled ? >>>> Where do we put it? I'd be tempted to put it in the same structure as >>>> pushChanges, as it's easily accessable and can be used across all scm >>>> providers. >>>> >>>> So you've said that MS TFS uses (is it optional or mandatory?) a >>>> workitem >>>> concept. Jazz does, and it's optional per workspace. What other SCM >>>> use/require a workitem concept? ClearQuest enabled UCM Clearcase has a >>>> task. Any others? >>>> >>>> -Chris >>>> >>>> >>>> On Thu, Sep 11, 2014 at 5:22 AM, Robert Scholte <rfscho...@apache.org> >>>> wrote: >>>> >>>> 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 < >>>>> chrisgw...@gmail.com>: >>>>> >>>>> >>>>> 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 <rfscho...@apache.org >>>>>> > >>>>>> 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 >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>> 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 > >
