A lower level solution is to support excluding bundles, which would be the
opposite of import bundle, of course if there are more than two alternative
bundles, things start to get ugly
I believe constraining dependencies by profile would be very useful, I would
like to think of it in terms of: Stages and Scopes
The relevant Stages would be:
- compilation stage
- testing stage (which in itself could be broken down into things like:
unit testing stage, and integration testing stage)
- runtime stage
and example of the Scopes would be:
- *compile*: available during compiling application classes, compiling
tests classes, running tests, and included in run configuration
- *provided*: available during compiling application classes, compiling
tests classes, running unit tests, but not in run configuration as it would
be provided be some other means
- *unit test*: available during compiling tests classes, running unit
tests
- *integration test*:available during compiling tests classes, running
integration tests
for the specific case you mentioned, the provided scope would serve it well
Maven offers a similar approach, where it has a predefined set of dependency
scopes, but it is not flexible, one can't define new scopes like with Ivy
On Sun, Oct 17, 2010 at 11:43 PM, Neil Bartlett <[email protected]>wrote:
> In Bndtools[1] I am using the OBR resolver from Felix (in a slightly
> modified form) to resolve build-time repositories and run
> configurations. I have come across a problem that perhaps somebody has
> seen before and can provide advice about.
>
> Suppose I have a run configuration that uses Felix as its framework,
> but the user has selected the DS implementation from Equinox. I
> therefore have the following three resources as inputs to the OBR
> resolver:
>
> org.apache.felix.framework
> org.eclipse.equinox.ds
> org.eclipse.equinox.util
>
> The Equinox bundles have dependencies on packages that are usually
> supplied by the core Equinox framework when running on Equinox... but
> there is a bundle "org.eclipse.equinox.supplement" that can provide
> those packages in scenarios such as the above.
>
> Unfortunately, the resolver picks "org.eclipse.osgi" to satisy the
> dependency, meaning I would end up with the full Equinox framework,
> running as a bundle inside Felix. This is undesirable.
>
> I feel that a clean solution for this problem would be some kind of
> "unique" capability. I do not want two OSGi Framework instances...
> perhaps both Felix and Equinox could provide a capability (e.g.
> "osgiframework") that was defined as unique, i.e. the resolver would
> allow only one resource providing that capability. This would force
> the resolver to pick org.eclipse.equinox.supplement, since Felix is
> already selected.
>
> Another desirable feature would be to constrain certain bundles
> according to a profile. For example, in the above scenario the
> resolver offers "osgi.core" (i.e. the OSGi core APIs) as an optional
> resource. But osgi.core is special: I always want to use it at build
> time -- in preference to either org.apache.felix.framework or
> org.eclipse.osgi -- but I NEVER want to include it at runtime.
>
> Any suggestions before I start to hack the above solution?
>
> Regards,
> Neil
>
> [1] http://njbartlett.name/bndtools.html
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
Kind Regards
Mohamed Ragab
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
