- Use a free-style project with a Maven build step
- Use a Maven-style project
The first way runs the build as Maven intended. The second way adds a whole lot of hooks and can even modify the build in ways that Maven did not intend.
The first way requires that you configure stuff yourself. The second way tries to “guess” what you want and auto-configure it.
The first way is initially less user friendly, i.e. you have more UI to click through to get the full set of reports. The second way is initially more user friendly… but when things go wrong… well sorry out of luck.
If something goes wrong with the first way, worst case you add a shell build step above the Maven build step that just runs SET, trigger a build, login to the build slave, switch to the user the build is running as, apply the environment your SET build step output and then run the Maven command that the build’s console log captured. That will give you an exact reproduction of the Maven build and you can debug why your build is not working.
When something goes wrong with the second way, well good luck. By all means try to do the same as you would for a free-style project, but at the end of the day, there is no way you can replicate the injected hooks that Jenkins puts into your Maven build. You can get an approximate reproduction, and hey, that may just be enough to let you figure out what is wrong and fix your build… but there are cases where you cannot.
Hence why, since 2007, I have been saying that the Maven job type is considered evil…
- It has very attractive because is easy to configure (so users use it) and gives nice per-module reports
- When it blows up, and it will blow up, it blows up big
* well actually three ways§ if you include the literate job type
§ (Update 2017-08-01) well actually four ways if you include pipeline and the
withMaven helper
Well, and of course that the maven job type automatically archives all the built artifacts, which is of no small utility!
ReplyDeleteCould the gap not be partially closed by having a jenkins-maven-plugin, that could communicate back to the main jenkins instance these missing things (e.g: modules, build artifacts, etc) ?
It's a pretty sad indictment of Maven, however, that it's not possible to - safely - inject inspection points into it without it causing it to collapse in a heap..
It is possible to safely inject inspection points... the problem is that Jenkins' Maven job type injects mutation points that modify the effective pom that is executed...
ReplyDeletethe most trivial example is that Jenkins tells Maven to ignore test failures... I would not mind if it this this by prepending to the command line -Dmaven.test.failure.ignore=true so that you would see on the launched command line in the console log that it is the Maven job type adding the option... but instead it actually modifies the effective pom... thus if you have a module that has tests that should never be skipped and so you hard-code the configuration section of surefire so that skip is true and the system property will be ignored... sorry out of luck, Jenkins will override you
sorry testFailureIgnore is false not skip is true..., e.g.
ReplyDelete<configuration>
<testFailureIgnore>false</testFailureIgnore>
<configuration>
which will ensure that the module's tests cannot be skipped... except when the Maven job type is playing fast and loose with its auto-magic
Then there's the relatively recent loss of logging of the console output... https://issues.jenkins-ci.org/browse/JENKINS-19095
ReplyDeleteOld topic but....
ReplyDeleteWhat about the release maven plugin? it only works with maven-style jobs :(
And the other "features" like publish test results or the incremental builds? :S
release maven plugin: if it only works with the evil one then it should be put in the bin.
ReplyDeleteautomatic pick up of test results... I have a plan for that
incremental builds... that breaks so much that if you have it working you are likely doing other things wrong and removing it will actually only make your life easier