[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] Re: Tutorial for building an RCP from hudson
|
Hi Thomas,
comments inline as well
Thomas Hallgren schrieb:
Hi Johannes,
Comments inline...
Johannes Utzig wrote:
!MESSAGE Missing requirement: Equinox Provisioning Engine
1.0.100.v20090525 (org.eclipse.equinox.p2.engine 1.0.100.v20090525)
requires 'package org.eclipse.equinox.internal.p2.persistence 0.0.0'
but it could not be found
This sounds like a regression of some kind. It used to work but it's
been a while since anyone tried it.
I see :)
First of all, do you think a tutorial like that would make sense in
the wiki?
Yes, absolutely. I think it's great that you do this. We are in a bad
shape when it comes to examples and tutorials so a contribution like
that is very valuable and appreciated.
I'm glad you like the idea
And if so, do you agree with the way I'm building things, or should I
change something for the wiki page?
I agree that the sample should have an RMAP of its own but I'm not too
keen about using an approach where Hudson populates the workspace. By
doing that, you bypass the whole resolution/materialization piece in
Buckminster. Not so good if the purpose is to use it all as an example.
It would also impede future examples of more advanced features such as
CQUERY based branch/tag selection.
I don't think it's really bypassing. Materialization takes still place
(kinda :) )since there is no workspace, just checked out modules.
Resolution also takes place, just a simplified version with only two
possible location: filesystem or target platform (other would be
possible as well if you want for example some maven artifacts from your
company's repository).
The simple file-system resolution makes a lot of things easier for
Hudson in my opinion:
-you do not need to configure VCS credentials since this is done
globally (by the administrator) in the hudson config
-you get the change log on every build
-the logs can be used to do advanced automated stuff like blaming test
failures, updating bugzilla, report and changelog generation...
-workspaces do not usually get deleted in hudson before/after a build
and I'm not even sure if buckminster can do a cvs/svn update, or if you
always have to do a full checkout (which is way slower). If it can, the
only way to achieve this would be to maintain an additional mspec, or is
there another way?
But I definetly do get your point, for an example it would make sense to
demonstrate the buckminster capabilities, I'm just not so sure if it
really is the best, or rather, easiest approach in a CI server.
Would it be possible to make Hudson understand that it should use
Buckminster as the check-out tool? Or perhaps we could make Hudson use
the information that it finds in a BOM file (the intermediate file that
Buckminster creates when it runs the resolver) to do the check-out?
That actually sounds very interesting. I can't answer that just now, but
I will think about how that could be done.
However, if for example the buckminster hudson plugin would also
register itself as as SCM plugin there's still the question I asked
above: can buckminster currently do svn, cvs, perforce,... updates, or
only checkout? Can the commit comments be retrieved? Can it be done
without an additional mspec?
Without commit logs, updates in favor of full check-outs and globally
configured credientials, I doubt that many hudson users would do the
check out with buckminster.
But I definetly like the idea, and if you think that there is a way to
preserve those features, then I'd be in.
About the later (using the bom to check-out) I'm not completly sure, but
I don't think it will work because SCM plugins always run before build
plugins run and all the check-out/update stuff is not done by the hudson
core, but specific plugins depending on the SCM in use. I'll have a look
but I don't think it could currently be done without changing a lot of
hudson code for this very special use-case.
To make the example really useful for people, the mail app would need
to be buildable and I'd need the extra files available in SVN (see
attached patch). Would you be willing to apply the patch and
eventually host the new cquery that points to the simplified
local-resolution rmap (I'll deliver both if you are ok with my general
approach) so that they will be available for public?
Yes, we'd be willing to do that. I think you should open a bugzilla
where you can paste a copy of this discussion and then attach patches.
The reason for that is that Eclipse.org cannot accept patches unless
they come as proper bugzilla attachments. An accepted patch also means
that your name is added to the contributor list of our IP-log.
Regards,
Thomas Hallgren
Ok, done. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=281503
I hope it is ok like that...
Best regards,
Johannes
