Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » What needs to be defined in the target platform(and what is resolved automagically by Buckminster?)
What needs to be defined in the target platform [message #556406] Wed, 01 September 2010 08:17 Go to next message
Tomsen  is currently offline Tomsen Friend
Messages: 42
Registered: July 2010
Member
Hi there,
I would like to get a clear idea on what I have to provide in my target platform definition and what Buckminster automatically adds to the TP.
My setup looks like

  • Buckminster 3.6 (on Helios)
  • Target Platform: 3.5


I have various dependencies like Gef, Emf etc and I would like to know if I have to provide them in my target platform definition or if Buckminster can add them to my target platform for me.

Right now it looks as if I have to provide them in the TP def because I get 3.6 plugins in the final collection despite my .rmap only points to 3.5 repositories.
Thomas Hallgren mentioned already that the default resolution path for Buckminster contains the Buckminster install as well, so this would be the source of the 3.6 plugins.
Since the repository location I defined in the .rmap should provide all necessary dependencies (Galileo release site) I don't understand why Buckminster resolves stuff first against the Buckminster install (which is 3.6) and does not seem to bother with the 3.5 repos.
I only seem to get around this problem when I fully configure the necessary features/plugins in the Target Platform. If I don't I get the 3.6 plugins.

Now, finally, my question: Is this how it is supposed to be? From what I read so far I was under the impression the resolution of missing features can be done by Buckminster which adds these to the TP as needed. Is this correct or not quite and I am missing a point here? Sorry for the ignorance.

best regards

Thomas
Re: What needs to be defined in the target platform [message #556414 is a reply to message #556406] Wed, 01 September 2010 09:08 Go to previous messageGo to next message
Peter Kullmann is currently offline Peter KullmannFriend
Messages: 240
Registered: July 2009
Senior Member
Buckminster can only "see" bundle-dependencies from bundles. It does
nothing with package dependencies. So, theoretically if none of your
bundles rely on package dependencies you could work without an explicit
target component and let buckminster resolve all the stuff. (Features
can have three types of dependencies, ie included bundles, included
features and the so called feature dependencies. The last type is
ignored by buckminster).

In our projects we usually have (some) package dependencies and
sometimes (for small components) feature dependencies. We therefore
always use an explicit target component which we materialize before the
actual sources. I usually have a feature for the target but sometimes
also take a buckminster cspec. In the target I usually have eclipse
platform and some other packages like emf. The target component does not
necessarily have to provide every single item in the target. When
resolving my real bundles it can happen that some additional binaries
are being materialized into the target platform.

When I design a new target platform I usually just start with either
eclipse platform or perhaps with nothing at all and see what happens
when I materialize my bundles and features. Either buckminster tries to
pull stuff that I don't want (like your 3.6 bundles). In this case I add
the correct stuff to my target and try again. Then perhaps I can see
that I have missing package dependencies (org.apache.commons.logging is
a typical one for us). So, I have to supply one of the many logging
systems in my target. And so on and on.

HTH,
Peter


Tomsen schrieb:
> Hi there,
> I would like to get a clear idea on what I have to provide in my target
> platform definition and what Buckminster automatically adds to the TP.
> My setup looks like
> Buckminster 3.6 (on Helios)
> Target Platform: 3.5
>
>
> I have various dependencies like Gef, Emf etc and I would like to know
> if I have to provide them in my target platform definition or if
> Buckminster can add them to my target platform for me.
> Right now it looks as if I have to provide them in the TP def because I
> get 3.6 plugins in the final collection despite my .rmap only points to
> 3.5 repositories. Thomas Hallgren mentioned already that the default
> resolution path for Buckminster contains the Buckminster install as
> well, so this would be the source of the 3.6 plugins. Since the
> repository location I defined in the .rmap should provide all necessary
> dependencies (Galileo release site) I don't understand why Buckminster
> resolves stuff first against the Buckminster install (which is 3.6) and
> does not seem to bother with the 3.5 repos. I only seem to get around
> this problem when I fully configure the necessary features/plugins in
> the Target Platform. If I don't I get the 3.6 plugins.
> Now, finally, my question: Is this how it is supposed to be? From what I
> read so far I was under the impression the resolution of missing
> features can be done by Buckminster which adds these to the TP as
> needed. Is this correct or not quite and I am missing a point here?
> Sorry for the ignorance.
> best regards
>
> Thomas
Re: What needs to be defined in the target platform [message #556418 is a reply to message #556406] Wed, 01 September 2010 09:20 Go to previous message
Tomsen  is currently offline Tomsen Friend
Messages: 42
Registered: July 2010
Member
Thanks Peter, this does clarify some things. We use some feature dependencies so this might be one of my problems. I'll extend my target platform then and see how it goes from there.

-Thomas
Previous Topic:Changing contents of a file before p2 is build
Next Topic:cquery with property expansion?
Goto Forum:
  


Current Time: Thu Apr 25 05:01:48 GMT 2024

Powered by FUDForum. Page generated in 0.02751 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top