Well, the manifest is fine. You never told the plugin to include the
commons, so that is another story. :-)
EE> 1. Detect as many problems as possible at compile-time. This means
EE> we're not too thrilled about the resolution:=optional solution.
EE> Runtime exceptions is not good enough.
You can't have your cake and it too ... In that case you must ensure
ALL your dependencies are met. Fine with me, its the model I use.
However, it means you will have to know exactly what you link to.
EE> 2. The POM is the definitive resource for information about a
EE> project's configuration. All other configuration resources (Eclipse
EE> files, OSGi manifests) should be generated from it.
Great, so skip the PDE and use the JDE, saves a lot of pain. The JDE
does NOT use the manifest.mf file.
EE> 3. Never ever add a feature (to the build infrastructure) if it
EE> means we have to update the same information in more than one place
EE> for frequent changes. (Everything more often than "once per month" is
EE> frequent.)
You're a man to my heart, though once a year would have put you in
even higher standing :-)
EE> So in our case the POM knows everything about the project. This means
EE> that ALL dependencies for our source files are listed in the POM. And
EE> this means that the plugin should be able to just do the Right
EE> Thing(tm), which in our view is to take dependencies with
EE> <type>bundle</type>, analyze them and generate Import-Package
EE> statements for them; and take dependencies with <type>jar</type>, add
EE> them to Bundle-Classpath and embed them in the bundle.
I now see you want to include all your dependencies into one big jar,
which of course in the OSGi component model is far from ideal :-(
I guess what you are looking for is a possibility to specify the
artifacts that should be placed on the bundle classpath? I am not sure
I can just take all the <scope>provided</scope> artifacts because I am sure
there are people who want to make finer grained components.
Would inline the jars work for you? It is more efficient on the
framework than including the jar and specifying the Bundle-Classpath
header. You can inline with Include-Resource but this means you need
to specify the dependencies twice and it requires knowing the Maven
path names, both are very unpleasant.
So we could add the artifacts that should be inlined without
redundantly specifying the dependents. Proposal:
include-maven ::= clause ( ',' clause ) *
clause ::= MATCH ( ';' attr '=' MATCH )
attr ::= 'version' | 'scope'
MATCH ::= <globbed regular expressions>
Defaults for attributes = '*', matching all.
I could use this header to find out all specified dependent artifacts
and add their paths to the Include-Resource header as inlined
artifacts.
In your case you would add for example:
<include-maven>*;scope=provided</include-maven>
Assuming bnd and commons were your dependencies then this would be
translated to something like:
<Include-Resource>
@/home/pkriens/.m2/biz/aQute/bnd-0.0.105/bnd-0.0.105.jar,
@/home/pkriens/.m2/apache/commons/commons-2.2.33/commons-02.2.33.jar
</Include-Resource>
Do I understand you correctly now and would this work?
Kind regards,
Peter Kriens
EE> This should solve our problems. I realize this is not for all. Some
EE> people don't have all information in the POM, others have all jar
EE> files as bundles. But the above functionality combined with the
EE> behavior for <scope>provided</scope> seems to cover all bases.
EE> Hi Peter. Thanks for your reply.
EE> On 12/4/06, Peter Kriens <[EMAIL PROTECTED]> wrote:
>> The manifest looks fine, there seems to be no bundle exporting the
>> org.apache.commons.logging package.
EE> Actually, in our case it's more like:
EE> "The manifest DOESN'T look fine, because there is no bundle
EE> exporting the org.apache.commons.logging package."
EE> [snip]
>> If you have suggestions for
>> improving the plugin/bnd then please let me know.
>>
EE> Yes, we do lack a feature that would make our lives easier.
EE> First off, we have a few simple principles for our build environment.
EE> In fact, we have a bunch but here's the gist as relevant for this
EE> discussion:
EE> 1. Detect as many problems as possible at compile-time. This means
EE> we're not too thrilled about the resolution:=optional solution.
EE> Runtime exceptions is not good enough.
EE> 2. The POM is the definitive resource for information about a
EE> project's configuration. All other configuration resources (Eclipse
EE> files, OSGi manifests) should be generated from it.
EE> 3. Never ever add a feature (to the build infrastructure) if it
EE> means we have to update the same information in more than one place
EE> for frequent changes. (Everything more often than "once per month" is
EE> frequent.)
EE> So in our case the POM knows everything about the project. This means
EE> that ALL dependencies for our source files are listed in the POM. And
EE> this means that the plugin should be able to just do the Right
EE> Thing(tm), which in our view is to take dependencies with
EE> <type>bundle</type>, analyze them and generate Import-Package
EE> statements for them; and take dependencies with <type>jar</type>, add
EE> them to Bundle-Classpath and embed them in the bundle.
EE> This should solve our problems. I realize this is not for all. Some
EE> people don't have all information in the POM, others have all jar
EE> files as bundles. But the above functionality combined with the
EE> behavior for <scope>provided</scope> seems to cover all bases.
EE> Am I missing something?
EE> Cheers,
EE> -EE
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
