|Re: What needs to be defined in the target platform [message #556414 is a reply to message #556406]
||Wed, 01 September 2010 09:08
| Peter Kullmann
Registered: July 2009
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.
> 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
Powered by FUDForum
. Page generated in 0.01369 seconds