Peter Kriens wrote:
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?
From the docs is says:
*provided* - this is much like compile, but indicates you expect the
JDK or a container to provide it. It is only available on the
compilation classpath, and is not transitive.
So, my interpretation is "provided" does NOT mean to include it, but
that it is external to the bundle and is provided by the "container" to
the bundle, which in our case means the bundle must import it...and this
is how we used the term in the old plugin...
-> richard
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
