Interesting...
I don't mean to hijack this thread (and please redirect me to where to
learn more), but how could I gain the automatic "snapshot dependency
change detection" provided by the "Maven" project type in a "Freestyle"
project type (without duplicating data already declared in the pom.xml)?
Dan
On 10/03/2011 07:51 AM, Stephen Connolly wrote:
On 3 October 2011 12:30, Miguel Almeida<[email protected]> wrote:
On Mon, Oct 3, 2011 at 10:44 AM, Stephen Connolly
<[email protected]> wrote:
I'm going to take a wild stab in the dark and guess that you are using
the "Maven" project type...
You're correct. I mean, it would be the obvious choice.
Don't use the "Maven" Project type.
What is the Maven project type then? "It's a mistake made by bad
programmers" is an easy answer.
Kohsuke is not a bad programmer, (I work with him and I would say far
from bad, more the other side of the spectrum), but perhaps he still
does not quite grok the "Maven way"... *
The "Maven" Project type was developed way way back in the day of
Jenkins, back in the double digit version numbers IIRC or perhaps in
the early 100's... back then KK did not grok the maven way at all...
the project type is a manifestation of that misunderstanding. It does
a number of things that are "just so wrong", but all to help users...
The net result is a project type that has lots of features that people
think are really cool... it's easy to set up, very little
configuration, per module reporting, etc... but once you hit a
problem, you are stuck because the build it does is not the same as
the build you do from the command line on that same machine as the
same user using the same command printed from the build log...
Now, it's mostly similar... unless you are using fancy plugins, in
general all that it will be doing differently is forcing m-surefire-p
to ignore test failures, and maybe redirecting m-deploy-p to deploy
somewhere else (so it can do the deploy for you at a later time)...
but the reality is you just don't know what it is doing without
digging into the source code of every plugin you have enabled...
I should say that most plugins would not be doing much to your
build... there are probably only about 3-4 plugin developers who know
how to go and muck about with the build config... and most limit the
changes to low impact: turn on XML report generation, etc. type
things... but it is the principal that is bad too... the principal
that a jenkins plugin can mutate the build in ways you don't know and
cannot reproduce by ensuring that your OS env, working directory and
command line are the same as Jenkins invokes...
Maven builds are supposed to be deterministic for any given OS,
environment variables, working directory, pom.xml and command line...
in fact it is strongly encouraged that you should have your build
deterministic for any pom.xml and command line, but [real world] we
can live with you having your build OS dependent, and toolchains
dependent [/real world] That is one aspect of the Maven way...
When I was in my previous job, I would always disable the Maven Plugin
in Jenkins... so that everyone would just use the FreeStyle project
type to build Maven jobs.... That is my personal opinion, you are free
to follow or ignore as you see fit...
In the M2 project type's defense... it does make it very easy to get a
project set up and going... it makes it easy to turn on static
analysis, code coverage, etc... you get per module reporting, etc...
but that does not mean _I_ have to like it!
;-)
-Stephen
*maybe I should phrase that differently... I think KK now groks the
"Maven way" he just doesn't believe in it _yet_ because he spent soo
much time not groking it ;-)
Cheers,
Miguel Almeida
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
