On 25 September 2014 08:53, James Nord (jnord) <[email protected]> wrote:
> Hi Stephen, > > I'm not sure why you think that per module reporting is the killer feature. > > Well any time we suggest switching to freestyle, the feedback we get is "oh but we can't because we'd loose the per-module reports" > 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... > Well James, you do know *you* could use templates (as you have the enterprise plugins ;-) ) and give a locked down build. > > 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 > So you are missing the full context. The literate-api allows for different providers. There are actually two providers in literate-api at present: the README.md driven one and a .travis.yml driven one (with a very incomplete parser... but I always like to test plugable APIs with more than one implementation to make sure the design is right) The way I see literate having advanced Maven support is via two modes: 1. Wherein you specify the literate commands as being for a "maven shell"... something like > # Build > > We build with Maven using the following phases > > ```mvnsh > clean verify > ``` When I add asciidoc support, that has a much nicer way to specify the syntax 2. Wherein you just tell it to use the pom.xml directly (i.e. a literate-api pom based parser that is activated by just having a pom.xml in the root (plus a marker file to say this is a buildable branch) Then in the config for the literate job you would specify the goals you want executed for that parser > 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. > Not yet... but once I get the time to write some code... > > /James > > > > -----Original Message----- > > From: Stephen Connolly [mailto:[email protected]] > > 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 <[email protected]> > > 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 > > <[email protected] > > > <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 <[email protected] > > > <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" < > > > > > [email protected] <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 > > > > > > <[email protected] > > > <javascript:;>> > > > > > > wrote: > > > > > > > > > > > > > On 23 September 2014 02:23, Curtis Rueden <[email protected] > > > <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: [email protected] > For additional commands, e-mail: [email protected] >
