| Re: [buckminster-dev] different update site for a plugin [message #882207] |
Tue, 05 June 2012 23:41  |
Eclipse User |
|
|
|
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 #882271 is a reply to message #882259] |
Wed, 06 June 2012 02:48  |
| Eclipse User |
|
|
|
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br>
<br></blockquote><div><br></div><div>One thing to add to this (while we're at it) is the fact that it is sometimes very difficult to find the feature where any given plugin can be found. You might be tempted to skip the search and wind up just putting the plugin into some "additional.plugins.feature". This will bite yourself in the foot (i merged two expressions here on purpose). </div>
<div><br></div><div>For example, if you include draw2d as a separate plugin into this additional feature then your users might not be able to pull in the GEF products because of bundle dependency conflicts. </div><div><br>
</div><div>So always strive to be as "pure" as possible and only supply YOUR bundles and let other bundles be provided by their respective featured. </div><div><br></div><div>To aid in this a little, I have written the "Feature Explorer" plugin. This can be downloaded from the market place. </div>
<div><br></div><div>Furthermore, check out the Orbit project where you can find some lonely bundles flying around.</div><div><br></div><div>Regards,</div><div><br></div><div>Wim </div></div><br>
|
|
|
Powered by
FUDForum. Page generated in 0.04469 seconds
Home