Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » [buckminster-dev] A few general questions about Buckminster
[buckminster-dev] A few general questions about Buckminster [message #666598] Thu, 21 April 2011 08:48 Go to next message
Paul  is currently offline Paul
Messages: 7
Registered: November 2010
Junior Member
Hello Buckminster people,

Our development processes are getting painful. We have many OSGi bundles.

We are looking at introducing semantic versioning for our bundles (where
the versioning scheme looks be the same as omni versioning)

I am reading through different Buckminster articles and the buck book
and cannot see some answers to some questions I have:

Assume that I create a project per feature to hold my buckminster files
( a feature maybe made up of multiple bundles)

So using Buckminster, can I ....

Materialize these bundles in eclipse where buckminster uses the bundle
manifest to work out the required dependencies.

How could it do this if the bundle manifest only contains Import-Package
directives? Does it require a Require-Bundle directive instead to be
able to resolve other bundle dependencies?

We want to use version ranging? What sort of repository would our bundle
artifacts need to be in for Buckminster to be able to search for the
latest version of a bundle artifact?

Per feature we would need a specific target platform materialized so the
feature can be tested.

Sorry for the questions, just trying to get my head around a few things.


Thanks
Paul
Re: [buckminster-dev] A few general questions about Buckminster [message #666599 is a reply to message #666598] Thu, 21 April 2011 09:18 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Hi Paul,

I'll try to give you some answers here. You might want to direct future postings to our newsgroup buckminster [1] rather
than buckminster-dev since the latter is intended for discussions around the development of Buckminster itself.

On 2011-04-21 10:48, Paul French wrote:
> Hello Buckminster people,
>
> Our development processes are getting painful. We have many OSGi bundles.
>
> We are looking at introducing semantic versioning for our bundles (where the versioning scheme looks be the same as omni
> versioning)
>
> I am reading through different Buckminster articles and the buck book and cannot see some answers to some questions I have:
>
> Assume that I create a project per feature to hold my buckminster files ( a feature maybe made up of multiple bundles)
>
> So using Buckminster, can I ....
>
> Materialize these bundles in eclipse where buckminster uses the bundle manifest to work out the required dependencies.
>
Check.

> How could it do this if the bundle manifest only contains Import-Package directives? Does it require a Require-Bundle
> directive instead to be able to resolve other bundle dependencies?
>
Buckminster will not consider Import-Package directives. The approach that I'd recommend is to use a feature at the top
that describes your "product" or "installable". In this feature, you list all bundles that cannot be resolved by other
means. You can of course also rely on "Require-Bundle" if that suits you better. In the end, Buckminster must have
information about the name of the bundle somewhere.

> We want to use version ranging? What sort of repository would our bundle artifacts need to be in for Buckminster to be
> able to search for the latest version of a bundle artifact?
>
Buckminster will always search for everything it can find that is within range. Ideally, you'd use a p2 or maven2
repository. I say ideally since it contains all meta-data necessary to avoid scanning or downloading a lot of data. But
Buckminster is also capable of scanning branches or tags in a SCM (CVS, SVN, or Git repository) in order to find source.

If you already have repositories with custom meta-data, then it's very plausible that Buckminster can use them too. Let
me know if that's the case and I'll try to help.

> Per feature we would need a specific target platform materialized so the feature can be tested.
>
That shouldn't be a problem. But bear in mind that a workspace can only be attached to one target platform at a time.

> Sorry for the questions, just trying to get my head around a few things.
>
We like questions so please keep them coming (but preferably in the buckminster newsgroup).

Kind Regards,
Thomas Hallgren

[1] http://www.eclipse.org/forums/eclipse.tools.buckminster
Re: [buckminster-dev] A few general questions about Buckminster [message #666692 is a reply to message #666599] Thu, 21 April 2011 16:00 Go to previous messageGo to next message
Philip Borlin is currently offline Philip Borlin
Messages: 30
Registered: July 2009
Member
On Thu, Apr 21, 2011 at 3:18 AM, Thomas Hallgren <thomas@tada.se> wrote:
> On 2011-04-21 10:48, Paul French wrote:
>> How could it do this if the bundle manifest only contains Import-Package
>> directives? Does it require a Require-Bundle
>> directive instead to be able to resolve other bundle dependencies?
>>
> The approach that I'd recommend is to use a feature at the top that describes your "product"
> or "installable". In this feature, you list all bundles that cannot be
> resolved by other means.

I work on a fairly large OSGi application that builds with Buckminster
and I want to second the "put it in a feature" approach. We don't use
a "top" feature but manage this throughout our applications. So for
instance we may have a MarketingFeature and a AccountingFeature. We
use imported packages as much as possible and manage the specific
bundle versions in the appropriate feature. This way the team that is
working on the MarketingFeature specifies their bundle versions in
their feature and the team working on the AccountingFeature specifies
their bundle versions in their feature. This prevents us from having
one giant feature or product file that everyone in the company is just
adding bundles to.

-Phil
Re: [buckminster-dev] A few general questions about Buckminster [message #666693 is a reply to message #666599] Thu, 21 April 2011 16:27 Go to previous messageGo to next message
Paul  is currently offline Paul
Messages: 7
Registered: November 2010
Junior Member
I promise to use the news group once this thread is dead!!

Hello Phil,

Thanks for your input.

As you know "Require-Bundle" in an OSGi manifest is frowned upon in the
OSGi community. We do use "Import-Package" but I am now questioning why
bother since we have to specify it's bundle dependencies in a POM or CSPEC

So if I use "Require-Bundle" in the bundle manifest that should be
sufficient for buckminster to resolve my dependencies without the need
to maintain a "feature" CSPEC.

However it does mean by using Require-Bundle I am tying my bundle at
runtime to another specific bundle. Another bundle with a different
symbolic name could provide the required packages but would not be
picked up. I am in two minds at the moment what to do.

I think you have convinced me to create multiple feature projects like
you say.

We are also trying to use semantic versioning so developers need not
have to worry about compatibility between bundles. Enforcing it is the
hard bit but eclipse does offer support in this area (enable API analysis)

In an ideal world I want to grab a feature project from CVS and then use
Buckminster to materialize the relevant bundles in my workspace, as well
as a target platform and if possible the current baseline of the feature
to work against to enforce semantic versioning, a question I will ask on
the newsgroup shortly.

Thanks


On 21/04/2011 17:00, Phil Borlin wrote:
> On Thu, Apr 21, 2011 at 3:18 AM, Thomas Hallgren<thomas@tada.se> wrote:
>> On 2011-04-21 10:48, Paul French wrote:
>>> How could it do this if the bundle manifest only contains Import-Package
>>> directives? Does it require a Require-Bundle
>>> directive instead to be able to resolve other bundle dependencies?
>>>
>> The approach that I'd recommend is to use a feature at the top that describes your "product"
>> or "installable". In this feature, you list all bundles that cannot be
>> resolved by other means.
> I work on a fairly large OSGi application that builds with Buckminster
> and I want to second the "put it in a feature" approach. We don't use
> a "top" feature but manage this throughout our applications. So for
> instance we may have a MarketingFeature and a AccountingFeature. We
> use imported packages as much as possible and manage the specific
> bundle versions in the appropriate feature. This way the team that is
> working on the MarketingFeature specifies their bundle versions in
> their feature and the team working on the AccountingFeature specifies
> their bundle versions in their feature. This prevents us from having
> one giant feature or product file that everyone in the company is just
> adding bundles to.
>
> -Phil
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
Re: [buckminster-dev] A few general questions about Buckminster [message #666722 is a reply to message #666693] Thu, 21 April 2011 23:20 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 2500
Registered: July 2009
Senior Member
On 4/21/11 6:27 PM, Paul French wrote:

> As you know "Require-Bundle" in an OSGi manifest is frowned upon in the
> OSGi community. We do use "Import-Package" but I am now questioning why
> bother since we have to specify it's bundle dependencies in a POM or CSPEC
>
> So if I use "Require-Bundle" in the bundle manifest that should be
> sufficient for buckminster to resolve my dependencies without the need
> to maintain a "feature" CSPEC.
>
True.

I couple of notes:
- If you have a feature that lists dependencies, than that is sufficient
for buckminster, you do not need to have a CSPEC if you already have a
feature that specifies the dependencies.

- Require-Bundle and Import-Package are both useful mechanisms. If all
your dependencies are Import-Package, there is really nothing that
declares who is providing these packages and you need to declare that
elsewhere. Clearly, this is an issue when there are many to track. OTOH,
Require-Bundle makes it difficult to create flexible compositions.
Personally, I like using both; Require-Bundle when bundles are indeed
tied to each other and I don't expect there to be an alternate
implementation of the packages. Import-Package is great for things like
"icu" where there are two implementations to choose from (the full
(huge) package, or the base (smaller)).

> However it does mean by using Require-Bundle I am tying my bundle at
> runtime to another specific bundle. Another bundle with a different
> symbolic name could provide the required packages but would not be
> picked up. I am in two minds at the moment what to do.
>
Let the requirements for variability control what you use, and remember
that variability does not come for free.

> I think you have convinced me to create multiple feature projects like
> you say.
>
I think this sounds like a good approach. I don't think that you in most
situations can have 100% Require-Bundle and you do need something that
defines the "platform and basic services" (and so on, up the application
domain chain).

> We are also trying to use semantic versioning so developers need not
> have to worry about compatibility between bundles. Enforcing it is the
> hard bit but eclipse does offer support in this area (enable API analysis)
>
The hardest part is usually defining a good API in the first place (or
you will forever break the API).

As a side note, I find that using google guice for injection is a great
help as it makes it easy to construct software out of composable parts
(without having to have complicated factory logic throughout the system
- logic that at least I am way to lazy to write if I had to code
everything by hand). Guice is exceptionally good when there is a high
degree of variability.

> In an ideal world I want to grab a feature project from CVS and then use
> Buckminster to materialize the relevant bundles in my workspace, as well
> as a target platform and if possible the current baseline of the feature
> to work against to enforce semantic versioning, a question I will ask on
> the newsgroup shortly.
>
Looking forward to hear about your progress. There is support in
Buckminster for what you describe.

Regards
- henrik

> Thanks
>
>
> On 21/04/2011 17:00, Phil Borlin wrote:
>> On Thu, Apr 21, 2011 at 3:18 AM, Thomas Hallgren<thomas@tada.se> wrote:
>>> On 2011-04-21 10:48, Paul French wrote:
>>>> How could it do this if the bundle manifest only contains
>>>> Import-Package
>>>> directives? Does it require a Require-Bundle
>>>> directive instead to be able to resolve other bundle dependencies?
>>>>
>>> The approach that I'd recommend is to use a feature at the top that
>>> describes your "product"
>>> or "installable". In this feature, you list all bundles that cannot be
>>> resolved by other means.
>> I work on a fairly large OSGi application that builds with Buckminster
>> and I want to second the "put it in a feature" approach. We don't use
>> a "top" feature but manage this throughout our applications. So for
>> instance we may have a MarketingFeature and a AccountingFeature. We
>> use imported packages as much as possible and manage the specific
>> bundle versions in the appropriate feature. This way the team that is
>> working on the MarketingFeature specifies their bundle versions in
>> their feature and the team working on the AccountingFeature specifies
>> their bundle versions in their feature. This prevents us from having
>> one giant feature or product file that everyone in the company is just
>> adding bundles to.
>>
>> -Phil
>> _______________________________________________
>> buckminster-dev mailing list
>> buckminster-dev@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
Re: [buckminster-dev] A few general questions about Buckminster [message #666748 is a reply to message #666722] Fri, 22 April 2011 07:11 Go to previous messageGo to next message
Paul  is currently offline Paul
Messages: 7
Registered: November 2010
Junior Member
On 22/04/2011 00:20, Henrik Lindberg wrote:
> I couple of notes:
> - If you have a feature that lists dependencies, than that is
> sufficient for buckminster, you do not need to have a CSPEC if you
> already have a feature that specifies the dependencies.
I use the term feature in a conceptual sense. We do not have eclipse
features. We are running many plain OSGi bundles in Knopflerfish, so I
assume I need to create a cspec for my "feature"
>
> As a side note, I find that using google guice for injection is a
> great help as it makes it easy to construct software out of composable
> parts (without having to have complicated factory logic throughout the
> system - logic that at least I am way to lazy to write if I had to
> code everything by hand). Guice is exceptionally good when there is a
> high degree of variability.
>
I would love to use Spring DM or Guice but we are running on resource
restricted devices on J9 (jre 1.3 API with 1.4 bytecode). We have
written an extension of ServiceTracker that provides a proxy to a
service and so in most cases we manage to de-couple our code from OSGi,
except in the Activator where we wire things up directly
> Looking forward to hear about your progress. There is support in
> Buckminster for what you describe.
>
Me too!!! :@)

Paul
Re: [buckminster-dev] A few general questions about Buckminster [message #666762 is a reply to message #666748] Fri, 22 April 2011 10:12 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
On 04/22/2011 09:11 AM, Paul French wrote:
>
> I use the term feature in a conceptual sense. We do not have eclipse
> features. We are running many plain OSGi bundles in Knopflerfish, so I
> assume I need to create a cspec for my "feature"

Even if you feel that you have no use for a PDE feature, there might
still be benefits in adding such a project. Buckminster will maintain an
in-memory CSPEC from such a project that contains a lot of actions. One
of them is the 'site.p2' action that will create a p2 repository based
on the feature includes.

HTH,
Thomas Hallgren
Previous Topic:[buckminster-dev] Project meta data is out of date for tools.buckminster
Next Topic:[buckminster-dev] Buckminster+Hudson Problem resolving directories in target definition
Goto Forum:
  


Current Time: Sat Sep 20 20:09:52 GMT 2014

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

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