Cool ! Thanks a lot Robert (and Ben). Cheers Le 7 août 2013 21:28, "Robert Scholte" <[email protected]> a écrit :
> https://jira.codehaus.org/**browse/HAUS-2316<https://jira.codehaus.org/browse/HAUS-2316>and > fixed > > On Tue, 06 Aug 2013 23:27:34 +0200, Baptiste MATHUS <[email protected]> > wrote: > > Hi all, >> >> For the record, I just played a bit with the extra-enforcer-rules bamboo >> configuration. I manually scheduled a build but this should still take >> some >> time before it begins since there's only two agents and one seems stuck. >> See >> https://bamboo-ci.codehaus.**org/build/admin/edit/** >> editBuildTasks.action?**buildKey=MOJO-**MEXTRAENFORCERRULES-JOB1<https://bamboo-ci.codehaus.org/build/admin/edit/editBuildTasks.action?buildKey=MOJO-MEXTRAENFORCERRULES-JOB1> >> for >> details. >> >> For those interested, I added two executions of "mvn clean verify >> -DenforcerPluginVersion=1.3.1" with m221 and m3. I might have added more >> combinations, but it's actually a bit cumbersome to configure many "axis" >> (IIUC, you actually have to add more executions and just configure each >> one >> separately. Matrix builds, I miss you here ;-)). >> >> Btw, Robert, as you talk about it, I think that we should actually ask for >> m3.1 installation isn't it? Or do you think we better wait for m3.1.1? >> >> Cheers >> >> >> 2013/7/31 Robert Scholte <[email protected]> >> >> Hi Baptiste, >>> >>> not sure why you think that we only build with M2.2.1, see >>> https://bamboo-ci.codehaus.****org/build/admin/edit/**** >>> editBuildTasks.action? >>> **buildKey=MOJO-MAPPASM-JOB1<h**ttps://bamboo-ci.codehaus.org/** >>> build/admin/edit/**editBuildTasks.action?**buildKey=MOJO-MAPPASM-JOB1<https://bamboo-ci.codehaus.org/build/admin/edit/editBuildTasks.action?buildKey=MOJO-MAPPASM-JOB1> >>> > >>> This is probably a good example of a lot of combinations of JDKs and >>> Maven >>> versions, both M2 and M3. >>> Ben has installed specific versions of Maven for me in he past, so it >>> shouldn't be too hard to get M3.1 here as well. >>> >>> I recently noticed that the aggregator has been disabled because it >>> claims >>> a lot of diskspace. This is probably caused by local repo's per plugin >>> for >>> the ITs, so we need think of a way to clean it up afterwards. With >>> Jenkins >>> we will have the same problem. >>> >>> Yes, there's one important downside with bamboo infrastructure: IIRC due >>> to the agents-setup you can't access the workspace. So you have to do it >>> with the logging or ask support@ to send you a zip. >>> I'm only interested in Jenkins if it stays within the Codehaus >>> infrastructure, i.e. controlled through xircles. >>> >>> If you need help with some specific plugins to run with Bamboo, just PM >>> me >>> with your concrete ideas/questions. >>> >>> Robert >>> >>> >>> >>> On Wed, 31 Jul 2013 14:10:25 +0200, Baptiste MATHUS <[email protected]> >>> wrote: >>> >>> Hi all, >>> >>>> >>>> I was thinking about the fact that IIUC we currently build in Bamboo >>>> only >>>> with one version of Maven (2.2.1). Sure, YMMV, but I remember digging a >>>> bit >>>> to see how to change it and I found it was a bit complicated and/or slow >>>> (granted, I don't know bamboo). >>>> >>>> I wonder if using Jenkins it wouln't be a little simpler to handle >>>> multi-aspects testing (*matrix builds*, I'm looking at you). >>>> >>>> >>>> We could in fact come up with a quite standard matrix build template for >>>> any plugin @MOJO to test for example different maven versions, different >>>> JDK, or even different parameters values (thinking of >>>> extra-enforcer-rules >>>> for examples, where we could test against the differen m-e-p versions >>>> quite >>>> easily using a matrix build). >>>> >>>> Maybe we could ask CloudBees to see if they can provide the >>>> corresponding >>>> required infra? Or ask for Jenkins@MOJO? >>>> >>>> WDYT? >>>> >>>> Thanks >>>> >>>> 2013/3/22 Stephen Connolly <stephen.alan.connolly@gmail.****com< >>>> stephen.alan.connolly@**gmail.com <[email protected]>> >>>> > >>>> >>>> There are things we can do with the RBAC plugin and folders that might >>>> >>>>> solve those issues... but I need to chat with Ben as to how to delegate >>>>> auth for a mojo project jenkins to xircles... >>>>> >>>>> >>>>> On 22 March 2013 12:17, Mirko Friedenhagen <[email protected]>** >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>>> >>>>>> I would like Jenkins better for codehaus as well (I hope I may reuse >>>>>> the >>>>>> account data from codehaus, jenkins-on-cloudbees e.g. would like to >>>>>> get >>>>>> insight into public *and* private repositories on github, which makes >>>>>> it a >>>>>> no-go for me). >>>>>> >>>>>> Regards Mirko >>>>>> -- >>>>>> Sent from my mobile >>>>>> On Mar 21, 2013 10:08 AM, "Stephen Connolly" < >>>>>> stephen.alan.connolly@gmail.****com <stephen.alan.connolly@gmail.** >>>>>> com <[email protected]>>> >>>>>> wrote: >>>>>> >>>>>> Well not suggesting *codehaus* abandon it. Just that we set up a JaaS >>>>>> >>>>>>> for the mojo project >>>>>>> >>>>>>> On Thursday, 21 March 2013, Baptiste MATHUS wrote: >>>>>>> >>>>>>> Sure, I personnally know Jenkins a lot better and sure would be more >>>>>>> >>>>>>>> comfortable with it. >>>>>>>> But I also like JIRA and don't know if atlassian would be happy with >>>>>>>> us >>>>>>>> ditching bamboo in favor of Jenkins. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> 2013/3/20 Stephen Connolly <stephen.alan.connolly@gmail.****com< >>>>>>>> stephen.alan.connolly@**gmail.com <[email protected]> >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> Do we want a Jenkins at CloudBees? Might be easier for people to >>>>>>>> grok? >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, 19 March 2013, Robert Scholte wrote: >>>>>>>> >>>>>>>> Let me go through all the jobs. >>>>>>>> It looks to me something has changed, because I'm pretty sure I >>>>>>>> configured notifications for failed builds and first successful to >>>>>>>> all >>>>>>>> committers (users who have committed to the build) for every mojo >>>>>>>> job. >>>>>>>> >>>>>>>> No real need to keep checking Bamboo as long as its green ;) >>>>>>>> >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> On Mon, 18 Mar 2013 22:57:52 +0100, Baptiste MATHUS < >>>>>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> FYI, I just committed the corresponding fix/evolution. CI is now >>>>>>>> back >>>>>>>> to >>>>>>>> green (thanks Mirko for noticing it, I'll watch it better next >>>>>>>> time). >>>>>>>> >>>>>>>> I'm gonna launch the 3rd try :-). >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> 2013/3/17 Arnaud Héritier <[email protected]> >>>>>>>> >>>>>>>> I'm in favor to have just a warning. >>>>>>>> It's enough >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Mar 17, 2013 at 9:25 PM, Baptiste MATHUS < >>>>>>>> [email protected] >>>>>>>> >wrote: >>>>>>>> >>>>>>>> Yup, I was just copying the code ;-). Thanks. >>>>>>>> >>>>>>>> Btw, I'm gonna just display a warning. But if you feel we should >>>>>>>> fail >>>>>>>> the >>>>>>>> build, just let me know. >>>>>>>> I feel this might be counter-productive to fail the build for that. >>>>>>>> People might in fact allow running 2.x and 3.x versions of maven on >>>>>>>> the >>>>>>>> same build, and failing here even if there's actually no cycle might >>>>>>>> make >>>>>>>> them just remove that rule (banCircularDependencies). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2013/3/17 Arnaud Héritier <[email protected]> >>>>>>>> >>>>>>>> The RequireMavenVersion Rule may help ? >>>>>>>> >>>>>>>> https://svn.apache.org/repos/******asf/maven/enforcer/trunk/**<https://svn.apache.org/repos/****asf/maven/enforcer/trunk/**> >>>>>>>> **<https://svn.apache.org/repos/****asf/maven/enforcer/trunk/**<https://svn.apache.org/repos/**asf/maven/enforcer/trunk/**> >>>>>>>> > >>>>>>>> enforcer-rules/src/main/java/******org/apache/maven/plugins/** >>>>>>>> enforcer/RequireMavenVersion.******java<https://svn.apache.**org/**<https://svn.apache.org/**> >>>>>>>> repos/asf/maven/enforcer/****trunk/enforcer-rules/src/main/**** >>>>>>>> java/org/apache/maven/plugins/****enforcer/** >>>>>>>> RequireMavenVersion.**java<htt**ps://svn.apache.org/repos/asf/** >>>>>>>> maven/enforcer/trunk/enforcer-**rules/src/main/java/org/** >>>>>>>> apache/maven/plugins/enforcer/**RequireMavenVersion.java<https://svn.apache.org/repos/asf/maven/enforcer/trunk/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireMavenVersion.java> >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Mar 17, 2013 at 9:12 PM, Baptiste MATHUS < >>>>>>>> [email protected] >>>>>>>> >wrote: >>>>>>>> >>>>>>>> OK, I'll go that way. >>>>>>>> If anyone sees this message just now and knows *the right way to >>>>>>>> check >>>>>>>> the maven version in use in an enforcer rule, I'm interested.* >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> 2013/3/17 Mirko Friedenhagen <[email protected]> >>>>>>>> >>>>>>>> I would prefer solution 1 and just document this behaviour (and set >>>>>>>> the Bamboo job to Maven 3). Otherwise you will have this switch in >>>>>>>> code, >>>>>>>> you should introduce two ITs, one with a failure status on Maven 3 >>>>>>>> and >>>>>>>> one >>>>>>>> with a skipped message on Maven 2. >>>>>>>> >>>>>>>> Honestly, new feature, new Maven should be no problem. >>>>>>>> >>>>>>>> Regards Mirko >>>>>>>> -- >>>>>>>> Sent from my mobile >>>>>>>> On Mar 16, 2013 10:42 PM, "Baptiste MATHUS" <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> In the circular IT, there's a circular dependency (now that's some >>>>>>>> news!). >>>>>>>> >>>>>>>> But M2 just ignores it silently, not M3. I think we hit >>>>>>>> http://jira.codehaus.org/******browse/MNG-1944<http://jira.codehaus.org/****browse/MNG-1944> >>>>>>>> <http://jira.**codehaus.org/**browse/MNG-1944<http://jira.codehaus.org/**browse/MNG-1944> >>>>>>>> **> >>>>>>>> <http://jira.**codehaus.org/**browse/MNG-1944<http://codehaus.org/browse/MNG-1944> >>>>>>>> <http://jira.**codehaus.org/browse/MNG-1944<http://jira.codehaus.org/browse/MNG-1944> >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> So, here we have an choice: either we >>>>>>>> 1) explicitly state (and check during execution?) that this rule can >>>>>>>> only be useful with M3 or >>>>>>>> 2) we simply remove it. >>>>>>>> >>>>>>>> I'd be for solution 1. I feel it's a valuable addition and as it >>>>>>>> works for the latest and greatest Maven, this makes sense to keep >>>>>>>> it. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>> 2013/3/15 Baptiste MATHUS <[email protected]> >>>>>>>> >>>>>>>> No problem, and true for the IT. >>>>>>>> I've copied the demo from the website and forgot to update that >>>>>>>> part. >>>>>>>> I can re-roll a release. Now >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Sent from my phone >>>>>>> >>>>>>> -- >>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net >>>>>>> Sauvez un arbre, >>>>>>> Mangez un castor ! nbsp;! >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>> -- >>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >>> >>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe from this list, please visit: >>> >>> >>> http://xircles.codehaus.org/****manage_email<http://xircles.codehaus.org/**manage_email> >>> <http://xircles.**codehaus.org/manage_email<http://xircles.codehaus.org/manage_email> >>> > >>> >>> >>> >>> >> >> > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > > ------------------------------**------------------------------**--------- > To unsubscribe from this list, please visit: > > > http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email> > > >
