[
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 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.
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.
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.
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?
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