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