One other issue that I think we need to follow up on, how should the
plugin handle transitive dependencies of the bundle's dependencies?
I see three options:
1. Ignore them and require the bundle developer to list them as
explicit dependencies if they want to embed them.
2. Embed all transitive dependencies of any embedded bundle dependency.
3. Use the matching rules from <embed-dependency> to determine if any
of the transitive dependencies should also be embedded.
Personally, I think (3) makes the most sense and is the most flexible;
this approach assumes that we can get groupId/artifactId/version/scope
of transitive dependencies.
Thoughts?
-> richard
Richard S. Hall wrote:
Hello,
Back in early December we had a discussion with Emil Eifrém, Aaron
Siri, et al about how the new bundle plugin should deal with embedding
(as opposed to inlining) dependent JAR files. Peter and I have finally
had some time to discuss this and have come up with a simple proposal
that we can now submit for some feedback.
The general approach is a slightly modified version of Peter's first
proposal. The idea is to add a mechanism to deal with embedding JARs
that is very similar to how the old maven plugin worked, but doing it
in a slightly more generic way than the old plugin by adding the
following instruction:
embed-dependency ::= clause ( ',' clause ) *
clause ::= MATCH ( ';' attr '=' MATCH )
attr ::= 'groupId' | 'artifactId' | 'version' |
'scope'
MATCH ::= <globbed regular expressions>
This instruction would be used to match the specified Maven
dependencies for embedding. Any matching dependency would have its JAR
file embedded onto the resulting bundle JAR file and it would be
appended to the Bundle-ClassPath header after ".".
This would allow people to easily achieve the same behavior as the old
plugin by simply doing:
<embed-dependency>*;scope=compile,*;scope=runtime</embed-dependency>
Thus, this instruction would automatically embed any maven
dependencies that were of scope "compile" or "runtime" and append them
to the bundle class path.
What do you think?
-> richard
