Hi,
On Thu, 2006-09-07 at 08:28 +0200, Felix Meschberger wrote:
> On 9/7/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> > It essentially mean that we can't leverage the <scope> for determining
> > whether
> > it should be inserted into the Bundle or expected to come from elsewhere.
>
> As far as I understand, using the scope is probably best in most
> cases. Especially for Bundle-only projects. On the other hand, John's
> use case makes sense.
My initial effort to migrate a library project to OSGi was along the
same lines that we, on the Felix list, have often spoke about -
encouraging other project teams to bundlize their artifacts.
Niclas described the idea to a new user of Felix in an email on this
list today:
For so called Library Bundles that we just want legacy classes
to be served from, need to be OSGified. Jason van Zyl has
queried about making this a standard process in Maven2, to give
us a huge hand in this process.
IMHO if there any technical drawbacks to creating OSGi library bundles
(added to the ever present psychological resistance to change) our
efforts to migrate legacy projects to OSGi will almost surely fail.
Breaking the transitive dependency feature of Maven2 with our OSGi
plugin is just such a technical problem. I think we need to fix it.
> I could rather imagine a configuration setting like <inlinedArtifact>,
> which allows to explicitly prevent inclusion of certain dependencies.
Within an OSGi project the dependency child element <scope> seems to be
too overloaded with significance. Today it means:
1. a dependency is/isn't a transitive dependency
2. a dependency inclusion/exclusion on particular maven build task
classpaths
3. a dependency inclusion/exclusion in the created bundle
Isn't that too much to ask for the <scope> element to do?
> Another issue, I have, is that transitive dependencies of a
> compile/runtime dependency also get included in the bundle, which of
> course is fine most of the time. But not always. Example: I need
> "commons-configuration" included but not the complete big list of
> dependencies like "dom4j" etc. I solve this problem by using
> dependency <exclusions>. While this works, it may be errorprone since
> this may change from release to release. Yet it seems to me to be the
> only practicable way to go.
>
If we:
+ left <scope> to do the first and second functions above (just like
standard maven projects expect it to do)
+ added a <inlinedArtifact> element to the dependency element to
indicate dependencies that are to be added to the bundle
+ allow <inlinedArtifact> to have child <exclusions> elements to
exclude transitives from our bundle.
Would this overcome the problem and meet requirements?
WDYT?
John
