|
On 10/08/2014 03:33 AM, David M
Williams wrote:
Despite your loaded language, you
have
inadvertently given a good example ... of how *that* build is
inadequate.
:) [Seriously, just kidding, with my language, but there is a
"bug"
in that build, or some limitation, as Git history shows that
issue that
was fixed 7 days ago.]
Ok, thanks for this piece of information and catching a bug in the
build. I'll re-check the job configuration.
And, even faster detection of
that particular
type of problem can be achieved by installing the "releng
tool"
and turn on the preference that shows such POM/MANIFEST
version "mismatches"
directly in your workbench.
I believe the m2e-tycho connector checks that too. However, I don't
know what part of contributors are actually using releng tools or
enabling Tycho on Platform bundles.
While I won't waste our (and
reader's)
time arguing pros and cons on this list -- we both obviously
have our biases
about "the best" way to work -- I do believe there are many
ways
to do things. Some are very much "developer" oriented, and
some
people these days shy away from "self hosting" that others
embrace.
But, some methods are very much "adopter" oriented, which is
how I define "a production build" (to answer one of your
questions)
-- it is one that we deliver to the release train and adopters
as our official
downloads and repository. And we have a number of criteria for
those, such
as repeatability, maintainability, valid qualifiers, etc.,
An additional constraint I add to projects I work on is "anyone can
build locally or on a CI server by fetching code and running mvn
clean install", which guarantees more portability. The Hudson
eclipse-aggregator-master is meant at checking this constraint is
satisfied.
we've listed
a couple of times, and while not perfect, I think our current
production
build is headed in the right direction. If and when the PMC
decides someone
else should produce the production build, using what ever
methodology they
want, that's fine with me. But, for now, that's my assignment
... and I
do the best I can (with the help of a great many people ...
including you!).I think the Gerrit builds that others have set
up (and that I know little
about) serve a good, useful purpose for some people, for some
purposes,
but the end result is not production quality bits -- at least
for our large,
complicated project.
By "Gerrit builds", you mean "Hudson builds"? Builds verifying
Gerrit patches before they get merged are indeed not for production
as their purpose is to test suggested change before they get
accepted, but what's the difference that makes other jobs doing "mvn
clean verify" on latest aggregator repository not good for
production?
I know some people will say,
"Well, it could,
if you made the investment to refactor your repositories and
code so that
it better fit the Maven/Tycho model... " but ... as far as I
know
... no one is willing to make that large investment, up front,
and instead
we all try to make slow and incremental progress.
'Nough said? (I've already been
too
wordy. :) Appreciate your (and everyone's) help, and any
constructive
suggestion is always welcome. Its probably best to enter
those as
a bugzilla entries where issues/suggestions can be tracked and
prioritized
more easily along with everything else that needs to get done.
|
