| Re: [buckminster-dev] different update site for a plugin [message #882207] |
Wed, 06 June 2012 03:41  |
 denny
Messages: 6
Registered: July 2009 |
Junior Member |
|
|
On 6/5/12 6:22 PM, Wim Jongman wrote:
> Hi,
>
> The site feature should only contain the features that you want in your
> site:
>
> this is our setup:
>
> importtargetdefinition '-A'
> '${WORKSPACE}/com.remainsoftware.td.releng.feature/TDOMS Base Target
> Hudson.target'
> import '${WORKSPACE}/com.remainsoftware.td.releng.feature/oms_all.cquery'
> build
> perform '-Q' '-D' 'target.os=*' '-D' 'target.ws=*' '-D' 'target.arch=*'
> '-Dcbi.include.source=false' 'com.remainsoftware.td.releng.feature#site.p2'
>
> This "releng" feature only contains other features (no bundles) and only
> the features that we want in our update site.
My version of the "releng" feature only has the feature I want in the
site, but that feature has the plugin, which is the same plugin I used
for the product.
Maybe I should have a different plugin for the product? That would make
pretty good sense as to what I'm seeing. This is the first time I've
messed with products in a few years, and I just tacked it onto the
existing plugin.
I'll try moving the product to a plugin just for the product, and see if
the generated site for the then isolated feature works. That's probably
the way god intended it anyhow.
>From yet another plugin project (separate project), which had a product
associated with it from years ago, I noticed that when I ran the
buckminster build against it that the product def was picked up
automatically (it had been ignored the way I'd been building/deploying
the plugin before, via eclipse with an update site the old fashioned way).
So bucky is actually being true-er to the build than what I was doing
before (the product def *is* in the plugin, after all).
This seems a plausible scenario. I'll do some more experimenting and
see what I get. If I cannot figure it out I'll do a new post to the
user group.
>
> By the way, we also save the resolved target platform because that contains
> all the foreign features. we give this to customers that cannot go to the
> internet to resolve the dependencies.
That is an excellent idea!
Thank you Wim!
:Denny
--
One can always reason with reason.
~ Heri Bergson
|
|
|
| Re: [buckminster-dev] different update site for a plugin [message #882259 is a reply to message #882207] |
Wed, 06 June 2012 06:15  |
|
Hi Denny,
One important thing to remember during publishing is the differentiation between what you provide yourself and the
features and plug-in that others provide. Both types might exist in various places of the transitive dependency graph
that extends from a plug-in. Buckminster will only traverse the first type.
As a rule of thumb, the two types of dependencies should be kept separate in a feature. The feature has 'Includes' and
'Requirements'. The former will form dependencies that have an exact version requirement (this is what creates the exact
set of things to install) whereas the version requirement of the latter is more relaxed to allow the feature to co-exist
with other features that also use the same set of third-party features and plug-ins.
When Buckminster generates a site, it will not consider dependencies introduced with the latter as something that must
be included. It will bring in all of the former though, since that's considered the set of things that make out your
feature.
Another important mechanism that will have an effect of what gets pulled in is whether you're using bundle or package
requirements in your OSGi manifests. Buckminster will never traverse a package requirement so if you want full control,
then use package requirements everywhere and then describe what plug-ins to use to fulfill those requirements with your
features.
Perhaps this piece of information can help you limit what gets pulled in to your update site.
Kind Regards,
Thomas Hallgren
|
|
|
|
Powered by
FUDForum. Page generated in 0.03111 seconds
] 
Search
Help
Register
Login
Home
