[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] A few general questions about Buckminster
|
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@xxxxxxx> 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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/buckminster-dev
