I fully agree with James, I never used the module reporting and I the action to remove undefined Modules does not add any added value either. The less configuration required the better and thats where this type really shines. Also its integration with the m2release plugin is what cuts down the number of required Jobs a lot. Domi
On 25.09.2014, at 09:53, James Nord (jnord) <jn...@cisco.com> wrote: > Hi Stephen, > > I'm not sure why you think that per module reporting is the killer feature. > > For me I couldn’t give a hoot if I saw all reports from maven modules munged > in a single report or spread across 100 different pages (in fact I generally > use the top level aggregate anyway). > > What's the killer feature is > 1) automatic (zero conf) finding of artifacts / test reports / findbugs > report pickup etc etc... > > And also being able to lock down what the CI system will run to deploy... > That is if some devs have control of their own builds when an enforcer rule > fails (your build is not repeatable) they will look up enforcer and add > -Denforcer.skip > Yes they could add <phase>none</phase> to the enforcer config - but the ones > that are intelligent enough to do that know better and fix the issue rather > than hide it! > Neither of the above are possible with the literate job type. > > /James > > >> -----Original Message----- >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] >> Sent: 23 September 2014 19:44 >> To: Maven Users List >> Subject: Re: usage with Jenkins >> >> FYI my aim is to supersede the evil job type with some enhanced reporting in >> what is currently called the literate job type. >> >> That would mean you'd get the per-module reporting. >> >> The current evil job type's other "killer" feature is automatic downstream >> job >> triggering... Which is actually broken as it does not take into account the >> local >> repo that the -SNAPSHOTs may or may not have been deployed into and >> assumes that `package` is the same as `deploy` as far as triggering is >> concerned as well as ignoring that deployment might be to a staging repo, so >> the artifacts may not be available downstream... However, despite being >> fundamentally broken at every level, you would be surprised how many >> people feel locked into the evil job type because of this... >> >> In short, there is so many issues with it that I cannot recommend its use... >> The only semi useful feature from my PoV is per module reporting. >> >> (Sadly my day job has me having to support the evil job type from time to >> time... Though usually those tickets get picked up by Kohsuke if I start >> another "evil job type" tirade ;-) ) >> >> On Tuesday, 23 September 2014, Curtis Rueden <ctrue...@wisc.edu> >> wrote: >> >>> Hi James, >>> >>>> I can no longer see "Deploy artifacts to Maven repository" >>>> as a post-build action. >>> >>> Just add a build step that does "mvn deploy" or similar. >>> >>>> Dare I ask what I'm missing having chosen the full-fat option..? >>> >>> If you're asking what you cannot do with freeform jobs: I don't know >>> of anything. I think the Maven-style job is just a convenience to get >>> very basic CI set up as quickly as possible, for people without much >>> technical know-how. >>> >>> If you're asking for more details on limitations of the Maven-style job: >>> it's been awhile, but IIRC my group had several problems. One such was >>> that the Jenkins Git plugin did not fire Maven-style jobs upon >>> receiving the push notification from GitHub. Another really serious >>> problem is that you can't add arbitrary shell script as a post-build >>> step. And needing to do this is, in my experience, extremely common. >>> >>> It wouldn't be that big of an issue if there were an easy way to later >>> "convert" a Maven-style job to a freestyle job should the need arise. >>> But try a web search on that topic and you'll see what I mean about it >>> being a highly non-trivial problem. >>> >>> Regards, >>> Curtis >>> >>> On Tue, Sep 23, 2014 at 8:56 AM, James Green >> <james.mk.gr...@gmail.com >>> <javascript:;>> >>> wrote: >>> >>>> News to me. Ironically I'm just setting up a new Jenkins job so >>>> tried the freeform style - I can no longer see "Deploy artifacts to >>>> Maven >>> repository" >>>> as a post-build action. >>>> >>>> Dare I ask what I'm missing having chosen the full-fat option..? >>>> >>>> On 23 September 2014 14:02, Curtis Rueden <ctrue...@wisc.edu >>> <javascript:;>> wrote: >>>> >>>>> The Maven style build will also lock you in to a small subset of >>>> Jenkins's >>>>> usual features. And when you eventually need a feature not >>>>> available >>>> with a >>>>> Maven-style build, there is no conversion path from Maven-style to >>>>> Freestyle -- you have to recreate the job (losing the build >>>>> history >>>> etc.). >>>>> >>>>> -Curtis >>>>> On Sep 23, 2014 7:33 AM, "Stephen Connolly" < >>>>> stephen.alan.conno...@gmail.com <javascript:;>> >>>>> wrote: >>>>> >>>>>> Freestyle does not mess with your build and change it from >>>>>> building >>> the >>>>> way >>>>>> maven intends. Google "stephen's java adventures Jenkins maven >>>> considered >>>>>> evil" for a more detailed discussion >>>>>> >>>>>> On Tuesday, 23 September 2014, James Green >>>>>> <james.mk.gr...@gmail.com >>> <javascript:;>> >>>>>> wrote: >>>>>> >>>>>>> On 23 September 2014 02:23, Curtis Rueden <ctrue...@wisc.edu >>> <javascript:;> >>>>>>> <javascript:;>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Also, stay away from the Jenkins "Maven" style job. >>>>>>>> Freestyle is >>>> more >>>>>>>> flexible and less buggy. >>>>>>>> >>>>>>> >>>>>>> Based on ..? >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from my phone >>>>>> >>>>> >>>> >>> >> >> >> -- >> Sent from my phone > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
