I am not a maven expert so maybe there are better ways to do it.
I never understood "provided" to mean include? If that is the
definition I can automatically include them. Can someone point me to
the relevant literature?
The <type>bundle</type> is required by maven as far as I know, as is
the messy plugin setup. If you know a better way let me know.
The plugin inlines the folders in the same way as the inlined jars (or
should) so there should be technically no difference between inlined
jars and Bundle-Classpath. In both cases, order is relevant if you
have overlapping packages.
Inlining or Bundle-Classpath both make no difference for the
Import-Package. The import header is calculated from the
references from all the classes on the Bundle-Classpath.
So if we support a <include-maven> instruction, should it with copied
jars or or inlined? I understand you want Bundle-Classpath, anybody
else in this group thoughts?
Kind regards,
Peter Kriens
EE> On 12/5/06, Peter Kriens <[EMAIL PROTECTED]> wrote:
>> 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> Yup, we're already using the JDE. Or rather, we're NOT using the PDE.
EE> Another principle is to keep the build infrastructure IDE agnostic. So
EE> we can't rely on the PDE. Some of our developers use IDEA or Netbeans
EE> or, well, at times, emacs.
EE> [snip]
>> 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 :-(
EE> Yes. We've settled on a model with few, course-grained bundles. I
EE> would have loved to go to the other extreme and have a bunch of small,
EE> decoupled, independently developed bundles to assemble my apps from --
EE> but our feeling is that the toolchain around OSGi (and Java) is not
EE> mature enough to support that yet. (At least for us it isn't, but our
EE> requirements around our development environment might be sharper than
EE> most.) A component concept that stretches across both runtime and
EE> compile-time and a bundles commons will be a good start, though.
>>
>> I guess what you are looking for is a possibility to specify the
>> artifacts that should be placed on the bundle classpath?
EE> Yes, this is exactly it. Placed on the bundle classpath and embedded
EE> in the bundle. Specified *at most* once per dependency in the POM. (I
EE> actually think it's possible to have the plugin do the Right Thing(tm)
EE> without any extra specification whatsoever in the POM. It kinda irks
EE> me that I have to declare my dependencies as <type>bundle</type> when
EE> obviously there's a way for the tool to figure that out without any
EE> manual labor on my part.)
>> 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.
EE> I was under the impression that <scope>provided</scope> meant just
EE> that, provided. As in, "don't worry about it, it'll be provided by the
EE> Powers That Be before the app is run." We use it only for the OSGi
EE> framework. The dependencies that we want to embed have
EE> <type>jar</type> and the dependencies that we want to generate
EE> Import-Package declarations for have <type>bundle</type>.
>>
>> Would inline the jars work for you? It is more efficient on the
>> framework than including the jar and specifying the Bundle-Classpath
>> header.
EE> I don't really know, I trust you a lot more than me when it comes to
EE> judging tradeoffs between embedding and inlining in OSGi -- but
EE> doesn't embedding and setting Bundle-Classpath seem to be the cleaner
EE> solution? I like the fact that the resulting bundle is "neat": you can
EE> look inside it with jar tvf and it makes sense. When you look into a
EE> bundle generated with inlined jars it's a big mess. You can not get a
EE> sense of what's supporting libraries and what's the actual component
EE> implementation. Also, I realize this is a corner case, but let's say
EE> that we have two jars with the same package... won't we have a
EE> non-deterministic dependency resolution (basically dependant on which
EE> jar file happens to be extracted first)?
EE> Oh, and I don't really care about framework performance. I can't
EE> imagine it's more than a very minor hit on bootstrap and maybe on
EE> first use of the classes. Anyway, in our case we're talking about a
EE> server-side application so minor overhead while we're warming up is
EE> not a big deal for us. Might be different in other settings, of
EE> course, but then there's always the inline option.
>> 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.
EE> They are indeed!
>>
>> 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.
EE> [snip]
>> Do I understand you correctly now and would this work?
EE> Yes, you do understand me correctly. Your proposal is a good start! However:
EE> 1) I would prefer embedding the jars to inlining them. See above.
EE> 2) You would also need to use the declaration in <include-maven> to
EE> modify the auto-generated Import-Package statement. If a package is
EE> provided by one of the jars matched by <include-maven> then that
EE> package should be removed from Import-Package.
EE> Thanks a lot for your time!
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
