>
> I have to admit, this starts looking very nasty. For a starter you might
> just do something like this:
>
> <Import-Package>*;resolution:=optional</Import-Package>
Well, that's one thing out of 1000 I've already tried. It deploys without
grumbling but as soon as I use
org.apache.abdera.parser.stax.util.PrettyWriter, I get an error:
"javax.xml.stream.FactoryConfigurationError: Requested factory
com.ctc.wstx.stax.WstxOutputFactory cannot be located. Classloader
[EMAIL PROTECTED] Launchpad Web Application"
On this path, I also gave a try to something like this:
<Import-Package>
javax.jcr.*,
javax.servlet.*;version=2.4,
javax.xml.*,
org.apache.sling.api.*,
org.xml.sax.*,
javax.el,
org.apache.sling.jcr.ocm.*,
org.apache.sling.scripting.jsp.jasper.runtime.*,
org.apache.sling.scripting.jsp.taglib.*,
org.slf4j,
*;resolution:=optional
</Import-Package>
The errors in the console were the same as shown in a previous mail.
> This causes the bnd tool to mark each and every import as optional. This
> should at least get you a starter.
>
>
>
>> On a general note, I have serious doubts about this approach of OSGi. I
>> mean, we are talking here only about using a single library! I wonder how
>> cumbersome really complicate things get?
>>
>
> The problem is not OSGi by itself. Or as another developer stated: "I
> always thought I would develop modular libraries until I started doing OSGi
> bundles".
>
> The problem really are legacy libraries providing support/bindings for tons
> of other libraries. Mixing and matching these things is a horrible and
> sometimes timeconsuming task. Because not all bindings are always needed.
>
> So in your use case I would start like that:
>
> (1) Embed the Abdera libraries plus commons-code in a bundle
> (2) Create the bundle
> (3) Dump the headers of the bundle by just feeding the
> bundle to the bnd tool:
> $ java -jar bnd.jar my.bundle.jar
> (4) Look at the import statements and decide what to do:
> -> accept some (mostly stuff available from sling)
> -> decide required ones: add to the embed list and start
> over at step (2)
> -> decide unneeded ones (probably com.sun.* ?): mark as
> optional and start over at step (2)
>
>
> Marking a dependency optional comes in two ways: (1) You may set the
> resolution optional by declaring the resolution:=optional directive in the
> Import-Package element/header or (2) you may list the package (wildcards
> allowed) in the DynamicImport-Package element header.
>
> For example to dynamically resolve any com.sun package you could say:
>
> <DynamicImport-Package>com.sun.*</DynamicImport-Package>
I appreciate your explanation and I will go that way even though I have gone
through a similar process before. What bothers me most is the fact that I
don't know what is going on. Guessing has in my opinion nothing to do with
engineering. If it was something super high techy, I could accept it but
hey, we are talking about using one single library!
