Alan D. Cabrera wrote:
On Jan 25, 2007, at 12:35 PM, 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?
I like that finer degree of control that this gives but think that we
should stick to using XML elements. I think that it's bad form to
mix-in OSGi manifest like patterns in a Maven POM, especially when
those patterns govern the behavior of a Maven plugin.
Do you have a proposal? I think it would be quite ugly/verbose to break
such syntax out into XML elements.
I am not sure I understand why there is a constraint on the form of XML
used by a plugin. It is almost as if you are saying that BND's syntax
isn't Maven-like enough.
This is a plugin for creating OSGi bundles, so it seems to make sense
for it to be comfortable for OSGi developers. Don't you think?
-> richard
