You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.biz> on 2006/12/05 15:49:29 UTC
Re[4]: Bundle plugin: Importing packages from non-bundles
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 <Pe...@aqute.biz> 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
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> On Tue, 2006-12-05 at 18:32 +0100, Peter Kriens wrote:
>
>> Hmmm. I think you mean to say that the <include-maven> instruction
>> would make you happy because then you have a choice?
>>
> YES
>
>> So we only have to decide if the JAR is copied or inlined?
>>
> Did we determine if there is a performance hit with the copied versus
> the inlined?
>
There is a performance hit at installation time, since the embedded JAR
files need to be extracted. This also implies extra consumption of disk
space. Otherwise, there should be no additional run-time overhead, I
don't think...except for needing more open files.
-> richard
> cheers,
> John
>
>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> JEC> On Tue, 2006-12-05 at 15:49 +0100, 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?
>>>>
>> JEC> Provided means that the jar is provided or available (somehow - like
>> JEC> another bundle in the felix framework) at runtime.
>>
>> JEC> Although the maven doc says:
>> JEC> "provided - this is much like compile, but indicates you expect the JDK
>> JEC> or a container to provide it. It is only available on the compilation
>> JEC> classpath, and is not transitive."
>>
>> JEC> <tangent not-the-main-point-I-want-to-make="but just thought of it">
>> JEC> Now this can't be right, if you think about it anything scoped as
>> JEC> provided would have to be available on maven's compilation, AND test AND
>> JEC> run classpaths as well. (How else could you test your project?)
>> JEC> </tangent>
>>
>> JEC> The Problem I really wanted to point out ---->
>> JEC> When using the old OSGi plugin it was necessary to ALWAYS specify the
>> JEC> scope 'provided' for any dependency, (let's call it depx that were/are
>> JEC> bundles themselves and would be 'provided' at runtime) to prevent them
>> JEC> from being embedded into the bundle (bundleA) along with their 'compile'
>> JEC> scoped siblings.
>>
>> JEC> Unfortunately there is a side effect to using the scope element to
>> JEC> determine the embedding of jars into the bundle.
>>
>> JEC> With provided, Maven no longer tags the artifact (depx) as transitive to
>> JEC> bundleA, and thus other maven projects that now use the newly
>> JEC> built/artifact bundleA as a dependency have lost transitive 'sight' of
>> JEC> that depx. Oops!
>>
>> JEC> So is it possible to allow compile and provided scoped dependencies to
>> JEC> be included or not included in the bundle? If so we can offer the
>> JEC> community an OSGi bundling plugin without sacrificing maven's transitive
>> JEC> dependency functionality.
>>
>>
>> JEC> cheers,
>> JEC> John
>>
>>
>>
>
>
Re: Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-12-05 at 18:32 +0100, Peter Kriens wrote:
> Hmmm. I think you mean to say that the <include-maven> instruction
> would make you happy because then you have a choice?
YES
>
> So we only have to decide if the JAR is copied or inlined?
Did we determine if there is a performance hit with the copied versus
the inlined?
cheers,
John
>
> Kind regards,
>
> Peter Kriens
>
>
>
> JEC> On Tue, 2006-12-05 at 15:49 +0100, 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?
> JEC> Provided means that the jar is provided or available (somehow - like
> JEC> another bundle in the felix framework) at runtime.
>
> JEC> Although the maven doc says:
> JEC> "provided - this is much like compile, but indicates you expect the JDK
> JEC> or a container to provide it. It is only available on the compilation
> JEC> classpath, and is not transitive."
>
> JEC> <tangent not-the-main-point-I-want-to-make="but just thought of it">
> JEC> Now this can't be right, if you think about it anything scoped as
> JEC> provided would have to be available on maven's compilation, AND test AND
> JEC> run classpaths as well. (How else could you test your project?)
> JEC> </tangent>
>
> JEC> The Problem I really wanted to point out ---->
> JEC> When using the old OSGi plugin it was necessary to ALWAYS specify the
> JEC> scope 'provided' for any dependency, (let's call it depx that were/are
> JEC> bundles themselves and would be 'provided' at runtime) to prevent them
> JEC> from being embedded into the bundle (bundleA) along with their 'compile'
> JEC> scoped siblings.
>
> JEC> Unfortunately there is a side effect to using the scope element to
> JEC> determine the embedding of jars into the bundle.
>
> JEC> With provided, Maven no longer tags the artifact (depx) as transitive to
> JEC> bundleA, and thus other maven projects that now use the newly
> JEC> built/artifact bundleA as a dependency have lost transitive 'sight' of
> JEC> that depx. Oops!
>
> JEC> So is it possible to allow compile and provided scoped dependencies to
> JEC> be included or not included in the bundle? If so we can offer the
> JEC> community an OSGi bundling plugin without sacrificing maven's transitive
> JEC> dependency functionality.
>
>
> JEC> cheers,
> JEC> John
>
>
Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by Peter Kriens <Pe...@aQute.biz>.
Hmmm. I think you mean to say that the <include-maven> instruction
would make you happy because then you have a choice?
So we only have to decide if the JAR is copied or inlined?
Kind regards,
Peter Kriens
JEC> On Tue, 2006-12-05 at 15:49 +0100, 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?
JEC> Provided means that the jar is provided or available (somehow - like
JEC> another bundle in the felix framework) at runtime.
JEC> Although the maven doc says:
JEC> "provided - this is much like compile, but indicates you expect the JDK
JEC> or a container to provide it. It is only available on the compilation
JEC> classpath, and is not transitive."
JEC> <tangent not-the-main-point-I-want-to-make="but just thought of it">
JEC> Now this can't be right, if you think about it anything scoped as
JEC> provided would have to be available on maven's compilation, AND test AND
JEC> run classpaths as well. (How else could you test your project?)
JEC> </tangent>
JEC> The Problem I really wanted to point out ---->
JEC> When using the old OSGi plugin it was necessary to ALWAYS specify the
JEC> scope 'provided' for any dependency, (let's call it depx that were/are
JEC> bundles themselves and would be 'provided' at runtime) to prevent them
JEC> from being embedded into the bundle (bundleA) along with their 'compile'
JEC> scoped siblings.
JEC> Unfortunately there is a side effect to using the scope element to
JEC> determine the embedding of jars into the bundle.
JEC> With provided, Maven no longer tags the artifact (depx) as transitive to
JEC> bundleA, and thus other maven projects that now use the newly
JEC> built/artifact bundleA as a dependency have lost transitive 'sight' of
JEC> that depx. Oops!
JEC> So is it possible to allow compile and provided scoped dependencies to
JEC> be included or not included in the bundle? If so we can offer the
JEC> community an OSGi bundling plugin without sacrificing maven's transitive
JEC> dependency functionality.
JEC> cheers,
JEC> John
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Re[4]: Bundle plugin: Importing packages from non-bundles
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-12-05 at 15:49 +0100, 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?
Provided means that the jar is provided or available (somehow - like
another bundle in the felix framework) at runtime.
Although the maven doc 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."
<tangent not-the-main-point-I-want-to-make="but just thought of it">
Now this can't be right, if you think about it anything scoped as
provided would have to be available on maven's compilation, AND test AND
run classpaths as well. (How else could you test your project?)
</tangent>
The Problem I really wanted to point out ---->
When using the old OSGi plugin it was necessary to ALWAYS specify the
scope 'provided' for any dependency, (let's call it depx that were/are
bundles themselves and would be 'provided' at runtime) to prevent them
from being embedded into the bundle (bundleA) along with their 'compile'
scoped siblings.
Unfortunately there is a side effect to using the scope element to
determine the embedding of jars into the bundle.
With provided, Maven no longer tags the artifact (depx) as transitive to
bundleA, and thus other maven projects that now use the newly
built/artifact bundleA as a dependency have lost transitive 'sight' of
that depx. Oops!
So is it possible to allow compile and provided scoped dependencies to
be included or not included in the bundle? If so we can offer the
community an OSGi bundling plugin without sacrificing maven's transitive
dependency functionality.
cheers,
John
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <Pe...@aqute.biz> 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
>
>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Steven E. Harris" <se...@panix.com>.
Peter Kriens <Pe...@aQute.biz> writes:
> Using "provide" as the instruction to include the jar does seem
> rather ad hoc looking at the semantics. I would actually assume the
> opposite at first reading and treat it as a bundle that will be
> installed in the runtime env.
That's "provided", as in "this resource is provided elsewhere or by
someone else". It specifically means /not/ to include the JAR, as it
will be provided later by other means.
--
Steven E. Harris
Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by Peter Kriens <Pe...@aQute.biz>.
Using "provide" as the instruction to include the jar does seem rather
ad hoc looking at the semantics. I would actually assume the opposite
at first reading and treat it as a bundle that will be installed in
the runtime env.
Kind regards,
Peter Kriens
EE> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
EE> Neither am I, but it actually means exclude. From
EE> http://maven.apache.org/pom.html:
--- >>8 ---
EE> * scope: This element refers to the classpath of the task at hand
EE> (compiling and runtime, testing, etc.) as well as how to limit the
EE> transitivity of a depedency. There are five scopes available:
EE> * compile - this is the default scope, used if none is specified.
EE> Compile dependencies are available in all classpaths.
EE> * provided - this is much like compile, but indicates you expect
EE> the JDK or a container to provide it. It is only available on the
EE> compilation classpath, and is not transitive.
EE> * runtime - this scope indicates that the dependency is not
EE> required for compilation, but is for execution. It is in the runtime
EE> and test classpaths, but not the compile classpath.
EE> * test - this scope indicates that the dependency is not required
EE> for normal use of the application, and is only available for the test
EE> compilation and execution phases.
EE> * system - this scope is similar to provided except that you have
EE> to provide the JAR which contains it explicitly. The artifact is
EE> always available and is not looked up in a repository.
--- >>8 ---
>>
>>
>> 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.
EE> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
EE> I just want stuff to work so I can build apps. :) But this is an
EE> Apache list, I'm sure others can chime in!
EE> What I meant in my previous mail was that I don't understand why the
EE> plugin needs to know the <type> of the dependencies. It's an
EE> OSGi-aware plugin... just have a peek in the jar file and figure it
EE> out? If it is, then generate Import-Package, if not then embed or
EE> inline it. Would work nicely. But maybe there's some Maven core <->
EE> Maven plugin interaction going on there that I'm missing. In either
EE> case, this would be nice-to-have functionality but it's not a
EE> showstopper for us.
EE> [snip]
>> 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.
EE> Here's where I don't get it. Let's go back to the simple original
EE> example with my one-class bundle which depended on commons-logging. If
EE> the plugin would embed or inline the commons-logging jar AND generate
EE> Import-Package statements... that would break when we load it into the
EE> OSGi framework, right? No other bundle will export commons-logging
EE> stuff and, moreover, even if there is I want my bundle to use the
EE> embedded stuff like I said in my POM. This is the core of the issue,
EE> as I see it.
EE> Cheers,
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
Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by Peter Kriens <Pe...@aQute.biz>.
I think it is:
<configuration>
<instructions>
AS> I was going to start asking similar questions. I'm wondering how I get my
AS> dependencies packaged in the bundle (I prefer them as jars and not inlined.)
AS> Does this thread imply that there is no way for library jars to be packaged
AS> in the bundle using maven-bundle-plugin?
AS> I'm also trying to get the plugin.xml file included into the bundle via:
AS> <configuration>
AS> <Include-Resource>plugin.xml</Include-Resource>
AS> </configuration>
AS> Which doesn't seem to be working. Is this the right way to get it included?
AS> -Aaron
AS> -----Original Message-----
AS> From: Emil Eifrém [mailto:emil@eifrem.com]
AS> Sent: Tuesday, December 05, 2006 10:10 AM
AS> To: Peter Kriens
AS> Cc: felix-dev@incubator.apache.org
AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from non-bundles
AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
AS> Neither am I, but it actually means exclude. From
AS> http://maven.apache.org/pom.html:
--- >>8 ---
AS> * scope: This element refers to the classpath of the task at hand (compiling
AS> and runtime, testing, etc.) as well as how to limit the transitivity of a
AS> depedency. There are five scopes available:
AS> * compile - this is the default scope, used if none is specified.
AS> Compile dependencies are available in all classpaths.
AS> * provided - this is much like compile, but indicates you expect the JDK
AS> or a container to provide it. It is only available on the compilation
AS> classpath, and is not transitive.
AS> * runtime - this scope indicates that the dependency is not required for
AS> compilation, but is for execution. It is in the runtime and test classpaths,
AS> but not the compile classpath.
AS> * test - this scope indicates that the dependency is not required for
AS> normal use of the application, and is only available for the test compilation
AS> and execution phases.
AS> * system - this scope is similar to provided except that you have to
AS> provide the JAR which contains it explicitly. The artifact is always
AS> available and is not looked up in a repository.
--- >>8 ---
>>
>>
>> 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.
AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
AS> I just want stuff to work so I can build apps. :) But this is an Apache list,
AS> I'm sure others can chime in!
AS> What I meant in my previous mail was that I don't understand why the plugin
AS> needs to know the <type> of the dependencies. It's an OSGi-aware plugin...
AS> just have a peek in the jar file and figure it out? If it is, then generate
AS> Import-Package, if not then embed or inline it. Would work nicely. But maybe
AS> there's some Maven core <-> Maven plugin interaction going on there that I'm
AS> missing. In either case, this would be nice-to-have functionality but it's
AS> not a showstopper for us.
AS> [snip]
>> 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.
AS> Here's where I don't get it. Let's go back to the simple original example
AS> with my one-class bundle which depended on commons-logging. If the plugin
AS> would embed or inline the commons-logging jar AND generate Import-Package
AS> statements... that would break when we load it into the OSGi framework,
AS> right? No other bundle will export commons-logging stuff and, moreover, even
AS> if there is I want my bundle to use the embedded stuff like I said in my POM.
AS> This is the core of the issue, as I see it.
AS> Cheers,
AS> -EE
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Re[2]: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/7/06, Peter Kriens <Pe...@aqute.biz> wrote:
> It is not ambiguous because if an Import-Package can not be matched
> the bundle can not be resolved. You can make an imported package
> optional, in that case it will resolve but the import is ignored at
> resolve time (it will not be wired) and the internal packages will be
> used according to the description.
>
> So the premise that you can resolve with an unmatched import is not
> right. The description you quote assumes the bundle is resolved
> otherwise no classes are loaded from it.
Makes perfect sense. Thanks.
-EE
Re[2]: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]
Posted by Peter Kriens <Pe...@aQute.biz>.
It is not ambiguous because if an Import-Package can not be matched
the bundle can not be resolved. You can make an imported package
optional, in that case it will resolve but the import is ignored at
resolve time (it will not be wired) and the internal packages will be
used according to the description.
So the premise that you can resolve with an unmatched import is not
right. The description you quote assumes the bundle is resolved
otherwise no classes are loaded from it.
Kind regards,
Peter Kriens
EE> On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> Well, AFAIU, it seems legal to have Import-Package of classes that are
>> available internal to the bundle (see 3.8.4), and still have it resolved even
>> if there is no Export-Package in the system.
EE> I read it over last night and came to the conclusion that it
EE> terminates in step 3:
EE> "If the class or resource is in a package that is imported using Import-
EE> Package or was imported dynamically in a previous load, then the
EE> request is delegated to the exporting bundle's class loader; otherwise the
EE> search continues with the next step." (3.8.4, step 3)
EE> I re-read it with fresh(er) eyes and now I think it's ambiguous. It
EE> doesn't explicitly say how to handle Import-Packages that can't be
EE> matched to Export-Packages (I read the "otherwise" clause to be
EE> attached to "if Import-Package" not to "if found(Export-Package)").
EE> I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
EE> the bundle with a BundleException because of missing or unresolved
EE> packages). It seems like the reasonable thing to do since it avoids
EE> your indeterministic scenario. Furthermore, it seems more analogous
EE> with (my understanding of) embedded or inlined jars: "Framework, from
EE> this point of view I'm an autonomous bundle. Don't you worry about
EE> these particular dependencies."
EE> Cheers,
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
Re: Re-wire Case [was; Re; Bundle plugin: Importing packages from
non-bundles]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Emil Eifrém wrote:
> On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> Well, AFAIU, it seems legal to have Import-Package of classes that are
>> available internal to the bundle (see 3.8.4), and still have it
>> resolved even
>> if there is no Export-Package in the system.
>
> I read it over last night and came to the conclusion that it
> terminates in step 3:
>
> "If the class or resource is in a package that is imported using Import-
> Package or was imported dynamically in a previous load, then the
> request is delegated to the exporting bundle's class loader; otherwise
> the
> search continues with the next step." (3.8.4, step 3)
>
> I re-read it with fresh(er) eyes and now I think it's ambiguous. It
> doesn't explicitly say how to handle Import-Packages that can't be
> matched to Export-Packages (I read the "otherwise" clause to be
> attached to "if Import-Package" not to "if found(Export-Package)").
If an import cannot be matched to an export then the bundle doesn't
resolve and you cannot load classes from it (nor activate it) no matter
what.
If the import is optional, then the import will be ignored by the
resolver forever if not found at resolve time. Then the bundle can get
an internal version of the package if present.
If the import is dynamic, then the import will be ignored until the
bundle tries to load it at run time. At which point the framework will
try to resolve the import. If the bundle has an internal version of the
package, then the dynamic import will never happen because the internal
package will always be found first.
> I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
> the bundle with a BundleException because of missing or unresolved
> packages). It seems like the reasonable thing to do since it avoids
> your indeterministic scenario. Furthermore, it seems more analogous
> with (my understanding of) embedded or inlined jars: "Framework, from
> this point of view I'm an autonomous bundle. Don't you worry about
> these particular dependencies."
This is exactly how Felix should behave too...let me know if you
discover otherwise.
-> richard
>
> Cheers,
>
> -EE
Re: Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> Well, AFAIU, it seems legal to have Import-Package of classes that are
> available internal to the bundle (see 3.8.4), and still have it resolved even
> if there is no Export-Package in the system.
I read it over last night and came to the conclusion that it
terminates in step 3:
"If the class or resource is in a package that is imported using Import-
Package or was imported dynamically in a previous load, then the
request is delegated to the exporting bundle's class loader; otherwise the
search continues with the next step." (3.8.4, step 3)
I re-read it with fresh(er) eyes and now I think it's ambiguous. It
doesn't explicitly say how to handle Import-Packages that can't be
matched to Export-Packages (I read the "otherwise" clause to be
attached to "if Import-Package" not to "if found(Export-Package)").
I ran a test on Knopflerfish (sorry) and they terminate in 3 (rejects
the bundle with a BundleException because of missing or unresolved
packages). It seems like the reasonable thing to do since it avoids
your indeterministic scenario. Furthermore, it seems more analogous
with (my understanding of) embedded or inlined jars: "Framework, from
this point of view I'm an autonomous bundle. Don't you worry about
these particular dependencies."
Cheers,
-EE
Re-wire Case [was; Re; Bundle plugin: Importing packages from non-bundles]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 03:24, Richard S. Hall wrote:
> Emil Eifrém wrote:
> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
> > framework matched my bundle's Import-Packages to other bundles
> > Export-Packages. In this case, I don't want the framework to find a
> > bundle that provides the package since the package is provided by the
> > (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
> > thought the plugin shouldn't add the package to the Import-Package
> > statement.
> >
> > Is this an incorrect understanding of how OSGi works?
Well, AFAIU, it seems legal to have Import-Package of classes that are
available internal to the bundle (see 3.8.4), and still have it resolved even
if there is no Export-Package in the system.
That makes little sense to me, but more importantly I think it opens up a bit
of indeterministic behaviour;
1. Bundle A loads and refers to class C in package P, which is found
internally in the system. It has Import-Package: P but no Export-Package.
2. Bundle B loads and has Export-Package: P
Bundle A must now be stopped and re-wired to Bundle B's export. Otherwise, if
a third bundle imports P and gets hold of C (e.g. via a service) a
ClassCastException will occur. But if 2. preceeds 1. in time, then no problem
will occur. Right?
So, does Felix re-wire all Import-Package when a Export-Package appears in the
system, i.e. even running bundles?
Cheers
Niclas
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/7/06, Richard S. Hall <he...@ungoverned.org> wrote:
> When Peter gets back from traveling, he and I will try to discuss some
> approaches to dealing with this issue and we will post a proposal to the
> list for discussion. Sound reasonable?
Sounds excellent. We are as well eagerly awaiting the proposal.
Cheers,
-EE
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/6/06, Richard S. Hall <he...@ungoverned.org> wrote:
> Steven E. Harris wrote:
> > But weren't we just talking about this policy a few days ago?¹ Richard
> > commented that such behavior is intentional and beneficial.
> >
>
> I think that is a different issue, but at this point, I am uncertain. :-)
That link is discussing package interoperability and substitutability.
That's a different issue from what we're discussing in this thread,
IMHO, since when you've already commited to using a plain jar for a
specific dependency and chosen to embed it into the bundle (like we
propose), then you've already chosen to give up on that nice OSGi
pluggability[1].
Cheers,
-EE
1] So yes, Richard and Peter: I do realize that what I and Aaron
propose is in many ways contrary to the vision of OSGi. I'm with you
on that one. It sucks to hard couple bundles to a certain
implementation of a dependency, which is the end result of our
embedding scheme. But I don't think it's counter-productive towards
fulfilling the vision. While we're waiting for a world of properly
designed bundles rather than arbitrarily designed jars, we must have a
way to efficiently and incrementally migrate towards that vision.
That's why I, today, would like to be able to embed jar files in my
bundles and that's why I, today, prefer Require-Bundle to
Import-Package when I assemble my internal products. But hopefully I
won't for too long.
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alan D. Cabrera wrote:
>
> On Dec 7, 2006, at 6:15 PM, Niclas Hedhman wrote:
>
>> Why not get your hands dirty and create your own plugin?
>>
>> Or, help Jason van Zyl to make the Jar plugin OSGi friendly. He also
>> is fairly
>> clueless of what is needed and best practices, so he should be easy to
>> influence in your direction.
>>
>> Or, use the old plugin if you find that one better. I didn't like
>> that one
>> either, but instead making fuzz over it I forked it and made my own
>> changes
>> that I felt would help me. (see
>> https://scm.ops4j.org/repos/ops4j/projects/pax/maven/osgi-bundle )
>> I am sure there are others out there.
>
> Interesting. I have just started reading this list in earnest and
> hand always thought that there was one plugin effort. What other
> plugins are there in all?
As far as I know, there are three:
* The original plugin started by Enrique and then later greatly
hacked by Peter Kriens, which is a Felix subproject.
* Niclas' fork of the above plugin.
* A new plugin based on Peter's BND tool that was committed a few
weeks back; originally this was going to be an enhancement to the
first plugin, but because it was so different we forked it in
Felix and have two plugin subprojects at this point...although we
hope to get back down to one.
The documentation for both Felix plugins can be found here:
http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html
http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
-> richard
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 7, 2006, at 6:15 PM, Niclas Hedhman wrote:
> Why not get your hands dirty and create your own plugin?
>
> Or, help Jason van Zyl to make the Jar plugin OSGi friendly. He
> also is fairly
> clueless of what is needed and best practices, so he should be easy to
> influence in your direction.
>
> Or, use the old plugin if you find that one better. I didn't like
> that one
> either, but instead making fuzz over it I forked it and made my own
> changes
> that I felt would help me. (see
> https://scm.ops4j.org/repos/ops4j/projects/pax/maven/osgi-bundle )
> I am sure there are others out there.
Interesting. I have just started reading this list in earnest and
hand always thought that there was one plugin effort. What other
plugins are there in all?
Regards,
Alan
Re: Bundle plugin: Importing packages from non-bundles
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 08 December 2006 03:07, Aaron Siri wrote:
> I get the
> impression here that some people think that maven is a form of voodoo and
> you never know what it is doing or that it can't be trusted. I always know
> exactly what is going to be pulled and know when I should short-circuit the
> dependency tree.
> Why should *you* dictate what *I* can and can't trust?
(because you and I don't know better ;o) )
How many POMs are "correct" (from an OSGi point of view) in the OSS landscape,
do you think?
How many are "correct" from any point of view?
Examples; Jars needed during testing only (ant, junit et al). Jars that are
provided by the "host" (servlet, jta, jca)
IMHO, there should be no magic bundle plugin at all. A reporting utility so I
can construct the manifest and bundle correctly is the first thing, and a
validator that somehow warns me when I have made changes to the references
and the Manifest may need an update, would be cool.
Why not get your hands dirty and create your own plugin?
Or, help Jason van Zyl to make the Jar plugin OSGi friendly. He also is fairly
clueless of what is needed and best practices, so he should be easy to
influence in your direction.
Or, use the old plugin if you find that one better. I didn't like that one
either, but instead making fuzz over it I forked it and made my own changes
that I felt would help me. (see
https://scm.ops4j.org/repos/ops4j/projects/pax/maven/osgi-bundle )
I am sure there are others out there.
Cheers
Niclas
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> Very reasonable. Part of this is me making sure I'm not assuming anything
> fundamentally wrong. Some of the discussion seems to be of the "yes we could
> do it that way but why?" nature and I wanted to convince myself that what is
> being asked for/suggested isn't unreasonable.
>
I don't think there is anything fundamentally wrong, just different
perspectives. Some people come from a Maven-like world and want to apply
those concepts to OSGi. Others come from an OSGi world and want to apply
those concepts to Maven. We can try to bridge those gaps.
-> richard
> I anxiously await the proposal. :)
>
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, December 07, 2006 2:17 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> I also care about what is being packaged in my bundle and via the pom
>> *I'm* making all my decisions - they aren't ad-hoc. If I select an
>> api/library to use I usually accept it as a whole and don't start
>> micromanaging it or pull it apart (unless it starts to break, then all
>> bets are off.) I get the impression here that some people think that
>> maven is a form of voodoo and you never know what it is doing or that
>> it can't be trusted. I always know exactly what is going to be pulled
>> and know when I should short-circuit the dependency tree. Why should
>> *you* dictate what *I* can and can't trust? We are all professional coders
>>
> here and can make our own decisions.
>
>>
>>
>
> I think the issue here is that Peter is not coming from a Maven perspective,
> since he doesn't use Maven.
>
>
>> If you want to flatten and optimize the bundle then that is your
>> prerogative, but can't that be a separate step? Right now the plugin
>> doesn't even give you an option, it forces one way of doing things.
>> We're just asking for more options. The auto Import/Export stuff is
>> attractive which is why we don't really want to abandon
>> maven-bundle-plugin. We just wish it let us choose how jar
>> dependencies are handled - either inline the classes and treat them as
>> your own code (what the plugin does now), or bundle them as is and add
>> them to Bundle-ClassPath (what some of us prefer.) In both cases isn't the
>>
> bundle's integrity maintained via Export-Package?
>
>>
>>
>
> As I stated a few times before, I think it is possible to come up with a
> solution, but we need the time to think about it and discuss it.
>
> When Peter gets back from traveling, he and I will try to discuss some
> approaches to dealing with this issue and we will post a proposal to the list
> for discussion. Sound reasonable?
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>> Sent: Thursday, December 07, 2006 10:24 AM
>> To: Henrik Larsson
>> Cc: felix-dev@incubator.apache.org
>> Subject: Re[2]: Bundle plugin: Importing packages from non-bundles
>>
>> For me the difference between a bundle and a jar is arbitrary. I
>> always try to make my bundles work as jars.
>>
>> I really think that the "simple" rules posted are too ad hoc and will
>> generate lots of problems. In my experience, the contents of your
>> bundle need to be designed and not some more or less arbitrary
>> collection of jars and packages, mostly decided by other people than
>> me. If code gets into MY bundle, I feel responsible and want to know
>> exactly what the consequences are. Leaving this up to chance and other
>> people's ad hoc decisions seems a tad to dangerous for me.
>>
>> The plugin/bnd was designed to carve the bundle out of the classpath
>> and then analyze it so you can inspect the consequences.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> HL> I'm a co-worker with Emil, so we share the same view on this (I
>> HL> hope ;)
>> ).
>>
>> HL> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>>
>>
>>>> After our discussion I decided to go back and give the old plugin a
>>>> try. It is definitely buggy. It seems to randomly add packages to
>>>> Import-Package no matter where they come from (plain old jars or
>>>> bundles.) Maybe it is just me but I can't make any sense in what it
>>>> is
>>>>
>>>>
>> doing.
>>
>>
>>>> I think Emil (correct me if I'm wrong) and I would both like to see
>>>> only packages from bundle dependencies added to Import-Package, not
>>>> stuff from embedded plain old jars (which should instead be added to
>>>> the classpath.) The new plugin's behavior for this is nice, as long
>>>> as it only looks at bundle dependencies and not jar dependencies. I
>>>> think Emil is then saying that if both a bundle and a plain old jar
>>>> provide a package then don't put it on Import-Package (i.e. let it
>>>> resolve to the plain old jar via the
>>>> classpath.) The embedded plain old jars should override bundles
>>>> (maybe OSGi spec already dictates this.)
>>>>
>>>>
>>>>
>> HL> Yes, this is exactly the kind of behavior we are looking for.
>>
>> HL> It would be nice if everything could be bundles, but as that is
>> HL> not the case we want to be able to embed plain old jars in our
>> HL> bundles (preferably not inlined, but that's not a major point).
>> HL> Then Import-Package should *only* contain packages that are
>> HL> exported by other bundles, not packages used from plain old jars
>> HL> that are in the Bundle-Classpath.
>>
>>
>>
>>>> The Bundle-Classpath entry from the old plugin looks good though.
>>>>
>>>> So, is anybody invited to work on the plugins?
>>>>
>>>> -Aaron
>>>>
>>>> P.S. I want to thank Richard and Peter for putting up with all of my
>>>> questions/complaints. I'm learning a lot in this newsgroup.
>>>>
>>>>
>> HL> Yes, thanks Richard and Peter. We very much appreciate your prompt
>> HL> and elaborate replies.
>>
>>
>>
>>
>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Wednesday, December 06, 2006 2:25 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>>
>>>> Emil Eifrém wrote:
>>>>
>>>>
>>>>> On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>>>>>
>>>>>
>>>>>> How can it NOT generate Import-Package for bundles that are on the
>>>>>> Bundle-Classpath?
>>>>>>
>>>>>>
>>>>> Maybe this is a typo, but maybe it's important. I'm not going to
>>>>> have any *bundles* on the Bundle-Classpath, I'm going to have plain
>>>>>
>>>>>
>> jars.
>>
>>
>>>>> (See my commons-logging example.) Does this make a difference?
>>>>>
>>>>>
>>>>>
>>>>>> This means you have unresolved dependencies in your code, which
>>>>>> can give you very nasty problems during deployment and running the
>>>>>>
>>>>>>
>> code.
>>
>>
>>>>>> That is like putting out class files that have compile errors.
>>>>>>
>>>>>>
>>>>> Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>>>>> framework matched my bundle's Import-Packages to other bundles
>>>>> Export-Packages. In this case, I don't want the framework to find a
>>>>> bundle that provides the package since the package is provided by
>>>>> the (plain, non-bundle) embedded jar on the Bundle-Classpath.
>>>>> That's why I thought the plugin shouldn't add the package to the
>>>>> Import-Package statement.
>>>>>
>>>>> Is this an incorrect understanding of how OSGi works?
>>>>>
>>>>>
>>>> Your understanding of OSGi is correct.
>>>>
>>>> I think there is a misunderstanding about what you are describing.
>>>>
>>>> You are saying that you don't want imports generated for the same
>>>> packages contained inside of embedded JAR files on your bundle class
>>>> path, correct? I think Peter thought you meant that you didn't want
>>>> to generate imports for the packages required by the packages in
>>>> your embedded JAR files. You want the latter, but not the
>>>> former...you indicate that the former is probably a bug in the old
>>>>
> plugin. Correct?
>
>>>> -> richard
>>>>
>>>>
>>>>
>>
>>
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
Very reasonable. Part of this is me making sure I'm not assuming anything
fundamentally wrong. Some of the discussion seems to be of the "yes we could
do it that way but why?" nature and I wanted to convince myself that what is
being asked for/suggested isn't unreasonable.
I anxiously await the proposal. :)
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Thursday, December 07, 2006 2:17 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
> I also care about what is being packaged in my bundle and via the pom
> *I'm* making all my decisions - they aren't ad-hoc. If I select an
> api/library to use I usually accept it as a whole and don't start
> micromanaging it or pull it apart (unless it starts to break, then all
> bets are off.) I get the impression here that some people think that
> maven is a form of voodoo and you never know what it is doing or that
> it can't be trusted. I always know exactly what is going to be pulled
> and know when I should short-circuit the dependency tree. Why should
> *you* dictate what *I* can and can't trust? We are all professional coders
here and can make our own decisions.
>
I think the issue here is that Peter is not coming from a Maven perspective,
since he doesn't use Maven.
> If you want to flatten and optimize the bundle then that is your
> prerogative, but can't that be a separate step? Right now the plugin
> doesn't even give you an option, it forces one way of doing things.
> We're just asking for more options. The auto Import/Export stuff is
> attractive which is why we don't really want to abandon
> maven-bundle-plugin. We just wish it let us choose how jar
> dependencies are handled - either inline the classes and treat them as
> your own code (what the plugin does now), or bundle them as is and add
> them to Bundle-ClassPath (what some of us prefer.) In both cases isn't the
bundle's integrity maintained via Export-Package?
>
As I stated a few times before, I think it is possible to come up with a
solution, but we need the time to think about it and discuss it.
When Peter gets back from traveling, he and I will try to discuss some
approaches to dealing with this issue and we will post a proposal to the list
for discussion. Sound reasonable?
-> richard
> -Aaron
>
> -----Original Message-----
> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
> Sent: Thursday, December 07, 2006 10:24 AM
> To: Henrik Larsson
> Cc: felix-dev@incubator.apache.org
> Subject: Re[2]: Bundle plugin: Importing packages from non-bundles
>
> For me the difference between a bundle and a jar is arbitrary. I
> always try to make my bundles work as jars.
>
> I really think that the "simple" rules posted are too ad hoc and will
> generate lots of problems. In my experience, the contents of your
> bundle need to be designed and not some more or less arbitrary
> collection of jars and packages, mostly decided by other people than
> me. If code gets into MY bundle, I feel responsible and want to know
> exactly what the consequences are. Leaving this up to chance and other
> people's ad hoc decisions seems a tad to dangerous for me.
>
> The plugin/bnd was designed to carve the bundle out of the classpath
> and then analyze it so you can inspect the consequences.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> HL> I'm a co-worker with Emil, so we share the same view on this (I
> HL> hope ;)
> ).
>
> HL> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>
>>> After our discussion I decided to go back and give the old plugin a
>>> try. It is definitely buggy. It seems to randomly add packages to
>>> Import-Package no matter where they come from (plain old jars or
>>> bundles.) Maybe it is just me but I can't make any sense in what it
>>> is
>>>
> doing.
>
>>> I think Emil (correct me if I'm wrong) and I would both like to see
>>> only packages from bundle dependencies added to Import-Package, not
>>> stuff from embedded plain old jars (which should instead be added to
>>> the classpath.) The new plugin's behavior for this is nice, as long
>>> as it only looks at bundle dependencies and not jar dependencies. I
>>> think Emil is then saying that if both a bundle and a plain old jar
>>> provide a package then don't put it on Import-Package (i.e. let it
>>> resolve to the plain old jar via the
>>> classpath.) The embedded plain old jars should override bundles
>>> (maybe OSGi spec already dictates this.)
>>>
>>>
>
>
> HL> Yes, this is exactly the kind of behavior we are looking for.
>
> HL> It would be nice if everything could be bundles, but as that is
> HL> not the case we want to be able to embed plain old jars in our
> HL> bundles (preferably not inlined, but that's not a major point).
> HL> Then Import-Package should *only* contain packages that are
> HL> exported by other bundles, not packages used from plain old jars
> HL> that are in the Bundle-Classpath.
>
>
>>> The Bundle-Classpath entry from the old plugin looks good though.
>>>
>>> So, is anybody invited to work on the plugins?
>>>
>>> -Aaron
>>>
>>> P.S. I want to thank Richard and Peter for putting up with all of my
>>> questions/complaints. I'm learning a lot in this newsgroup.
>>>
>
>
> HL> Yes, thanks Richard and Peter. We very much appreciate your prompt
> HL> and elaborate replies.
>
>
>
>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Wednesday, December 06, 2006 2:25 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>>
>>> Emil Eifrém wrote:
>>>
>>>> On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>>>>
>>>>> How can it NOT generate Import-Package for bundles that are on the
>>>>> Bundle-Classpath?
>>>>>
>>>> Maybe this is a typo, but maybe it's important. I'm not going to
>>>> have any *bundles* on the Bundle-Classpath, I'm going to have plain
>>>>
> jars.
>
>>>> (See my commons-logging example.) Does this make a difference?
>>>>
>>>>
>>>>> This means you have unresolved dependencies in your code, which
>>>>> can give you very nasty problems during deployment and running the
>>>>>
> code.
>
>>>>> That is like putting out class files that have compile errors.
>>>>>
>>>> Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>>>> framework matched my bundle's Import-Packages to other bundles
>>>> Export-Packages. In this case, I don't want the framework to find a
>>>> bundle that provides the package since the package is provided by
>>>> the (plain, non-bundle) embedded jar on the Bundle-Classpath.
>>>> That's why I thought the plugin shouldn't add the package to the
>>>> Import-Package statement.
>>>>
>>>> Is this an incorrect understanding of how OSGi works?
>>>>
>>> Your understanding of OSGi is correct.
>>>
>>> I think there is a misunderstanding about what you are describing.
>>>
>>> You are saying that you don't want imports generated for the same
>>> packages contained inside of embedded JAR files on your bundle class
>>> path, correct? I think Peter thought you meant that you didn't want
>>> to generate imports for the packages required by the packages in
>>> your embedded JAR files. You want the latter, but not the
>>> former...you indicate that the former is probably a bug in the old
plugin. Correct?
>>>
>>> -> richard
>>>
>>>
>
>
>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> I also care about what is being packaged in my bundle and via the pom *I'm*
> making all my decisions - they aren't ad-hoc. If I select an api/library to
> use I usually accept it as a whole and don't start micromanaging it or pull
> it apart (unless it starts to break, then all bets are off.) I get the
> impression here that some people think that maven is a form of voodoo and you
> never know what it is doing or that it can't be trusted. I always know
> exactly what is going to be pulled and know when I should short-circuit the
> dependency tree. Why should *you* dictate what *I* can and can't trust? We
> are all professional coders here and can make our own decisions.
>
I think the issue here is that Peter is not coming from a Maven
perspective, since he doesn't use Maven.
> If you want to flatten and optimize the bundle then that is your prerogative,
> but can't that be a separate step? Right now the plugin doesn't even give
> you an option, it forces one way of doing things. We're just asking for more
> options. The auto Import/Export stuff is attractive which is why we don't
> really want to abandon maven-bundle-plugin. We just wish it let us choose
> how jar dependencies are handled - either inline the classes and treat them
> as your own code (what the plugin does now), or bundle them as is and add
> them to Bundle-ClassPath (what some of us prefer.) In both cases isn't the
> bundle's integrity maintained via Export-Package?
>
As I stated a few times before, I think it is possible to come up with a
solution, but we need the time to think about it and discuss it.
When Peter gets back from traveling, he and I will try to discuss some
approaches to dealing with this issue and we will post a proposal to the
list for discussion. Sound reasonable?
-> richard
> -Aaron
>
> -----Original Message-----
> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
> Sent: Thursday, December 07, 2006 10:24 AM
> To: Henrik Larsson
> Cc: felix-dev@incubator.apache.org
> Subject: Re[2]: Bundle plugin: Importing packages from non-bundles
>
> For me the difference between a bundle and a jar is arbitrary. I always try
> to make my bundles work as jars.
>
> I really think that the "simple" rules posted are too ad hoc and will
> generate lots of problems. In my experience, the contents of your bundle need
> to be designed and not some more or less arbitrary collection of jars and
> packages, mostly decided by other people than me. If code gets into MY
> bundle, I feel responsible and want to know exactly what the consequences
> are. Leaving this up to chance and other people's ad hoc decisions seems a
> tad to dangerous for me.
>
> The plugin/bnd was designed to carve the bundle out of the classpath and then
> analyze it so you can inspect the consequences.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> HL> I'm a co-worker with Emil, so we share the same view on this (I hope ;)
> ).
>
> HL> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>
>>> After our discussion I decided to go back and give the old plugin a
>>> try. It is definitely buggy. It seems to randomly add packages to
>>> Import-Package no matter where they come from (plain old jars or
>>> bundles.) Maybe it is just me but I can't make any sense in what it is
>>>
> doing.
>
>>> I think Emil (correct me if I'm wrong) and I would both like to see
>>> only packages from bundle dependencies added to Import-Package, not
>>> stuff from embedded plain old jars (which should instead be added to
>>> the classpath.) The new plugin's behavior for this is nice, as long
>>> as it only looks at bundle dependencies and not jar dependencies. I
>>> think Emil is then saying that if both a bundle and a plain old jar
>>> provide a package then don't put it on Import-Package (i.e. let it
>>> resolve to the plain old jar via the
>>> classpath.) The embedded plain old jars should override bundles
>>> (maybe OSGi spec already dictates this.)
>>>
>>>
>
>
> HL> Yes, this is exactly the kind of behavior we are looking for.
>
> HL> It would be nice if everything could be bundles, but as that is not
> HL> the case we want to be able to embed plain old jars in our bundles
> HL> (preferably not inlined, but that's not a major point). Then
> HL> Import-Package should *only* contain packages that are exported by
> HL> other bundles, not packages used from plain old jars that are in the
> HL> Bundle-Classpath.
>
>
>>> The Bundle-Classpath entry from the old plugin looks good though.
>>>
>>> So, is anybody invited to work on the plugins?
>>>
>>> -Aaron
>>>
>>> P.S. I want to thank Richard and Peter for putting up with all of my
>>> questions/complaints. I'm learning a lot in this newsgroup.
>>>
>
>
> HL> Yes, thanks Richard and Peter. We very much appreciate your prompt
> HL> and elaborate replies.
>
>
>
>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Wednesday, December 06, 2006 2:25 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>>
>>> Emil Eifrém wrote:
>>>
>>>> On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>>>>
>>>>> How can it NOT generate Import-Package for bundles that are on the
>>>>> Bundle-Classpath?
>>>>>
>>>> Maybe this is a typo, but maybe it's important. I'm not going to
>>>> have any *bundles* on the Bundle-Classpath, I'm going to have plain
>>>>
> jars.
>
>>>> (See my commons-logging example.) Does this make a difference?
>>>>
>>>>
>>>>> This means you have unresolved dependencies in your code, which
>>>>> can give you very nasty problems during deployment and running the
>>>>>
> code.
>
>>>>> That is like putting out class files that have compile errors.
>>>>>
>>>> Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>>>> framework matched my bundle's Import-Packages to other bundles
>>>> Export-Packages. In this case, I don't want the framework to find a
>>>> bundle that provides the package since the package is provided by
>>>> the (plain, non-bundle) embedded jar on the Bundle-Classpath.
>>>> That's why I thought the plugin shouldn't add the package to the
>>>> Import-Package statement.
>>>>
>>>> Is this an incorrect understanding of how OSGi works?
>>>>
>>> Your understanding of OSGi is correct.
>>>
>>> I think there is a misunderstanding about what you are describing.
>>>
>>> You are saying that you don't want imports generated for the same
>>> packages contained inside of embedded JAR files on your bundle class
>>> path, correct? I think Peter thought you meant that you didn't want
>>> to generate imports for the packages required by the packages in your
>>> embedded JAR files. You want the latter, but not the former...you
>>> indicate that the former is probably a bug in the old plugin. Correct?
>>>
>>> -> richard
>>>
>>>
>
>
>
RE: Re[2]: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
I also care about what is being packaged in my bundle and via the pom *I'm*
making all my decisions - they aren't ad-hoc. If I select an api/library to
use I usually accept it as a whole and don't start micromanaging it or pull
it apart (unless it starts to break, then all bets are off.) I get the
impression here that some people think that maven is a form of voodoo and you
never know what it is doing or that it can't be trusted. I always know
exactly what is going to be pulled and know when I should short-circuit the
dependency tree. Why should *you* dictate what *I* can and can't trust? We
are all professional coders here and can make our own decisions.
If you want to flatten and optimize the bundle then that is your prerogative,
but can't that be a separate step? Right now the plugin doesn't even give
you an option, it forces one way of doing things. We're just asking for more
options. The auto Import/Export stuff is attractive which is why we don't
really want to abandon maven-bundle-plugin. We just wish it let us choose
how jar dependencies are handled - either inline the classes and treat them
as your own code (what the plugin does now), or bundle them as is and add
them to Bundle-ClassPath (what some of us prefer.) In both cases isn't the
bundle's integrity maintained via Export-Package?
-Aaron
-----Original Message-----
From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
Sent: Thursday, December 07, 2006 10:24 AM
To: Henrik Larsson
Cc: felix-dev@incubator.apache.org
Subject: Re[2]: Bundle plugin: Importing packages from non-bundles
For me the difference between a bundle and a jar is arbitrary. I always try
to make my bundles work as jars.
I really think that the "simple" rules posted are too ad hoc and will
generate lots of problems. In my experience, the contents of your bundle need
to be designed and not some more or less arbitrary collection of jars and
packages, mostly decided by other people than me. If code gets into MY
bundle, I feel responsible and want to know exactly what the consequences
are. Leaving this up to chance and other people's ad hoc decisions seems a
tad to dangerous for me.
The plugin/bnd was designed to carve the bundle out of the classpath and then
analyze it so you can inspect the consequences.
Kind regards,
Peter Kriens
HL> I'm a co-worker with Emil, so we share the same view on this (I hope ;)
).
HL> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>> After our discussion I decided to go back and give the old plugin a
>> try. It is definitely buggy. It seems to randomly add packages to
>> Import-Package no matter where they come from (plain old jars or
>> bundles.) Maybe it is just me but I can't make any sense in what it is
doing.
>>
>> I think Emil (correct me if I'm wrong) and I would both like to see
>> only packages from bundle dependencies added to Import-Package, not
>> stuff from embedded plain old jars (which should instead be added to
>> the classpath.) The new plugin's behavior for this is nice, as long
>> as it only looks at bundle dependencies and not jar dependencies. I
>> think Emil is then saying that if both a bundle and a plain old jar
>> provide a package then don't put it on Import-Package (i.e. let it
>> resolve to the plain old jar via the
>> classpath.) The embedded plain old jars should override bundles
>> (maybe OSGi spec already dictates this.)
>>
HL> Yes, this is exactly the kind of behavior we are looking for.
HL> It would be nice if everything could be bundles, but as that is not
HL> the case we want to be able to embed plain old jars in our bundles
HL> (preferably not inlined, but that's not a major point). Then
HL> Import-Package should *only* contain packages that are exported by
HL> other bundles, not packages used from plain old jars that are in the
HL> Bundle-Classpath.
>> The Bundle-Classpath entry from the old plugin looks good though.
>>
>> So, is anybody invited to work on the plugins?
>>
>> -Aaron
>>
>> P.S. I want to thank Richard and Peter for putting up with all of my
>> questions/complaints. I'm learning a lot in this newsgroup.
HL> Yes, thanks Richard and Peter. We very much appreciate your prompt
HL> and elaborate replies.
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Wednesday, December 06, 2006 2:25 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>>
>> Emil Eifrém wrote:
>> > On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>> >> How can it NOT generate Import-Package for bundles that are on the
>> >> Bundle-Classpath?
>> >
>> > Maybe this is a typo, but maybe it's important. I'm not going to
>> > have any *bundles* on the Bundle-Classpath, I'm going to have plain
jars.
>> > (See my commons-logging example.) Does this make a difference?
>> >
>> >> This means you have unresolved dependencies in your code, which
>> >> can give you very nasty problems during deployment and running the
code.
>> >> That is like putting out class files that have compile errors.
>> >
>> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>> > framework matched my bundle's Import-Packages to other bundles
>> > Export-Packages. In this case, I don't want the framework to find a
>> > bundle that provides the package since the package is provided by
>> > the (plain, non-bundle) embedded jar on the Bundle-Classpath.
>> > That's why I thought the plugin shouldn't add the package to the
>> > Import-Package statement.
>> >
>> > Is this an incorrect understanding of how OSGi works?
>> Your understanding of OSGi is correct.
>>
>> I think there is a misunderstanding about what you are describing.
>>
>> You are saying that you don't want imports generated for the same
>> packages contained inside of embedded JAR files on your bundle class
>> path, correct? I think Peter thought you meant that you didn't want
>> to generate imports for the packages required by the packages in your
>> embedded JAR files. You want the latter, but not the former...you
>> indicate that the former is probably a bug in the old plugin. Correct?
>>
>> -> richard
>>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re[2]: Bundle plugin: Importing packages from non-bundles
Posted by Peter Kriens <Pe...@aQute.biz>.
For me the difference between a bundle and a jar is arbitrary. I
always try to make my bundles work as jars.
I really think that the "simple" rules posted are too ad hoc and will
generate lots of problems. In my experience, the contents of your
bundle need to be designed and not some more or less arbitrary
collection of jars and packages, mostly decided by other people than
me. If code gets into MY bundle, I feel responsible and want to know
exactly what the consequences are. Leaving this up to chance and other
people's ad hoc decisions seems a tad to dangerous for me.
The plugin/bnd was designed to carve the bundle out of the classpath and then
analyze it so you can inspect the consequences.
Kind regards,
Peter Kriens
HL> I'm a co-worker with Emil, so we share the same view on this (I hope ;) ).
HL> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>> After our discussion I decided to go back and give the old plugin a try. It
>> is definitely buggy. It seems to randomly add packages to Import-Package no
>> matter where they come from (plain old jars or bundles.) Maybe it is just me
>> but I can't make any sense in what it is doing.
>>
>> I think Emil (correct me if I'm wrong) and I would both like to see only
>> packages from bundle dependencies added to Import-Package, not stuff from
>> embedded plain old jars (which should instead be added to the classpath.)
>> The new plugin's behavior for this is nice, as long as it only looks at
>> bundle dependencies and not jar dependencies. I think Emil is then saying
>> that if both a bundle and a plain old jar provide a package then don't put it
>> on Import-Package (i.e. let it resolve to the plain old jar via the
>> classpath.) The embedded plain old jars should override bundles (maybe OSGi
>> spec already dictates this.)
>>
HL> Yes, this is exactly the kind of behavior we are looking for.
HL> It would be nice if everything could be bundles, but as that is not
HL> the case we want to be able to embed plain old jars in our bundles
HL> (preferably not inlined, but that's not a major point). Then
HL> Import-Package should *only* contain packages that are exported by
HL> other bundles, not packages used from plain old jars that are in the
HL> Bundle-Classpath.
>> The Bundle-Classpath entry from the old plugin looks good though.
>>
>> So, is anybody invited to work on the plugins?
>>
>> -Aaron
>>
>> P.S. I want to thank Richard and Peter for putting up with all of my
>> questions/complaints. I'm learning a lot in this newsgroup.
HL> Yes, thanks Richard and Peter. We very much appreciate your prompt and
HL> elaborate replies.
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Wednesday, December 06, 2006 2:25 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>>
>> Emil Eifrém wrote:
>> > On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>> >> How can it NOT generate Import-Package for bundles that are on the
>> >> Bundle-Classpath?
>> >
>> > Maybe this is a typo, but maybe it's important. I'm not going to have
>> > any *bundles* on the Bundle-Classpath, I'm going to have plain jars.
>> > (See my commons-logging example.) Does this make a difference?
>> >
>> >> This means you have unresolved dependencies in your code, which can
>> >> give you very nasty problems during deployment and running the code.
>> >> That is like putting out class files that have compile errors.
>> >
>> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>> > framework matched my bundle's Import-Packages to other bundles
>> > Export-Packages. In this case, I don't want the framework to find a
>> > bundle that provides the package since the package is provided by the
>> > (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
>> > thought the plugin shouldn't add the package to the Import-Package
>> > statement.
>> >
>> > Is this an incorrect understanding of how OSGi works?
>> Your understanding of OSGi is correct.
>>
>> I think there is a misunderstanding about what you are describing.
>>
>> You are saying that you don't want imports generated for the same packages
>> contained inside of embedded JAR files on your bundle class path, correct? I
>> think Peter thought you meant that you didn't want to generate imports for
>> the packages required by the packages in your embedded JAR files. You want
>> the latter, but not the former...you indicate that the former is probably a
>> bug in the old plugin. Correct?
>>
>> -> richard
>>
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/7/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thursday 07 December 2006 09:43, Emil Eifrém wrote:
> > All dependencies are not treated equal. If dependency is a bundle then
> > generate Import-Package. If dependency is a jar then embed and
> > generate Bundle-Classpath.
>
> This is an interesting hack. :o)
Will it work?
>
> You are more or less equalling the 'class transport mechanism in Maven'
> with 'class resolution mechanism in OSGi'.
Of course I am. Except I have no idea of what you just said. :)
>
> The more I read this thread the more convinced I am getting that Maven ain't
> the savior ;o)
I'm sure it isn't. The other night, Peter (the Neubauer kind, not the
Kriens kind) spent half an hour telling me how Maven will never
*really* work for OSGi, while I sipped my wine, pretended to listen
and quietly thought about all the cool applications I'm going to build
on top of OSGi once we've added this small feature to Maven. ;)
Maybe Maven isn't the ultimate solution, and maybe it's not perfect
for OSGi. But with some tweaks it seems good enough for now.
Cheers,
-EE
Re: Bundle plugin: Importing packages from non-bundles
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 09:43, Emil Eifrém wrote:
> All dependencies are not treated equal. If dependency is a bundle then
> generate Import-Package. If dependency is a jar then embed and
> generate Bundle-Classpath.
This is an interesting hack. :o)
You are more or less equalling the 'class transport mechanism in Maven'
with 'class resolution mechanism in OSGi'.
The more I read this thread the more convinced I am getting that Maven ain't
the savior ;o)
Cheers
Niclas
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/6/06, Richard S. Hall <he...@ungoverned.org> wrote:
> It seems like I am getting mixed messages.
>
> For further clarification, do you want the dependencies of embedded JAR
> files to be ignored or do you want the transitive closure of those
> dependencies embedded inside of the generated bundle and put on the
> bundle class path?
All dependencies are not treated equal. If dependency is a bundle then
generate Import-Package. If dependency is a jar then embed and
generate Bundle-Classpath.
-EE
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
In maven-land the transitive closure would be embedded but you can control
how deep to walk the dependency tree.
Example:
<dependency>
<groupId>jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.0</version>
</dependency>
Would put both jdom.jar and xml-apis.jar (a jdom dependency) on the classpath
and in the bundle.
However:
<dependency>
<groupId>jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
</exclusions>
</dependency>
Would not put xml-apis.jar (nor any of its dependencies) on the classpath or
in the bundle.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Wednesday, December 06, 2006 4:55 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
It seems like I am getting mixed messages.
For further clarification, do you want the dependencies of embedded JAR files
to be ignored or do you want the transitive closure of those dependencies
embedded inside of the generated bundle and put on the bundle class path?
-> richard
Henrik Larsson wrote:
> I'm a co-worker with Emil, so we share the same view on this (I hope
> ;) ).
>
> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>> After our discussion I decided to go back and give the old plugin a
>> try. It is definitely buggy. It seems to randomly add packages to
>> Import-Package no matter where they come from (plain old jars or
>> bundles.) Maybe it is just me but I can't make any sense in what it
>> is doing.
>>
>> I think Emil (correct me if I'm wrong) and I would both like to see
>> only packages from bundle dependencies added to Import-Package, not
>> stuff from embedded plain old jars (which should instead be added to
>> the
>> classpath.)
>> The new plugin's behavior for this is nice, as long as it only looks
>> at bundle dependencies and not jar dependencies. I think Emil is
>> then saying that if both a bundle and a plain old jar provide a
>> package then don't put it on Import-Package (i.e. let it resolve to
>> the plain old jar via the
>> classpath.) The embedded plain old jars should override bundles
>> (maybe OSGi spec already dictates this.)
>>
>
>
> Yes, this is exactly the kind of behavior we are looking for.
>
> It would be nice if everything could be bundles, but as that is not
> the case we want to be able to embed plain old jars in our bundles
> (preferably not inlined, but that's not a major point). Then
> Import-Package should *only* contain packages that are exported by
> other bundles, not packages used from plain old jars that are in the
> Bundle-Classpath.
>
>> The Bundle-Classpath entry from the old plugin looks good though.
>>
>> So, is anybody invited to work on the plugins?
>>
>> -Aaron
>>
>> P.S. I want to thank Richard and Peter for putting up with all of my
>> questions/complaints. I'm learning a lot in this newsgroup.
>
>
> Yes, thanks Richard and Peter. We very much appreciate your prompt and
> elaborate replies.
>
>
>
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Wednesday, December 06, 2006 2:25 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>>
>> Emil Eifrém wrote:
>> > On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>> >> How can it NOT generate Import-Package for bundles that are on the
>> >> Bundle-Classpath?
>> >
>> > Maybe this is a typo, but maybe it's important. I'm not going to
>> > have any *bundles* on the Bundle-Classpath, I'm going to have plain
jars.
>> > (See my commons-logging example.) Does this make a difference?
>> >
>> >> This means you have unresolved dependencies in your code, which
>> >> can give you very nasty problems during deployment and running the
code.
>> >> That is like putting out class files that have compile errors.
>> >
>> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>> > framework matched my bundle's Import-Packages to other bundles
>> > Export-Packages. In this case, I don't want the framework to find a
>> > bundle that provides the package since the package is provided by
>> > the (plain, non-bundle) embedded jar on the Bundle-Classpath.
>> > That's why I thought the plugin shouldn't add the package to the
>> > Import-Package statement.
>> >
>> > Is this an incorrect understanding of how OSGi works?
>> Your understanding of OSGi is correct.
>>
>> I think there is a misunderstanding about what you are describing.
>>
>> You are saying that you don't want imports generated for the same
>> packages contained inside of embedded JAR files on your bundle class
>> path, correct? I think Peter thought you meant that you didn't want
>> to generate imports for the packages required by the packages in your
>> embedded JAR files. You want the latter, but not the former...you
>> indicate that the former is probably a bug in the old plugin.
>> Correct?
>>
>> -> richard
>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
It seems like I am getting mixed messages.
For further clarification, do you want the dependencies of embedded JAR
files to be ignored or do you want the transitive closure of those
dependencies embedded inside of the generated bundle and put on the
bundle class path?
-> richard
Henrik Larsson wrote:
> I'm a co-worker with Emil, so we share the same view on this (I hope
> ;) ).
>
> On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
>> After our discussion I decided to go back and give the old plugin a
>> try. It
>> is definitely buggy. It seems to randomly add packages to
>> Import-Package no
>> matter where they come from (plain old jars or bundles.) Maybe it is
>> just me
>> but I can't make any sense in what it is doing.
>>
>> I think Emil (correct me if I'm wrong) and I would both like to see only
>> packages from bundle dependencies added to Import-Package, not stuff
>> from
>> embedded plain old jars (which should instead be added to the
>> classpath.)
>> The new plugin's behavior for this is nice, as long as it only looks at
>> bundle dependencies and not jar dependencies. I think Emil is then
>> saying
>> that if both a bundle and a plain old jar provide a package then
>> don't put it
>> on Import-Package (i.e. let it resolve to the plain old jar via the
>> classpath.) The embedded plain old jars should override bundles
>> (maybe OSGi
>> spec already dictates this.)
>>
>
>
> Yes, this is exactly the kind of behavior we are looking for.
>
> It would be nice if everything could be bundles, but as that is not
> the case we want to be able to embed plain old jars in our bundles
> (preferably not inlined, but that's not a major point). Then
> Import-Package should *only* contain packages that are exported by
> other bundles, not packages used from plain old jars that are in the
> Bundle-Classpath.
>
>> The Bundle-Classpath entry from the old plugin looks good though.
>>
>> So, is anybody invited to work on the plugins?
>>
>> -Aaron
>>
>> P.S. I want to thank Richard and Peter for putting up with all of my
>> questions/complaints. I'm learning a lot in this newsgroup.
>
>
> Yes, thanks Richard and Peter. We very much appreciate your prompt and
> elaborate replies.
>
>
>
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Wednesday, December 06, 2006 2:25 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>>
>> Emil Eifrém wrote:
>> > On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>> >> How can it NOT generate Import-Package for bundles that are on the
>> >> Bundle-Classpath?
>> >
>> > Maybe this is a typo, but maybe it's important. I'm not going to have
>> > any *bundles* on the Bundle-Classpath, I'm going to have plain jars.
>> > (See my commons-logging example.) Does this make a difference?
>> >
>> >> This means you have unresolved dependencies in your code, which can
>> >> give you very nasty problems during deployment and running the code.
>> >> That is like putting out class files that have compile errors.
>> >
>> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
>> > framework matched my bundle's Import-Packages to other bundles
>> > Export-Packages. In this case, I don't want the framework to find a
>> > bundle that provides the package since the package is provided by the
>> > (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
>> > thought the plugin shouldn't add the package to the Import-Package
>> > statement.
>> >
>> > Is this an incorrect understanding of how OSGi works?
>> Your understanding of OSGi is correct.
>>
>> I think there is a misunderstanding about what you are describing.
>>
>> You are saying that you don't want imports generated for the same
>> packages
>> contained inside of embedded JAR files on your bundle class path,
>> correct? I
>> think Peter thought you meant that you didn't want to generate
>> imports for
>> the packages required by the packages in your embedded JAR files. You
>> want
>> the latter, but not the former...you indicate that the former is
>> probably a
>> bug in the old plugin. Correct?
>>
>> -> richard
>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> "Henrik Larsson" <he...@windh.com> writes:
>
>
>> Import-Package should *only* contain packages that are exported by
>> other bundles, not packages used from plain old jars that are in the
>> Bundle-Classpath.
>>
>
> But weren't we just talking about this policy a few days ago?¹ Richard
> commented that such behavior is intentional and beneficial.
>
I think that is a different issue, but at this point, I am uncertain. :-)
-> richard
>
> Footnotes:
> ¹ http://www.mail-archive.com/felix-dev@incubator.apache.org/msg03065.html
>
>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Steven E. Harris" <se...@panix.com>.
"Henrik Larsson" <he...@windh.com> writes:
> Import-Package should *only* contain packages that are exported by
> other bundles, not packages used from plain old jars that are in the
> Bundle-Classpath.
But weren't we just talking about this policy a few days ago?¹ Richard
commented that such behavior is intentional and beneficial.
Footnotes:
¹ http://www.mail-archive.com/felix-dev@incubator.apache.org/msg03065.html
--
Steven E. Harris
Re: Bundle plugin: Importing packages from non-bundles
Posted by Henrik Larsson <he...@windh.com>.
I'm a co-worker with Emil, so we share the same view on this (I hope ;) ).
On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
> After our discussion I decided to go back and give the old plugin a try. It
> is definitely buggy. It seems to randomly add packages to Import-Package no
> matter where they come from (plain old jars or bundles.) Maybe it is just me
> but I can't make any sense in what it is doing.
>
> I think Emil (correct me if I'm wrong) and I would both like to see only
> packages from bundle dependencies added to Import-Package, not stuff from
> embedded plain old jars (which should instead be added to the classpath.)
> The new plugin's behavior for this is nice, as long as it only looks at
> bundle dependencies and not jar dependencies. I think Emil is then saying
> that if both a bundle and a plain old jar provide a package then don't put it
> on Import-Package (i.e. let it resolve to the plain old jar via the
> classpath.) The embedded plain old jars should override bundles (maybe OSGi
> spec already dictates this.)
>
Yes, this is exactly the kind of behavior we are looking for.
It would be nice if everything could be bundles, but as that is not
the case we want to be able to embed plain old jars in our bundles
(preferably not inlined, but that's not a major point). Then
Import-Package should *only* contain packages that are exported by
other bundles, not packages used from plain old jars that are in the
Bundle-Classpath.
> The Bundle-Classpath entry from the old plugin looks good though.
>
> So, is anybody invited to work on the plugins?
>
> -Aaron
>
> P.S. I want to thank Richard and Peter for putting up with all of my
> questions/complaints. I'm learning a lot in this newsgroup.
Yes, thanks Richard and Peter. We very much appreciate your prompt and
elaborate replies.
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Wednesday, December 06, 2006 2:25 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
>
> Emil Eifrém wrote:
> > On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
> >> How can it NOT generate Import-Package for bundles that are on the
> >> Bundle-Classpath?
> >
> > Maybe this is a typo, but maybe it's important. I'm not going to have
> > any *bundles* on the Bundle-Classpath, I'm going to have plain jars.
> > (See my commons-logging example.) Does this make a difference?
> >
> >> This means you have unresolved dependencies in your code, which can
> >> give you very nasty problems during deployment and running the code.
> >> That is like putting out class files that have compile errors.
> >
> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
> > framework matched my bundle's Import-Packages to other bundles
> > Export-Packages. In this case, I don't want the framework to find a
> > bundle that provides the package since the package is provided by the
> > (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
> > thought the plugin shouldn't add the package to the Import-Package
> > statement.
> >
> > Is this an incorrect understanding of how OSGi works?
> Your understanding of OSGi is correct.
>
> I think there is a misunderstanding about what you are describing.
>
> You are saying that you don't want imports generated for the same packages
> contained inside of embedded JAR files on your bundle class path, correct? I
> think Peter thought you meant that you didn't want to generate imports for
> the packages required by the packages in your embedded JAR files. You want
> the latter, but not the former...you indicate that the former is probably a
> bug in the old plugin. Correct?
>
> -> richard
>
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/6/06, Aaron Siri <Aa...@efi.com> wrote:
> I think Emil (correct me if I'm wrong) and I would both like to see only
> packages from bundle dependencies added to Import-Package, not stuff from
> embedded plain old jars (which should instead be added to the classpath.)
> The new plugin's behavior for this is nice, as long as it only looks at
> bundle dependencies and not jar dependencies. I think Emil is then saying
> that if both a bundle and a plain old jar provide a package then don't put it
> on Import-Package (i.e. let it resolve to the plain old jar via the
> classpath.) The embedded plain old jars should override bundles (maybe OSGi
> spec already dictates this.)
This is exactly what I want. If the plugin did this then I would be fine.
All my posts so far can be summarized with this: Bundle B depends on A. Then:
A is bundle => generate Import-Package.
A is jar => embed and add to Bundle-Classpath.
Apply recursively.
[snip]
> P.S. I want to thank Richard and Peter for putting up with all of my
> questions/complaints. I'm learning a lot in this newsgroup.
Yes, likewise. Thanks for your patience and help in figuring this all out!
-EE
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/6/06, Richard S. Hall <he...@ungoverned.org> wrote:
> Your understanding of OSGi is correct.
>
> I think there is a misunderstanding about what you are describing.
>
> You are saying that you don't want imports generated for the same
> packages contained inside of embedded JAR files on your bundle class
> path, correct?
Correct.
> I think Peter thought you meant that you didn't want to
> generate imports for the packages required by the packages in your
> embedded JAR files. You want the latter, but not the former...you
> indicate that the former is probably a bug in the old plugin. Correct?
Well, the algo is recursive: if my dependency is a bundle then
generate Import-Package statements, else embed it and add it to
Bundle-Classpath. If that dependency's dependencies are bundles then
generate Import-Package statements, else embed them as well and add to
Bundle-Classpath. Lather, rinse, repeat for the transitive closure.
Cheers,
-EE
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
After our discussion I decided to go back and give the old plugin a try. It
is definitely buggy. It seems to randomly add packages to Import-Package no
matter where they come from (plain old jars or bundles.) Maybe it is just me
but I can't make any sense in what it is doing.
I think Emil (correct me if I'm wrong) and I would both like to see only
packages from bundle dependencies added to Import-Package, not stuff from
embedded plain old jars (which should instead be added to the classpath.)
The new plugin's behavior for this is nice, as long as it only looks at
bundle dependencies and not jar dependencies. I think Emil is then saying
that if both a bundle and a plain old jar provide a package then don't put it
on Import-Package (i.e. let it resolve to the plain old jar via the
classpath.) The embedded plain old jars should override bundles (maybe OSGi
spec already dictates this.)
The Bundle-Classpath entry from the old plugin looks good though.
So, is anybody invited to work on the plugins?
-Aaron
P.S. I want to thank Richard and Peter for putting up with all of my
questions/complaints. I'm learning a lot in this newsgroup.
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Wednesday, December 06, 2006 2:25 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Emil Eifrém wrote:
> On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>> How can it NOT generate Import-Package for bundles that are on the
>> Bundle-Classpath?
>
> Maybe this is a typo, but maybe it's important. I'm not going to have
> any *bundles* on the Bundle-Classpath, I'm going to have plain jars.
> (See my commons-logging example.) Does this make a difference?
>
>> This means you have unresolved dependencies in your code, which can
>> give you very nasty problems during deployment and running the code.
>> That is like putting out class files that have compile errors.
>
> Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
> framework matched my bundle's Import-Packages to other bundles
> Export-Packages. In this case, I don't want the framework to find a
> bundle that provides the package since the package is provided by the
> (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
> thought the plugin shouldn't add the package to the Import-Package
> statement.
>
> Is this an incorrect understanding of how OSGi works?
Your understanding of OSGi is correct.
I think there is a misunderstanding about what you are describing.
You are saying that you don't want imports generated for the same packages
contained inside of embedded JAR files on your bundle class path, correct? I
think Peter thought you meant that you didn't want to generate imports for
the packages required by the packages in your embedded JAR files. You want
the latter, but not the former...you indicate that the former is probably a
bug in the old plugin. Correct?
-> richard
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Emil Eifrém wrote:
> On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
>> How can it NOT generate Import-Package for bundles that are on the
>> Bundle-Classpath?
>
> Maybe this is a typo, but maybe it's important. I'm not going to have
> any *bundles* on the Bundle-Classpath, I'm going to have plain jars.
> (See my commons-logging example.) Does this make a difference?
>
>> This means you have unresolved dependencies in your
>> code, which can give you very nasty problems during deployment and
>> running the code. That is like putting out class files that have compile
>> errors.
>
> Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
> framework matched my bundle's Import-Packages to other bundles
> Export-Packages. In this case, I don't want the framework to find a
> bundle that provides the package since the package is provided by the
> (plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
> thought the plugin shouldn't add the package to the Import-Package
> statement.
>
> Is this an incorrect understanding of how OSGi works?
Your understanding of OSGi is correct.
I think there is a misunderstanding about what you are describing.
You are saying that you don't want imports generated for the same
packages contained inside of embedded JAR files on your bundle class
path, correct? I think Peter thought you meant that you didn't want to
generate imports for the packages required by the packages in your
embedded JAR files. You want the latter, but not the former...you
indicate that the former is probably a bug in the old plugin. Correct?
-> richard
Re: Re[2]: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/6/06, Peter Kriens <Pe...@aqute.biz> wrote:
> How can it NOT generate Import-Package for bundles that are on the
> Bundle-Classpath?
Maybe this is a typo, but maybe it's important. I'm not going to have
any *bundles* on the Bundle-Classpath, I'm going to have plain jars.
(See my commons-logging example.) Does this make a difference?
> This means you have unresolved dependencies in your
> code, which can give you very nasty problems during deployment and
> running the code. That is like putting out class files that have compile
> errors.
Hmm, then I'm mistaken about some OSGi fundamentals. I thought the
framework matched my bundle's Import-Packages to other bundles
Export-Packages. In this case, I don't want the framework to find a
bundle that provides the package since the package is provided by the
(plain, non-bundle) embedded jar on the Bundle-Classpath. That's why I
thought the plugin shouldn't add the package to the Import-Package
statement.
Is this an incorrect understanding of how OSGi works?
Cheers,
-EE
Re[2]: Bundle plugin: Importing packages from non-bundles
Posted by Peter Kriens <Pe...@aQute.biz>.
How can it NOT generate Import-Package for bundles that are on the
Bundle-Classpath? This means you have unresolved dependencies in your
code, which can give you very nasty problems during deployment and
running the code. That is like putting out class files that have compile
errors.
I think the old plugin is much more suitable than the new plugin for
your strategy.
Kind regards,
Peter Kriens
EE> On 12/5/06, Aaron Siri <Aa...@efi.com> wrote:
>> Again - like the war-plugin, osgi-plugin (and most other packaging maving
>> plugins that I am familiar with) jar dependencies (with the compile scope)
>> are automatically added to the artifact (in this case, a bundle) as-is and
>> made available to the runtime (in this case added to Bundle-ClassPath.)
EE> I think I've said this a number of times over the course of this
EE> thread, but just to emphasize: +1 on the above. This is exactly the
EE> behavior we need. That and making sure that the plugin is *not
EE> generating Import-Package statements for the stuff that the
EE> Bundle-Classpath jars provide*. (This last thing about Import-Package
EE> is the ONLY thing the old maven-osgi-plugin did wrong.)
EE> Cheers,
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
Re: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/5/06, Aaron Siri <Aa...@efi.com> wrote:
> Again - like the war-plugin, osgi-plugin (and most other packaging maving
> plugins that I am familiar with) jar dependencies (with the compile scope)
> are automatically added to the artifact (in this case, a bundle) as-is and
> made available to the runtime (in this case added to Bundle-ClassPath.)
I think I've said this a number of times over the course of this
thread, but just to emphasize: +1 on the above. This is exactly the
behavior we need. That and making sure that the plugin is *not
generating Import-Package statements for the stuff that the
Bundle-Classpath jars provide*. (This last thing about Import-Package
is the ONLY thing the old maven-osgi-plugin did wrong.)
Cheers,
-EE
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> Peter Kriens <Pe...@aQute.biz> writes:
>
>
>> Packaging the spec interfaces with the implementation is not only
>> very easy with bnd, I also think that is the right way to go. Last
>> week I worked on a demo and Felix jetty was the only bundle that ran
>> directly out of the box from OBR because it contained all its
>> interfaces;
>>
>
> By "its interfaces", do you mean interfaces that it implements, or
> interfaces that it /uses/ expecting someone else to have implemented?
>
> For instance, should that every bundle that uses (as a client) the
> OSGi LogService include all of org.osgi.service.log? Or do you just
> mean that the Felix Log implementation includes all of
> org.osgi.service.log?
>
I believe Peter was referring to interfaces you implement, not the ones
that you require.
-> richard
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> I'm starting to think that the older osgi-plugin was a better fit with the
> maven model and that bnd isn't very mavenisable or doesn't translate to maven
> well. But maybe a happy median can be achieved?
>
I believe that a middle ground can be reached here...
-> richard
> -Aaron
>
> -----Original Message-----
> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
> Sent: Wednesday, December 06, 2006 11:06 AM
> To: Richard S. Hall
> Cc: felix-dev@incubator.apache.org
> Subject: Re[2]: Bundling interfaces and implementations (was: Bundle plugin:
> Importing packages from non-bundles)
>
> I completely concur with Richard. Import-Package is for me the way to go and
> is even officially preferred by the OSGi Alliance (look at the disadvantages
> of using Require-Bundle in the spec, and also in my blogs). One reason I like
> Felix is this fanatic focus on decoupling.
>
> The bnd plugin is targeted at making bundles directly from the classpath that
> use Import-Package to minimize coupling between bundles. Packaging the spec
> interfaces with the implementation is not only very easy with bnd, I also
> think that is the right way to go.
> Last week I worked on a demo and Felix jetty was the only bundle that ran
> directly out of the box from OBR because it contained all its interfaces;
> really nice in my opinion.
>
> However, this model is very different from the maven policy of transitive
> dependencies on artifacts.
>
> Starting to support Require-Bundle in bnd is therefore counter to its
> original goal. If you really think you need Require-Bundle, maybe this plugin
> is not the way to go then. I am afraid that if I add all these features to
> the plugin it becomes complex and bloated and overriding its original goal.
>
> Maybe we need multiple plugins ...
>
> Kind regards,
>
> Peter Kriens
>
>
>
> RSH> On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:
>
>
>>> Richard S. Hall <he...@ungoverned.org> writes:
>>>
>>>
>>>> The spec used to recommend packaging a bundle with its
>>>> interfaces...I am not sure if it still does or not, but it is
>>>> definitely not anti-OSGi.
>>>>
>>> Today I've been wondering about this too. In many cases, I wish to
>>> define some service interface for clients to use, then write at least
>>> one implementation of the service interface. Clients will rely on the
>>> interfaces, but should have no knowledge of the implementation(s).
>>> What's the right way to package this in OSGi?
>>>
>>> If I put the interfaces in the same bundle as the implementation, the
>>> two have to be in different packages to maintain the intended privacy
>>> of the implementation. Alternately, I can place the interfaces in a
>>> bundle, and have both the clients and the implementation bundle rely
>>> on that interface-only bundle. This is based on the assumption that a
>>> given class or interface should only wind up in one bundle. Also, the
>>> latter separated approach seems more favorable to there being
>>> multiple implementations of a single interface, as it wouldn't make
>>> sense to put the interfaces in the first implementation's bundle and
>>> have all other implementations rely on the first.
>>>
>>> Since Felix is written largely as an implementation of a separate set
>>> of OSGi interfaces, it's more obvious how it splits the two domains.
>>> For an application or system that's more self-contained, though, it's
>>> harder to figure out a discipline for separating interfaces and
>>> implementations.
>>>
>
> RSH> Overall, it doesn't really make a difference which approach you
> RSH> choose, since they will all work equally well on the OSGi
> RSH> framework. The main issues are that if you separate out interfaces,
> RSH> then you end up with a bunch of small bundles needing to be
> RSH> deployed and you essentially have no self-contained bundles.
>
> RSH> If you package service interfaces with all of your service
> RSH> implementations (and both import and export them), then the
> RSH> framework will correctly handle sharing among the different
> RSH> providers properly so that they can interoperate (if possible). The
> RSH> main downside to this approach is that if you refresh the
> RSH> implementation it will also refresh any dependent clients or other
> providers.
>
> RSH> If you expect to only have one service provider at a time, then it
> RSH> might make sense to package the service interfaces with the service
> RSH> impl. If you expect to have multiple providers of the same service,
> RSH> then maybe it makes sense to package the service interfaces separately.
>
> RSH> Unfortunately, there is no single rule.
>
> ->> richard
>
>
>
Re: Bundling interfaces and implementations
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 01:51, Steven E. Harris wrote:
> Peter Kriens <Pe...@aQute.biz> writes:
> > Packaging the spec interfaces with the implementation is not only
> > very easy with bnd, I also think that is the right way to go. Last
> > week I worked on a demo and Felix jetty was the only bundle that ran
> > directly out of the box from OBR because it contained all its
> > interfaces;
>
> By "its interfaces", do you mean interfaces that it implements, or
> interfaces that it /uses/ expecting someone else to have implemented?
As Richard points out, I am pretty sure Peter is talking about the *public*
interfaces of the bundle. One of the beauties of OSGi is that it allows you
to easily define the *actual* API and protect everything else from abuse.
> For instance, should that every bundle that uses (as a client) the
> OSGi LogService include all of org.osgi.service.log? Or do you just
> mean that the Felix Log implementation includes all of
> org.osgi.service.log?
The latter. But *I* happen to like to go one step further and put the API in a
separate bundle from the implementation. This allows me to upgrade the
implementation without the clients being stopped. And the lower in the stack
you go the sweeter this distinction becomes.
Cheers
Niclas
P.S. It is nice to see so many new faces, and hopefully this is the beginning
of *take off* for OSGi and Felix.
Re[2]: Bundling interfaces and implementations
Posted by Peter Kriens <Pe...@aQute.biz>.
SEH> Peter Kriens <Pe...@aQute.biz> writes:
>> Packaging the spec interfaces with the implementation is not only
>> very easy with bnd, I also think that is the right way to go. Last
>> week I worked on a demo and Felix jetty was the only bundle that ran
>> directly out of the box from OBR because it contained all its
>> interfaces;
SEH> By "its interfaces", do you mean interfaces that it implements, or
SEH> interfaces that it /uses/ expecting someone else to have implemented?
The one that provides the functionality should carry the interfaces.
Depending on the service specification this can both be the
implementer as the user of the Java interface. For example, log
implementer should contain the org.osgi.service.log that contains both
interfaces it implementes (LogService, LogReaderService, LogEntry) and uses
(LogListener).
SEH> For instance, should that every bundle that uses (as a client) the
SEH> OSGi LogService include all of org.osgi.service.log? Or do you just
SEH> mean that the Felix Log implementation includes all of
SEH> org.osgi.service.log?
Yes.
Then again, this is a choice. It makes the bundle standalone and
capable of providing its functionality in every environment without
requiring other bundles, exactly the way I like it.
However, these choices you make when you design the packaging and you
can set it up in many different ways. This is just my personal opinion
of best practice, feel free to do it differently.
Kind regards,
Peter Kriens
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Bundling interfaces and implementations
Posted by "Steven E. Harris" <se...@panix.com>.
Peter Kriens <Pe...@aQute.biz> writes:
> Packaging the spec interfaces with the implementation is not only
> very easy with bnd, I also think that is the right way to go. Last
> week I worked on a demo and Felix jetty was the only bundle that ran
> directly out of the box from OBR because it contained all its
> interfaces;
By "its interfaces", do you mean interfaces that it implements, or
interfaces that it /uses/ expecting someone else to have implemented?
For instance, should that every bundle that uses (as a client) the
OSGi LogService include all of org.osgi.service.log? Or do you just
mean that the Felix Log implementation includes all of
org.osgi.service.log?
--
Steven E. Harris
Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 12:41, Aaron Siri wrote:
> "What Peter's tools has done so far, is to traverse the bytecodes and
> locate all the packages that are referenced one way or the other. A task
> not fit for humans."
>
> But with maven you've already done this with the dependency definitions.
> It wouldn't have compiled otherwise. Maven will also take care of
> dependency dependencies and let you specify packaging intent. The plugin
> then needlessly does a lot of bytecode inspection just to figure out what
> maven already told you was needed. As a stand-alone tool that is slick, as
> a maven plugin it is redundant and confusing.
Well, that is incorrect.
Firstly, every compile I have seen on the market includes rt.jar, which
contains all kinds of classes that must be imported if referenced one, two or
more levels down.
Secondly, everything on the market isn't compiled with Maven. Many projects
out there has been "mavenized" independently and most of them has poms
without dependency information, hence the information is lost.
> Why oh why would you even bring up the jar vs. package debate? For better
> or worse .jar is the standard "packaging" mechanism and packages have been
> regulated to namespace duty. ;) As long as code is delivered via .jars
> why don't we keep it in that format? I don't want to second guess why
> things are packaged as they are. We are just trying to keep our bundles
> neat and organized. :P
Well, the "world is wrong" ;o) and the OSGi community has chosen to state
that, stick by it and evangelize that "package" keyword is more than a
classname prefix (namespace is inapproriate term as well, since the JVM has a
concept of class namespace different from this).
Now, personally I am not much in favour of "inlining", but there are
exceptions. Example; Let's say I use one class in the Jakarta Commons
Collection jar. I don't like to have my bundle depend on a "not yet
bundlized" commons-collection, and sticking a 558kB into my bundle seems a
bit of overkill, especially if it is a very commonly recurring class.
I agree that inling should not be default, but it should be supported.
I disagree that Maven's model is rich enough to support OSGi modelling, and I
doubt that we will ever see a change, partly due to the "WTF do you mean is
wrong with the Jar as the versioned artifact to drive the compile and runtime
cycles?" attitude that is the first reaction when trying to explain the
problem domain to non-OSGiers.
Cheers
Niclas
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> Why oh why would you even bring up the jar vs. package debate? For better or
> worse .jar is the standard "packaging" mechanism and packages have been
> regulated to namespace duty. ;) As long as code is delivered via .jars why
> don't we keep it in that format? I don't want to second guess why things are
> packaged as they are. We are just trying to keep our bundles neat and
> organized. :P
>
Well, the OSGi framework works in terms of packages, not JARs.
-> richard
> -Aaron
>
>
>
> -----Original Message-----
> From: Niclas Hedhman on behalf of Niclas Hedhman
> Sent: Wed 12/6/2006 8:53 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundling interfaces and implementations (was: Bundle plugin:
> Importing packages from non-bundles)
>
> On Thursday 07 December 2006 00:54, Aaron Siri wrote:
>
>> What if we did away with <Private-Package> (or detect a special value) and
>> just assume that all maven jar dependencies are required by the bundle
>> packages with packaging of the jars honoring the dependency definitions
>> (i.e. compile, provided, etc.)? The classpath is added to the manifest.
>> You can Export-Package/Import-Package as done today. Could this work?
>>
>
> I have not yet taken a proper look at bnd, but your suggestions doesn't sound
>
> sound... ;o)
>
> What Peter's tools has done so far, is to traverse the bytecodes and locate
> all the packages that are referenced one way or the other. A task not fit for
>
> humans.
> Now, it makes a lot sense to me that the tool is *not* authorative in the
> normal case, but defaults to something useful for the average idiot like
> myself. I assume you are refering to such defaults... That can probably be
> achieved, once the principles are agreed upon.
>
> Private-Package sounds like a short-cut to "full review" of the found
> packages
> and essentially Export-Package vs Private-Package is analogous with "allow"
> vs "deny" in Httpd server.
>
> Further, packaging can be done in three ways;
>
> 1. embedding - Put the dependent jar file of classes into the Bundle jar.
> 2. inlining - Put the dependent classes into the Bundle jar
> 3. external - Reference to the requirement in Import-Package/Require-Bundle
>
> The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter,
>
> myself, Richard (sorry guys) grew up in days where resources were not
> abundant, bark was used as flour and Jack the Ripper was the real reality
> show for whores in London, so we get sick in the stomach when we see a 2MB
> jar file included in a bundle just because a single 2kB class is referenced.
>
> The point Peter always tries to make is that the Jar is a Java after-thought,
>
> a hack and that Sun actually had it more right from day 1, in that the
> package is the natural "container" of classes, and it was only lacking proper
>
> versioning and other annotations from the start. We should be able to ignore
> the Jar itself, take it for what it is; A ZIP file for easy transport.
> Maven, other build systems, the JVMs classpath and endless other systems
> assumes that the jar file carries additional significance, such as being a
> unique identifier of its content, or that the content will only reside in jar
>
> files that follows this particular naming conventions and if the classes
> resurface elsewhere, then "elsewhere" is raping someone elses work.
>
> Ok, a lot of rambling...<stop/>
>
>
> Cheers
> Niclas
>
>
RE: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Aaron Siri <Aa...@efi.com>.
"What Peter's tools has done so far, is to traverse the bytecodes and locate
all the packages that are referenced one way or the other. A task not fit for
humans."
But with maven you've already done this with the dependency definitions. It
wouldn't have compiled otherwise. Maven will also take care of dependency
dependencies and let you specify packaging intent. The plugin then
needlessly does a lot of bytecode inspection just to figure out what maven
already told you was needed. As a stand-alone tool that is slick, as a maven
plugin it is redundant and confusing.
What we are saying is let the pom drive the packaging and the classpath. Let
the plugin do the neat Import/Export stuff it is doing now. We aren't trying
to change how bnd behaves, just how the new plugin behaves. If they are so
tightly coupled that you can't change one without changing the other then
perhaps that is the issue that needs to be addressed.
Why oh why would you even bring up the jar vs. package debate? For better or
worse .jar is the standard "packaging" mechanism and packages have been
regulated to namespace duty. ;) As long as code is delivered via .jars why
don't we keep it in that format? I don't want to second guess why things are
packaged as they are. We are just trying to keep our bundles neat and
organized. :P
-Aaron
-----Original Message-----
From: Niclas Hedhman on behalf of Niclas Hedhman
Sent: Wed 12/6/2006 8:53 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundling interfaces and implementations (was: Bundle plugin:
Importing packages from non-bundles)
On Thursday 07 December 2006 00:54, Aaron Siri wrote:
> What if we did away with <Private-Package> (or detect a special value) and
> just assume that all maven jar dependencies are required by the bundle
> packages with packaging of the jars honoring the dependency definitions
> (i.e. compile, provided, etc.)? The classpath is added to the manifest.
> You can Export-Package/Import-Package as done today. Could this work?
I have not yet taken a proper look at bnd, but your suggestions doesn't sound
sound... ;o)
What Peter's tools has done so far, is to traverse the bytecodes and locate
all the packages that are referenced one way or the other. A task not fit for
humans.
Now, it makes a lot sense to me that the tool is *not* authorative in the
normal case, but defaults to something useful for the average idiot like
myself. I assume you are refering to such defaults... That can probably be
achieved, once the principles are agreed upon.
Private-Package sounds like a short-cut to "full review" of the found
packages
and essentially Export-Package vs Private-Package is analogous with "allow"
vs "deny" in Httpd server.
Further, packaging can be done in three ways;
1. embedding - Put the dependent jar file of classes into the Bundle jar.
2. inlining - Put the dependent classes into the Bundle jar
3. external - Reference to the requirement in Import-Package/Require-Bundle
The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter,
myself, Richard (sorry guys) grew up in days where resources were not
abundant, bark was used as flour and Jack the Ripper was the real reality
show for whores in London, so we get sick in the stomach when we see a 2MB
jar file included in a bundle just because a single 2kB class is referenced.
The point Peter always tries to make is that the Jar is a Java after-thought,
a hack and that Sun actually had it more right from day 1, in that the
package is the natural "container" of classes, and it was only lacking proper
versioning and other annotations from the start. We should be able to ignore
the Jar itself, take it for what it is; A ZIP file for easy transport.
Maven, other build systems, the JVMs classpath and endless other systems
assumes that the jar file carries additional significance, such as being a
unique identifier of its content, or that the content will only reside in jar
files that follows this particular naming conventions and if the classes
resurface elsewhere, then "elsewhere" is raping someone elses work.
Ok, a lot of rambling...<stop/>
Cheers
Niclas
Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 00:54, Aaron Siri wrote:
> What if we did away with <Private-Package> (or detect a special value) and
> just assume that all maven jar dependencies are required by the bundle
> packages with packaging of the jars honoring the dependency definitions
> (i.e. compile, provided, etc.)? The classpath is added to the manifest.
> You can Export-Package/Import-Package as done today. Could this work?
I have not yet taken a proper look at bnd, but your suggestions doesn't sound
sound... ;o)
What Peter's tools has done so far, is to traverse the bytecodes and locate
all the packages that are referenced one way or the other. A task not fit for
humans.
Now, it makes a lot sense to me that the tool is *not* authorative in the
normal case, but defaults to something useful for the average idiot like
myself. I assume you are refering to such defaults... That can probably be
achieved, once the principles are agreed upon.
Private-Package sounds like a short-cut to "full review" of the found packages
and essentially Export-Package vs Private-Package is analogous with "allow"
vs "deny" in Httpd server.
Further, packaging can be done in three ways;
1. embedding - Put the dependent jar file of classes into the Bundle jar.
2. inlining - Put the dependent classes into the Bundle jar
3. external - Reference to the requirement in Import-Package/Require-Bundle
The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter,
myself, Richard (sorry guys) grew up in days where resources were not
abundant, bark was used as flour and Jack the Ripper was the real reality
show for whores in London, so we get sick in the stomach when we see a 2MB
jar file included in a bundle just because a single 2kB class is referenced.
The point Peter always tries to make is that the Jar is a Java after-thought,
a hack and that Sun actually had it more right from day 1, in that the
package is the natural "container" of classes, and it was only lacking proper
versioning and other annotations from the start. We should be able to ignore
the Jar itself, take it for what it is; A ZIP file for easy transport.
Maven, other build systems, the JVMs classpath and endless other systems
assumes that the jar file carries additional significance, such as being a
unique identifier of its content, or that the content will only reside in jar
files that follows this particular naming conventions and if the classes
resurface elsewhere, then "elsewhere" is raping someone elses work.
Ok, a lot of rambling...<stop/>
Cheers
Niclas
RE: Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Aaron Siri <Aa...@efi.com>.
I actually don't mind import-package vs. require-bundle and reading the spec
I have to agree with you that import-package is the recommendation.
My issue is more of a packaging issue and how the plugin interprets the maven
environment. The bundle plugin, unless I'm mistaken, rips classes out of
dependency, non-bundle jars and puts the classes into the local bundle rather
than just embedding the .jar as a .jar and putting it on the classpath. It
ignores the maven dependencies for packaging purposes and forces the user to
manually figure out which packages are needed and specify them via
<Private-Package>.
What if we did away with <Private-Package> (or detect a special value) and
just assume that all maven jar dependencies are required by the bundle
packages with packaging of the jars honoring the dependency definitions (i.e.
compile, provided, etc.)? The classpath is added to the manifest. You can
Export-Package/Import-Package as done today. Could this work?
I'm starting to think that the older osgi-plugin was a better fit with the
maven model and that bnd isn't very mavenisable or doesn't translate to maven
well. But maybe a happy median can be achieved?
-Aaron
-----Original Message-----
From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
Sent: Wednesday, December 06, 2006 11:06 AM
To: Richard S. Hall
Cc: felix-dev@incubator.apache.org
Subject: Re[2]: Bundling interfaces and implementations (was: Bundle plugin:
Importing packages from non-bundles)
I completely concur with Richard. Import-Package is for me the way to go and
is even officially preferred by the OSGi Alliance (look at the disadvantages
of using Require-Bundle in the spec, and also in my blogs). One reason I like
Felix is this fanatic focus on decoupling.
The bnd plugin is targeted at making bundles directly from the classpath that
use Import-Package to minimize coupling between bundles. Packaging the spec
interfaces with the implementation is not only very easy with bnd, I also
think that is the right way to go.
Last week I worked on a demo and Felix jetty was the only bundle that ran
directly out of the box from OBR because it contained all its interfaces;
really nice in my opinion.
However, this model is very different from the maven policy of transitive
dependencies on artifacts.
Starting to support Require-Bundle in bnd is therefore counter to its
original goal. If you really think you need Require-Bundle, maybe this plugin
is not the way to go then. I am afraid that if I add all these features to
the plugin it becomes complex and bloated and overriding its original goal.
Maybe we need multiple plugins ...
Kind regards,
Peter Kriens
RSH> On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:
>> Richard S. Hall <he...@ungoverned.org> writes:
>>
>>> The spec used to recommend packaging a bundle with its
>>> interfaces...I am not sure if it still does or not, but it is
>>> definitely not anti-OSGi.
>>
>> Today I've been wondering about this too. In many cases, I wish to
>> define some service interface for clients to use, then write at least
>> one implementation of the service interface. Clients will rely on the
>> interfaces, but should have no knowledge of the implementation(s).
>> What's the right way to package this in OSGi?
>>
>> If I put the interfaces in the same bundle as the implementation, the
>> two have to be in different packages to maintain the intended privacy
>> of the implementation. Alternately, I can place the interfaces in a
>> bundle, and have both the clients and the implementation bundle rely
>> on that interface-only bundle. This is based on the assumption that a
>> given class or interface should only wind up in one bundle. Also, the
>> latter separated approach seems more favorable to there being
>> multiple implementations of a single interface, as it wouldn't make
>> sense to put the interfaces in the first implementation's bundle and
>> have all other implementations rely on the first.
>>
>> Since Felix is written largely as an implementation of a separate set
>> of OSGi interfaces, it's more obvious how it splits the two domains.
>> For an application or system that's more self-contained, though, it's
>> harder to figure out a discipline for separating interfaces and
>> implementations.
RSH> Overall, it doesn't really make a difference which approach you
RSH> choose, since they will all work equally well on the OSGi
RSH> framework. The main issues are that if you separate out interfaces,
RSH> then you end up with a bunch of small bundles needing to be
RSH> deployed and you essentially have no self-contained bundles.
RSH> If you package service interfaces with all of your service
RSH> implementations (and both import and export them), then the
RSH> framework will correctly handle sharing among the different
RSH> providers properly so that they can interoperate (if possible). The
RSH> main downside to this approach is that if you refresh the
RSH> implementation it will also refresh any dependent clients or other
providers.
RSH> If you expect to only have one service provider at a time, then it
RSH> might make sense to package the service interfaces with the service
RSH> impl. If you expect to have multiple providers of the same service,
RSH> then maybe it makes sense to package the service interfaces separately.
RSH> Unfortunately, there is no single rule.
->> richard
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Peter Kriens <Pe...@aQute.biz>.
I completely concur with Richard. Import-Package is for me the way to
go and is even officially preferred by the OSGi Alliance (look at the
disadvantages of using Require-Bundle in the spec, and also in my
blogs). One reason I like Felix is this fanatic focus on decoupling.
The bnd plugin is targeted at making bundles directly from the
classpath that use Import-Package to minimize coupling between
bundles. Packaging the spec interfaces with the implementation is not
only very easy with bnd, I also think that is the right way to go.
Last week I worked on a demo and Felix jetty was the only bundle that
ran directly out of the box from OBR because it contained all its
interfaces; really nice in my opinion.
However, this model is very different from the maven policy of transitive
dependencies on artifacts.
Starting to support Require-Bundle in bnd is therefore counter to its
original goal. If you really think you need Require-Bundle, maybe this
plugin is not the way to go then. I am afraid that if I add all these
features to the plugin it becomes complex and bloated and overriding
its original goal.
Maybe we need multiple plugins ...
Kind regards,
Peter Kriens
RSH> On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:
>> Richard S. Hall <he...@ungoverned.org> writes:
>>
>>> The spec used to recommend packaging a bundle with its
>>> interfaces...I am not sure if it still does or not, but it is
>>> definitely not anti-OSGi.
>>
>> Today I've been wondering about this too. In many cases, I wish to
>> define some service interface for clients to use, then write at least
>> one implementation of the service interface. Clients will rely on the
>> interfaces, but should have no knowledge of the
>> implementation(s). What's the right way to package this in OSGi?
>>
>> If I put the interfaces in the same bundle as the implementation, the
>> two have to be in different packages to maintain the intended privacy
>> of the implementation. Alternately, I can place the interfaces in a
>> bundle, and have both the clients and the implementation bundle rely
>> on that interface-only bundle. This is based on the assumption that a
>> given class or interface should only wind up in one bundle. Also, the
>> latter separated approach seems more favorable to there being multiple
>> implementations of a single interface, as it wouldn't make sense to
>> put the interfaces in the first implementation's bundle and have all
>> other implementations rely on the first.
>>
>> Since Felix is written largely as an implementation of a separate set
>> of OSGi interfaces, it's more obvious how it splits the two
>> domains. For an application or system that's more self-contained,
>> though, it's harder to figure out a discipline for separating
>> interfaces and implementations.
RSH> Overall, it doesn't really make a difference which approach you choose,
RSH> since they will all work equally well on the OSGi framework. The main
RSH> issues are that if you separate out interfaces, then you end up with a
RSH> bunch of small bundles needing to be deployed and you essentially have
RSH> no self-contained bundles.
RSH> If you package service interfaces with all of your service
RSH> implementations (and both import and export them), then the framework
RSH> will correctly handle sharing among the different providers properly so
RSH> that they can interoperate (if possible). The main downside to this
RSH> approach is that if you refresh the implementation it will also refresh
RSH> any dependent clients or other providers.
RSH> If you expect to only have one service provider at a time, then it
RSH> might make sense to package the service interfaces with the service
RSH> impl. If you expect to have multiple providers of the same service,
RSH> then maybe it makes sense to package the service interfaces separately.
RSH> Unfortunately, there is no single rule.
->> richard
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Bundling interfaces and implementations
Posted by Jeff McAffer <Je...@ca.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 12/05/2006 07:00:14 PM:
> On Dec 5, 2006, at 6:47 PM, Aaron Siri wrote:
>
> > If you haven't already taken a look at equinox you should. Eclipse is
> > a good
> > example of an app built atop OSGi from which to learn. If equinox is
> > a bad
> > word around here then I apologize.
> >
> > Anyways, it already has the concept of plugins, extension points, etc
> > built
> > atop OSGi using xml descriptors. You can use it all without any of
the
> > eclipse UI/app framework. Just download the equinox SDK and you'll
> > have
> > almost everything you'll need. We are using it for a web-based
> > application
> > where we and third parties can plug in functionality.
> >
> > BTW, is the equinox/felix relationship friendly?
>
> Sure it is...well, except for that McAffer guy... (sorry Jeff, I
> couldn't resist)
Don't blame you. I likely could not have resisted the inverse jab... ;-)
Truth be known for everyone out there I have the utmost respect for
Richard and all the work being done in Felix. Its great.
> We have a few differences in opinion on "best practices", but otherwise
> we work together and discuss with each other quite regularly.
Too much is likely made of these differences (actually, I likely make to
much of them sometimes). Fact is that all the OSGi communities out there
are keen on modularity, simplicity, dynamic behaviour and see OSGi as a
great vehicle. There are some different usecases and priorities driving
the work being done. Certainly in the Equinox community we are actively
seeking to reduce/eliminate any "containerisms" that we may have.
In short, people should feel comfortable adopting OSGi as a base
technology for their software knowing that this is a cohesive community
and that ultimately they have choices in the implementation they use.
Jeff (aka, "that McAffer guy")
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 6:47 PM, Aaron Siri wrote:
> If you haven't already taken a look at equinox you should. Eclipse is
> a good
> example of an app built atop OSGi from which to learn. If equinox is
> a bad
> word around here then I apologize.
>
> Anyways, it already has the concept of plugins, extension points, etc
> built
> atop OSGi using xml descriptors. You can use it all without any of the
> eclipse UI/app framework. Just download the equinox SDK and you'll
> have
> almost everything you'll need. We are using it for a web-based
> application
> where we and third parties can plug in functionality.
>
> BTW, is the equinox/felix relationship friendly?
Sure it is...well, except for that McAffer guy... (sorry Jeff, I
couldn't resist)
We have a few differences in opinion on "best practices", but otherwise
we work together and discuss with each other quite regularly.
-> richard
>
> -Aaron
>
> -----Original Message-----
> From: Steven E. Harris [mailto:seh@panix.com]
> Sent: Tuesday, December 05, 2006 6:34 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundling interfaces and implementations
>
> Richard S. Hall <he...@ungoverned.org> writes:
>
>> The main issues are that if you separate out interfaces, then you end
>> up with a bunch of small bundles needing to be deployed and you
>> essentially have no self-contained bundles.
>
> Right, that's what I'm seeing emerge. For example, I have one bundle
> right
> now that has one class in it.
>
> The motivating scenario for my application is this: The application
> has a
> couple of "plugin types" (defined as interfaces) for which it expects
> to
> download and install lots of plugins, each of which will be an OSGi
> bundle.
> Perhaps this is analogous to a servlet container; there's one servlet
> API
> set, and lots of servlets that will come along and implement it.
>
> Obviously the application itself needs access to these interfaces, as
> do the
> plugins. The interfaces have no obvious home. If the plugins could be
> developed by third parties, we'd have to make the interface class files
> available in some way, regardless of what bundle they eventually wind
> up in.
> Normally we have these decisions to make about how to organize source
> in a
> tree, how to package it for distribution or deployment, and now with
> bundles
> we have yet another dimension to consider.
>
>> If you expect to have multiple providers of the same service, then
>> maybe it makes sense to package the service interfaces separately.
>
> That sounds more like my situation.
>
>> Unfortunately, there is no single rule.
>
> Even so, we need more example applications built atop OSGi from which
> to
> learn.
>
> --
> Steven E. Harris
RE: Bundling interfaces and implementations
Posted by Aaron Siri <Aa...@efi.com>.
If you haven't already taken a look at equinox you should. Eclipse is a good
example of an app built atop OSGi from which to learn. If equinox is a bad
word around here then I apologize.
Anyways, it already has the concept of plugins, extension points, etc built
atop OSGi using xml descriptors. You can use it all without any of the
eclipse UI/app framework. Just download the equinox SDK and you'll have
almost everything you'll need. We are using it for a web-based application
where we and third parties can plug in functionality.
BTW, is the equinox/felix relationship friendly?
-Aaron
-----Original Message-----
From: Steven E. Harris [mailto:seh@panix.com]
Sent: Tuesday, December 05, 2006 6:34 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundling interfaces and implementations
Richard S. Hall <he...@ungoverned.org> writes:
> The main issues are that if you separate out interfaces, then you end
> up with a bunch of small bundles needing to be deployed and you
> essentially have no self-contained bundles.
Right, that's what I'm seeing emerge. For example, I have one bundle right
now that has one class in it.
The motivating scenario for my application is this: The application has a
couple of "plugin types" (defined as interfaces) for which it expects to
download and install lots of plugins, each of which will be an OSGi bundle.
Perhaps this is analogous to a servlet container; there's one servlet API
set, and lots of servlets that will come along and implement it.
Obviously the application itself needs access to these interfaces, as do the
plugins. The interfaces have no obvious home. If the plugins could be
developed by third parties, we'd have to make the interface class files
available in some way, regardless of what bundle they eventually wind up in.
Normally we have these decisions to make about how to organize source in a
tree, how to package it for distribution or deployment, and now with bundles
we have yet another dimension to consider.
> If you expect to have multiple providers of the same service, then
> maybe it makes sense to package the service interfaces separately.
That sounds more like my situation.
> Unfortunately, there is no single rule.
Even so, we need more example applications built atop OSGi from which to
learn.
--
Steven E. Harris
Re: Bundling interfaces and implementations
Posted by "Steven E. Harris" <se...@panix.com>.
Richard S. Hall <he...@ungoverned.org> writes:
> The main issues are that if you separate out interfaces, then you
> end up with a bunch of small bundles needing to be deployed and you
> essentially have no self-contained bundles.
Right, that's what I'm seeing emerge. For example, I have one bundle
right now that has one class in it.
The motivating scenario for my application is this: The application
has a couple of "plugin types" (defined as interfaces) for which it
expects to download and install lots of plugins, each of which will be
an OSGi bundle. Perhaps this is analogous to a servlet container;
there's one servlet API set, and lots of servlets that will come along
and implement it.
Obviously the application itself needs access to these interfaces, as
do the plugins. The interfaces have no obvious home. If the plugins
could be developed by third parties, we'd have to make the interface
class files available in some way, regardless of what bundle they
eventually wind up in. Normally we have these decisions to make about
how to organize source in a tree, how to package it for distribution
or deployment, and now with bundles we have yet another dimension to
consider.
> If you expect to have multiple providers of the same service, then
> maybe it makes sense to package the service interfaces separately.
That sounds more like my situation.
> Unfortunately, there is no single rule.
Even so, we need more example applications built atop OSGi from which
to learn.
--
Steven E. Harris
Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:
> Richard S. Hall <he...@ungoverned.org> writes:
>
>> The spec used to recommend packaging a bundle with its
>> interfaces...I am not sure if it still does or not, but it is
>> definitely not anti-OSGi.
>
> Today I've been wondering about this too. In many cases, I wish to
> define some service interface for clients to use, then write at least
> one implementation of the service interface. Clients will rely on the
> interfaces, but should have no knowledge of the
> implementation(s). What's the right way to package this in OSGi?
>
> If I put the interfaces in the same bundle as the implementation, the
> two have to be in different packages to maintain the intended privacy
> of the implementation. Alternately, I can place the interfaces in a
> bundle, and have both the clients and the implementation bundle rely
> on that interface-only bundle. This is based on the assumption that a
> given class or interface should only wind up in one bundle. Also, the
> latter separated approach seems more favorable to there being multiple
> implementations of a single interface, as it wouldn't make sense to
> put the interfaces in the first implementation's bundle and have all
> other implementations rely on the first.
>
> Since Felix is written largely as an implementation of a separate set
> of OSGi interfaces, it's more obvious how it splits the two
> domains. For an application or system that's more self-contained,
> though, it's harder to figure out a discipline for separating
> interfaces and implementations.
Overall, it doesn't really make a difference which approach you choose,
since they will all work equally well on the OSGi framework. The main
issues are that if you separate out interfaces, then you end up with a
bunch of small bundles needing to be deployed and you essentially have
no self-contained bundles.
If you package service interfaces with all of your service
implementations (and both import and export them), then the framework
will correctly handle sharing among the different providers properly so
that they can interoperate (if possible). The main downside to this
approach is that if you refresh the implementation it will also refresh
any dependent clients or other providers.
If you expect to only have one service provider at a time, then it
might make sense to package the service interfaces with the service
impl. If you expect to have multiple providers of the same service,
then maybe it makes sense to package the service interfaces separately.
Unfortunately, there is no single rule.
-> richard
Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by "Steven E. Harris" <se...@panix.com>.
Richard S. Hall <he...@ungoverned.org> writes:
> The spec used to recommend packaging a bundle with its
> interfaces...I am not sure if it still does or not, but it is
> definitely not anti-OSGi.
Today I've been wondering about this too. In many cases, I wish to
define some service interface for clients to use, then write at least
one implementation of the service interface. Clients will rely on the
interfaces, but should have no knowledge of the
implementation(s). What's the right way to package this in OSGi?
If I put the interfaces in the same bundle as the implementation, the
two have to be in different packages to maintain the intended privacy
of the implementation. Alternately, I can place the interfaces in a
bundle, and have both the clients and the implementation bundle rely
on that interface-only bundle. This is based on the assumption that a
given class or interface should only wind up in one bundle. Also, the
latter separated approach seems more favorable to there being multiple
implementations of a single interface, as it wouldn't make sense to
put the interfaces in the first implementation's bundle and have all
other implementations rely on the first.
Since Felix is written largely as an implementation of a separate set
of OSGi interfaces, it's more obvious how it splits the two
domains. For an application or system that's more self-contained,
though, it's harder to figure out a discipline for separating
interfaces and implementations.
Advice and examples would be welcome.
--
Steven E. Harris
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 6:39 PM, Aaron Siri wrote:
> Anyways, Maven has nothing to do with any of this. Maven only pulls
> what you
> need (well - it pulls what you say you need.) If you say your hello
> world
> app depends on all of jakarta then that is what maven will pull down
> (only
> once BTW, everything maven pulls is cached.)
In general, my experience has been that JAR files are not very
cohesive. You must be luckier than I am.
> I guess I just don't like how the Export-Package and Private-Package
> instructions pull the required code into the bundle by ripping apart
> other
> bundles/jars (honestly, I'm in awe that people find this acceptable.)
> I'd
> rather embed the clean jars (as is, not-unrolled), add them to the
> Bundle-Classpath and then build Export-Package off of them.
> Import-package
> can be built off of the dependency bundles (probably what it is doing
> already.) <Private-Package> seems unnecessary.
Again, you are taking a special case and making it the common case.
Normally, what you would do is specify the root package of your project
(e.g., org.myproject.*) and be done. The average project should not be
copying stuff from their dependencies. In some cases this makes sense.
The assertion that embedding JARs is clean is not necessarily accurate
either, unless you know that there is no overlap between any of the
JARs being combined. If there is overlap, then you will end up
shadowing or mixing class versions. In the end, you have to have some
knowledge about what you are doing.
The purest way is to import everything not contained in your project.
> The anti-OSGi statement was a little harsh. I apologize if I
> offended. OSGi
> strikes me as promoting modularity and "self-contained" bundles, to
> me, seem
> to contradict that.
There is no general promotion of "self-contained" bundles here. The
issue is, sometimes it makes sense. If it doesn't make sense for your
situation, that is fine by me. If you would rather pull in a large JAR
file rather than copy out two interface definitions that you need, that
works. I prefer not to. I see room for both approaches.
> But, I'm used to equinox and the eclipse environment
> where bundles are very modular.
ROTFL.
-> richard
>
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 5:30 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> On Dec 5, 2006, at 5:15 PM, Aaron Siri wrote:
>
>> In your example, if I'm not mistaken, you are taking binaries from one
>> bundle and including them in your own bundle (instead of depending on
>> the bundle at runtime). Now this seems anti-OSGi :)
>
> Not at all anti-OSGi...the OSGi framework automatically deals with
> multiple
> providers of the same package (in my example the Log Service exports
> the log
> package). The spec used to recommend packaging a bundle with its
> interfaces...I am not sure if it still does or not, but it is
> definitely not
> anti-OSGi.
>
> To me, using Require-Bundle for dependencies is the anti-OSGi thing to
> do,
> but that is a whole other debate.
>
>> You don't seem to be using the bundle as a bundle, but rather as a
>> simple, but very big, third party library (i.e. bunch of class files.)
>> Yeah - it's self contained, but doesn't really take advantage of the
>> modular nature of the OSGi infrastructure. However, I don't know the
>> details of the bundles you are talking about and assume there are good
>> reasons for doing it the way you are.
>
> Nowhere did I say that you should do this for every dependency you
> have, but
> only for the ones that it makes sense. For the rest, you let the plugin
> generate Import-Package declarations and it is all automatic.
>
>> But, the case you made seems to only really make sense for poorly
>> designed bundles (as this compendium bundle seems to be - including a
>> logging API that can't be separated from the rest) I'd hope the maven
>> plugin is designed with such a situation as the exception instead of
>> the rule. Either you depend on compendium or you don't. In your case
>> the answer is "Sort of. I drag what I need into my own bundle."
>>
>> I'm trying to target the 80% that are using the plugin like they use
>> all other maven plugins. Via the POM I've expressed what the
>> dependencies are and if I want them in the artifact. That should be
>> enough to get them bundled. I can then fine tune visibility via the
>> plugin's instructions.
>
> If that is your definition of poorly designed, then I guess nearly all
> JAR
> files are poorly designed judging by the amount of stuff that gets
> downloaded
> by Maven for any simple operation. Pulling in 20MB of stuff to compile
> a
> "hello world" program does scream "poor design", but it is not the
> "hello
> world" program that is poorly designed.
>
> Rarely any JAR file is perfectly cohesive and as a result dependencies
> on a
> JAR file are generally going to pull in too much.
>
>
>> As a start, I'd suggest that a <Bundle-ClassPath> instruction is
>> added. You
>> can specify "<none>" (do what it does today), or actual packages/jars.
>> If it
>> isn't specified at all then the dependencies are added to the
>> Bundle-ClassPath manifest entry. Whether or not the .jars are
>> actually
>> packaged in the bundle would be determined by how the dependencies
>> were
>> defined. I'm shooting from the hip here but it could be a start. The
>> interplay with Export-Package and Private-Package would have to be
>> addressed.
>
> Yes, I think we can look into it.
>
> -> richard
>
>>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 4:13 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>> Sorry - thought it was implied. Since this is a maven plugin I'd
>>> want
>>> the process automated (with reasonable overrides.) :)
>>>
>>> Again - like the war-plugin, osgi-plugin (and most other packaging
>>> maving plugins that I am familiar with) jar dependencies (with the
>>> compile scope) are automatically added to the artifact (in this case,
>>> a bundle) as-is and made available to the runtime (in this case added
>>> to Bundle-ClassPath.) Specifying where in the bundle the jars should
>>> go (i.e. META-INF/lib, lib,
>>> etc.) would be a bonus.
>>>
>>
>> I still feel like my question wasn't totally answered. I understand
>> that you
>> want the process automated; we all do, which is why we have a plugin.
>> What I
>> don't understand is whether it is a requirement that you want the JAR
>> file
>> embedded or if inlining of the JAR is acceptable.
>>
>> I am asking this question to get a better understanding of how
>> possibly to
>> devise a solution.
>>
>>> With all due respect, having to specify the <Private-Package/>
>>> instruction to pull in dependencies seems a little goofy and
>>> anti-maven. Via the POM I already specified the dependencies and if
>>> they need to be part of the artifact. Finer-grained visibility
>>> control can then be done via the Export-Package instruction.
>>>
>>
>> If you consider it anti-Maven, then maybe it is, I don't know. Maven
>> doesn't
>> really work exactly like I would like it to.
>>
>> For example, we have a very simple Log Service implementation in
>> Felix.
>> The actually Log Service interface package is in the compendium
>> bundle.
>> This means that the Log Service bundle has a dependency on the
>> compendium
>> bundle. If I follow the "pro-Maven" approach, then to use this very
>> lightweight log service I have to download the fairly large compendium
>> bundle
>> and the servlet bundle, since compendium has a dependency on that.
>>
>> I don't know of any real "pro-Maven" approach for eliminating this
>> situation
>> other than copying the Log Service package source code from the
>> compendium
>> project into my Log Service project. The downside of this approach is
>> that I
>> now have to maintain two copies of the source code.
>>
>> With the maven-bundle-plugin, I can simply include the package I need
>> from
>> the compendium dependency and now I have a completely self-contained,
>> lightweight Log Service bundle.
>>
>> This approach may not suit every purpose, but it definitely comes in
>> handy if
>> you ask me.
>>
>> I can see the other side to the argument too, so we just have to think
>> up a
>> good solution for both, I think.
>>
>> -> richard
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 3:26 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>> RH> You simply indicate which packages you want in your bundle and
>>>> RH> they are
>>>> copied into it.
>>>>
>>>> Huh?! So, if I write a bundle that uses the dom4j API (it is a
>>>> <dependency/> in my bundle's POM) this plugin won't simply bundle
>>>> dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I
>>>> have to know what all of the packages are in dom4j.jar and
>>>> explicitly
>>>> *indicate* that they should be
>>>> *copied* into the bundle so that they are available at runtime? Is
>>>> that correct? I want to make sure I understand this correctly.
>>>>
>>>>
>>>
>>> Yes, you understand. Often the only thing that is required is
>>> something
>>> like:
>>>
>>> <Private-Package>org.dom4j.*</Private-Package>
>>>
>>> But you didn't answer my question, are you interested in having
>>> embedded JAR files (as opposed to inlined JAR files) or interested in
>>> simply automating the above process?
>>>
>>> -> richard
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Tuesday, December 05, 2006 2:45 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Aaron Siri wrote:
>>>>
>>>>
>>>>> Understood. A switch or option would be nice then. My
>>>>> Import-Package property is huge and always looks like a mess.
>>>>>
>>>>>
>>>>>
>>>> If it is calculated, then it shouldn't be something to worry
>>>> about...I am sure the byte code in my class files looks like a mess
>>>> too. ;-)
>>>>
>>>>
>>>>
>>>>> Still wondering about jar dependencies and auto-generation of
>>>>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>>>>> supported this.
>>>>>
>>>>>
>>>>>
>>>> Yes, the new plugin promotes a different approach to creating
>>>> bundles.
>>>> You simply indicate which packages you want in your bundle and they
>>>> are copied into it.
>>>>
>>>> Do you have the need for actually embedding JAR files into your
>>>> bundle or is your desire to simply have some way to automatically
>>>> embedded your dependencies (inlined or as JAR files) into your
>>>> bundle?
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -Aaron
>>>>>
>>>>> -----Original Message-----
>>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>>> Sent: Tuesday, December 05, 2006 2:09 PM
>>>>> To: felix-dev@incubator.apache.org
>>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>>
>>>>> Aaron Siri wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Only dependencies that are of type bundle. Plain old jars would
>>>>>> be
>>>>>> added to the classpath. I guess it doesn't have to be the default
>>>>>> behavior - just possible.
>>>>>>
>>>>>> As a side note. You create bundles that are dependent on other
>>>>>> bundles (to compile, I assume) but then you don't want them to be
>>>>>> required during runtime?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> The issue is Import-Package vs. Require-Bundle. I prefer
>>>>> Import-Package over Require-Bundle for my dependencies.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -Aaron
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>>>>> To: felix-dev@incubator.apache.org
>>>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>>>
>>>>>> Aaron Siri wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I guess I'm expecting it to behave a little more like the
>>>>>>> war-plugin with respect to dependency jars. Any dependency that
>>>>>>> is of type jar and has a scope of something like compile will be
>>>>>>> included in the bundle jar (and on the manifest classpath). For
>>>>>>> that matter, any dependency that is of type bundle I'd expect to
>>>>>>> be included in the manifest
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Required-Bundles property.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Well, I definitely would not want the default handling of
>>>>>> dependencies to be converted to require-bundle...
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -Aaron
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>>>>> To: Aaron Siri
>>>>>>> Cc: felix-dev@incubator.apache.org
>>>>>>> Subject: Re[6]: Bundle plugin: Importing packages from
>>>>>>> non-bundles
>>>>>>>
>>>>>>> Sorry for the previous mail, was not finished yet.
>>>>>>>
>>>>>>> I think it is :
>>>>>>>
>>>>>>> <configuration>
>>>>>>> <instructions>
>>>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>>>> </instructions>
>>>>>>> </configuration>
>>>>>>>
>>>>>>> And not
>>>>>>>
>>>>>>> <configuration>
>>>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>>>> </configuration>
>>>>>>>
>>>>>>> You can always package the bundles as jars, you just have to
>>>>>>> Include them as resources. However, this implies you know where
>>>>>>> to
>>>>>>> find
>>>>>>>
>>> them.
>>>
>>>>>>> Please realize that the plugin was build for the OSGi model where
>>>>>>> you have many small bundles. This implies that not all scenarios
>>>>>>> are targeted with this plugin.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Peter Kriens
>>>>>>>
>>>>>>>
>>>>>>> AS> I was going to start asking similar questions. I'm wondering
>>>>>>> AS> how I get my dependencies packaged in the bundle (I prefer
>>>>>>> AS> them as jars and not inlined.) Does this thread imply that
>>>>>>> AS> there is no way for library jars to be packaged in the bundle
>>>>>>> AS> using
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> maven-bundle-plugin?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>>>>> AS> bundle
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> via:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> AS> <configuration>
>>>>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>>>>> AS> </configuration>
>>>>>>>
>>>>>>> AS> Which doesn't seem to be working. Is this the right way to
>>>>>>> AS> get it
>>>>>>> included?
>>>>>>>
>>>>>>> AS> -Aaron
>>>>>>>
>>>>>>> AS> -----Original Message-----
>>>>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>>>>> AS> To: Peter Kriens
>>>>>>> AS> Cc: felix-dev@incubator.apache.org
>>>>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>>>>> AS> non-bundles
>>>>>>>
>>>>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> AS> Neither am I, but it actually means exclude. From
>>>>>>> AS> http://maven.apache.org/pom.html:
>>>>>>>
>>>>>>> --- >>8 ---
>>>>>>> AS> * scope: This element refers to the classpath of the task at
>>>>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>>>>
>>>>>>>
>>>> available:
>>>>
>>>>
>>>>>>> AS> * compile - this is the default scope, used if none is
>>>>>>>
>>> specified.
>>>
>>>>>>> AS> Compile dependencies are available in all classpaths.
>>>>>>> AS> * provided - this is much like compile, but indicates you
>>>>>>> AS> expect the JDK or a container to provide it. It is only
>>>>>>> AS> available on the compilation classpath, and is not
>>>>>>> transitive.
>>>>>>> AS> * runtime - this scope indicates that the dependency is
>>>>>>> AS> not required for compilation, but is for execution. It is in
>>>>>>> AS> the runtime and test classpaths, but not the compile
>>>>>>> classpath.
>>>>>>> AS> * test - this scope indicates that the dependency is not
>>>>>>> AS> required for normal use of the application, and is only
>>>>>>> AS> available for the test compilation and execution phases.
>>>>>>> AS> * system - this scope is similar to provided except that
>>>>>>> AS> you have to provide the JAR which contains it explicitly. The
>>>>>>> AS> artifact is always available and is not looked up in a
>>>>>>> repository.
>>>>>>> --- >>8 ---
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am
>>>>>>> AS> on
>>>>>>>
>>> OSGi.
>>>
>>>>>>> AS> I just want stuff to work so I can build apps. :) But this is
>>>>>>> AS> an Apache list, I'm sure others can chime in!
>>>>>>>
>>>>>>> AS> What I meant in my previous mail was that I don't understand
>>>>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>>>>> AS> It's an OSGi-aware
>>>>>>> plugin...
>>>>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>>>>> AS> Would work nicely. But maybe there's some Maven core <->
>>>>>>> Maven
>>>>>>> AS> plugin interaction going on there that I'm missing. In either
>>>>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> showstopper for us.
>>>>>
>>>>>
>>>>>
>>>>>>> AS> [snip]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>>>>> AS> original example with my one-class bundle which depended on
>>>>>>>
>>>>>>>
>>>> commons-logging.
>>>>
>>>>
>>>>>>> AS> If the plugin would embed or inline the commons-logging jar
>>>>>>> AS> AND generate Import-Package statements... that would break
>>>>>>> AS> when we load it into the OSGi framework, right? No other
>>>>>>> AS> bundle will export commons-logging stuff and, moreover, even
>>>>>>> AS> if there is I want my bundle to
>>>>>>> use the embedded stuff like I said in my POM.
>>>>>>> AS> This is the core of the issue, as I see it.
>>>>>>>
>>>>>>> AS> Cheers,
>>>>>>>
>>>>>>> AS> -EE
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
"If that is your definition of poorly designed, then I guess nearly all JAR
files are poorly designed judging by the amount of stuff that gets downloaded
by Maven for any simple operation. Pulling in 20MB of stuff to compile a
"hello world" program does scream "poor design", but it is not the "hello
world" program that is poorly designed."
No, it is the pom.xml that is poorly designed.
By poor design I meant that you needed only a little piece of compendium.
Little enough that taking compendium as a whole was wasteful. You shouldn't
have to break apart jars (or bundles) to get the binaries you need. Most
third-party jars DO NOT work like this. If you use anything from apache,
ibm, Eclipse, etc. you usually need the .jar in full (and breaking it apart
to only pull pieces out can even be foolish.)
"Rarely any JAR file is perfectly cohesive and as a result dependencies on a
JAR file are generally going to pull in too much."
I'm not comfortable ripping apart jars that I didn't package and it is bad
form (if you don't like it then complain to the packager.) No one I know
creates jar files by pulling apart other jar files, sticking the classes into
their own jar file along with their own binaries (even if they are more
"self-contained".)
Anyways, Maven has nothing to do with any of this. Maven only pulls what you
need (well - it pulls what you say you need.) If you say your hello world
app depends on all of jakarta then that is what maven will pull down (only
once BTW, everything maven pulls is cached.)
I guess I just don't like how the Export-Package and Private-Package
instructions pull the required code into the bundle by ripping apart other
bundles/jars (honestly, I'm in awe that people find this acceptable.) I'd
rather embed the clean jars (as is, not-unrolled), add them to the
Bundle-Classpath and then build Export-Package off of them. Import-package
can be built off of the dependency bundles (probably what it is doing
already.) <Private-Package> seems unnecessary.
The anti-OSGi statement was a little harsh. I apologize if I offended. OSGi
strikes me as promoting modularity and "self-contained" bundles, to me, seem
to contradict that. But, I'm used to equinox and the eclipse environment
where bundles are very modular.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, December 05, 2006 5:30 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
On Dec 5, 2006, at 5:15 PM, Aaron Siri wrote:
> In your example, if I'm not mistaken, you are taking binaries from one
> bundle and including them in your own bundle (instead of depending on
> the bundle at runtime). Now this seems anti-OSGi :)
Not at all anti-OSGi...the OSGi framework automatically deals with multiple
providers of the same package (in my example the Log Service exports the log
package). The spec used to recommend packaging a bundle with its
interfaces...I am not sure if it still does or not, but it is definitely not
anti-OSGi.
To me, using Require-Bundle for dependencies is the anti-OSGi thing to do,
but that is a whole other debate.
> You don't seem to be using the bundle as a bundle, but rather as a
> simple, but very big, third party library (i.e. bunch of class files.)
> Yeah - it's self contained, but doesn't really take advantage of the
> modular nature of the OSGi infrastructure. However, I don't know the
> details of the bundles you are talking about and assume there are good
> reasons for doing it the way you are.
Nowhere did I say that you should do this for every dependency you have, but
only for the ones that it makes sense. For the rest, you let the plugin
generate Import-Package declarations and it is all automatic.
> But, the case you made seems to only really make sense for poorly
> designed bundles (as this compendium bundle seems to be - including a
> logging API that can't be separated from the rest) I'd hope the maven
> plugin is designed with such a situation as the exception instead of
> the rule. Either you depend on compendium or you don't. In your case
> the answer is "Sort of. I drag what I need into my own bundle."
>
> I'm trying to target the 80% that are using the plugin like they use
> all other maven plugins. Via the POM I've expressed what the
> dependencies are and if I want them in the artifact. That should be
> enough to get them bundled. I can then fine tune visibility via the
> plugin's instructions.
If that is your definition of poorly designed, then I guess nearly all JAR
files are poorly designed judging by the amount of stuff that gets downloaded
by Maven for any simple operation. Pulling in 20MB of stuff to compile a
"hello world" program does scream "poor design", but it is not the "hello
world" program that is poorly designed.
Rarely any JAR file is perfectly cohesive and as a result dependencies on a
JAR file are generally going to pull in too much.
> As a start, I'd suggest that a <Bundle-ClassPath> instruction is
> added. You
> can specify "<none>" (do what it does today), or actual packages/jars.
> If it
> isn't specified at all then the dependencies are added to the
> Bundle-ClassPath manifest entry. Whether or not the .jars are actually
> packaged in the bundle would be determined by how the dependencies were
> defined. I'm shooting from the hip here but it could be a start. The
> interplay with Export-Package and Private-Package would have to be
> addressed.
Yes, I think we can look into it.
-> richard
>
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 4:13 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>> Sorry - thought it was implied. Since this is a maven plugin I'd want
>> the process automated (with reasonable overrides.) :)
>>
>> Again - like the war-plugin, osgi-plugin (and most other packaging
>> maving plugins that I am familiar with) jar dependencies (with the
>> compile scope) are automatically added to the artifact (in this case,
>> a bundle) as-is and made available to the runtime (in this case added
>> to Bundle-ClassPath.) Specifying where in the bundle the jars should
>> go (i.e. META-INF/lib, lib,
>> etc.) would be a bonus.
>>
>
> I still feel like my question wasn't totally answered. I understand
> that you
> want the process automated; we all do, which is why we have a plugin.
> What I
> don't understand is whether it is a requirement that you want the JAR
> file
> embedded or if inlining of the JAR is acceptable.
>
> I am asking this question to get a better understanding of how
> possibly to
> devise a solution.
>
>> With all due respect, having to specify the <Private-Package/>
>> instruction to pull in dependencies seems a little goofy and
>> anti-maven. Via the POM I already specified the dependencies and if
>> they need to be part of the artifact. Finer-grained visibility
>> control can then be done via the Export-Package instruction.
>>
>
> If you consider it anti-Maven, then maybe it is, I don't know. Maven
> doesn't
> really work exactly like I would like it to.
>
> For example, we have a very simple Log Service implementation in Felix.
> The actually Log Service interface package is in the compendium bundle.
> This means that the Log Service bundle has a dependency on the
> compendium
> bundle. If I follow the "pro-Maven" approach, then to use this very
> lightweight log service I have to download the fairly large compendium
> bundle
> and the servlet bundle, since compendium has a dependency on that.
>
> I don't know of any real "pro-Maven" approach for eliminating this
> situation
> other than copying the Log Service package source code from the
> compendium
> project into my Log Service project. The downside of this approach is
> that I
> now have to maintain two copies of the source code.
>
> With the maven-bundle-plugin, I can simply include the package I need
> from
> the compendium dependency and now I have a completely self-contained,
> lightweight Log Service bundle.
>
> This approach may not suit every purpose, but it definitely comes in
> handy if
> you ask me.
>
> I can see the other side to the argument too, so we just have to think
> up a
> good solution for both, I think.
>
> -> richard
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 3:26 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>> RH> You simply indicate which packages you want in your bundle and
>>> RH> they are
>>> copied into it.
>>>
>>> Huh?! So, if I write a bundle that uses the dom4j API (it is a
>>> <dependency/> in my bundle's POM) this plugin won't simply bundle
>>> dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I
>>> have to know what all of the packages are in dom4j.jar and explicitly
>>> *indicate* that they should be
>>> *copied* into the bundle so that they are available at runtime? Is
>>> that correct? I want to make sure I understand this correctly.
>>>
>>>
>>
>> Yes, you understand. Often the only thing that is required is
>> something
>> like:
>>
>> <Private-Package>org.dom4j.*</Private-Package>
>>
>> But you didn't answer my question, are you interested in having
>> embedded JAR files (as opposed to inlined JAR files) or interested in
>> simply automating the above process?
>>
>> -> richard
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 2:45 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>> Understood. A switch or option would be nice then. My
>>>> Import-Package property is huge and always looks like a mess.
>>>>
>>>>
>>>>
>>> If it is calculated, then it shouldn't be something to worry
>>> about...I am sure the byte code in my class files looks like a mess
>>> too. ;-)
>>>
>>>
>>>
>>>> Still wondering about jar dependencies and auto-generation of
>>>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>>>> supported this.
>>>>
>>>>
>>>>
>>> Yes, the new plugin promotes a different approach to creating
>>> bundles.
>>> You simply indicate which packages you want in your bundle and they
>>> are copied into it.
>>>
>>> Do you have the need for actually embedding JAR files into your
>>> bundle or is your desire to simply have some way to automatically
>>> embedded your dependencies (inlined or as JAR files) into your
>>> bundle?
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Tuesday, December 05, 2006 2:09 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Aaron Siri wrote:
>>>>
>>>>
>>>>
>>>>> Only dependencies that are of type bundle. Plain old jars would be
>>>>> added to the classpath. I guess it doesn't have to be the default
>>>>> behavior - just possible.
>>>>>
>>>>> As a side note. You create bundles that are dependent on other
>>>>> bundles (to compile, I assume) but then you don't want them to be
>>>>> required during runtime?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> The issue is Import-Package vs. Require-Bundle. I prefer
>>>> Import-Package over Require-Bundle for my dependencies.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>> -Aaron
>>>>>
>>>>> -----Original Message-----
>>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>>>> To: felix-dev@incubator.apache.org
>>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>>
>>>>> Aaron Siri wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I guess I'm expecting it to behave a little more like the
>>>>>> war-plugin with respect to dependency jars. Any dependency that
>>>>>> is of type jar and has a scope of something like compile will be
>>>>>> included in the bundle jar (and on the manifest classpath). For
>>>>>> that matter, any dependency that is of type bundle I'd expect to
>>>>>> be included in the manifest
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Required-Bundles property.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Well, I definitely would not want the default handling of
>>>>> dependencies to be converted to require-bundle...
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -Aaron
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>>>> To: Aaron Siri
>>>>>> Cc: felix-dev@incubator.apache.org
>>>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>>>
>>>>>> Sorry for the previous mail, was not finished yet.
>>>>>>
>>>>>> I think it is :
>>>>>>
>>>>>> <configuration>
>>>>>> <instructions>
>>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>>> </instructions>
>>>>>> </configuration>
>>>>>>
>>>>>> And not
>>>>>>
>>>>>> <configuration>
>>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>>> </configuration>
>>>>>>
>>>>>> You can always package the bundles as jars, you just have to
>>>>>> Include them as resources. However, this implies you know where to
>>>>>> find
>>>>>>
>> them.
>>
>>>>>> Please realize that the plugin was build for the OSGi model where
>>>>>> you have many small bundles. This implies that not all scenarios
>>>>>> are targeted with this plugin.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Peter Kriens
>>>>>>
>>>>>>
>>>>>> AS> I was going to start asking similar questions. I'm wondering
>>>>>> AS> how I get my dependencies packaged in the bundle (I prefer
>>>>>> AS> them as jars and not inlined.) Does this thread imply that
>>>>>> AS> there is no way for library jars to be packaged in the bundle
>>>>>> AS> using
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> maven-bundle-plugin?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>>>> AS> bundle
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> via:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> AS> <configuration>
>>>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>>>> AS> </configuration>
>>>>>>
>>>>>> AS> Which doesn't seem to be working. Is this the right way to
>>>>>> AS> get it
>>>>>> included?
>>>>>>
>>>>>> AS> -Aaron
>>>>>>
>>>>>> AS> -----Original Message-----
>>>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>>>> AS> To: Peter Kriens
>>>>>> AS> Cc: felix-dev@incubator.apache.org
>>>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>>>> AS> non-bundles
>>>>>>
>>>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Neither am I, but it actually means exclude. From
>>>>>> AS> http://maven.apache.org/pom.html:
>>>>>>
>>>>>> --- >>8 ---
>>>>>> AS> * scope: This element refers to the classpath of the task at
>>>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>>>
>>>>>>
>>> available:
>>>
>>>
>>>>>> AS> * compile - this is the default scope, used if none is
>>>>>>
>> specified.
>>
>>>>>> AS> Compile dependencies are available in all classpaths.
>>>>>> AS> * provided - this is much like compile, but indicates you
>>>>>> AS> expect the JDK or a container to provide it. It is only
>>>>>> AS> available on the compilation classpath, and is not transitive.
>>>>>> AS> * runtime - this scope indicates that the dependency is
>>>>>> AS> not required for compilation, but is for execution. It is in
>>>>>> AS> the runtime and test classpaths, but not the compile
>>>>>> classpath.
>>>>>> AS> * test - this scope indicates that the dependency is not
>>>>>> AS> required for normal use of the application, and is only
>>>>>> AS> available for the test compilation and execution phases.
>>>>>> AS> * system - this scope is similar to provided except that
>>>>>> AS> you have to provide the JAR which contains it explicitly. The
>>>>>> AS> artifact is always available and is not looked up in a
>>>>>> repository.
>>>>>> --- >>8 ---
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am
>>>>>> AS> on
>>>>>>
>> OSGi.
>>
>>>>>> AS> I just want stuff to work so I can build apps. :) But this is
>>>>>> AS> an Apache list, I'm sure others can chime in!
>>>>>>
>>>>>> AS> What I meant in my previous mail was that I don't understand
>>>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>>>> AS> It's an OSGi-aware
>>>>>> plugin...
>>>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>>>>> AS> plugin interaction going on there that I'm missing. In either
>>>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>>>
>>>>>>
>>>>>>
>>>> showstopper for us.
>>>>
>>>>
>>>>
>>>>>> AS> [snip]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>>>> AS> original example with my one-class bundle which depended on
>>>>>>
>>>>>>
>>> commons-logging.
>>>
>>>
>>>>>> AS> If the plugin would embed or inline the commons-logging jar
>>>>>> AS> AND generate Import-Package statements... that would break
>>>>>> AS> when we load it into the OSGi framework, right? No other
>>>>>> AS> bundle will export commons-logging stuff and, moreover, even
>>>>>> AS> if there is I want my bundle to
>>>>>> use the embedded stuff like I said in my POM.
>>>>>> AS> This is the core of the issue, as I see it.
>>>>>>
>>>>>> AS> Cheers,
>>>>>>
>>>>>> AS> -EE
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 5:15 PM, Aaron Siri wrote:
> In your example, if I'm not mistaken, you are taking binaries from one
> bundle
> and including them in your own bundle (instead of depending on the
> bundle at
> runtime). Now this seems anti-OSGi :)
Not at all anti-OSGi...the OSGi framework automatically deals with
multiple providers of the same package (in my example the Log Service
exports the log package). The spec used to recommend packaging a bundle
with its interfaces...I am not sure if it still does or not, but it is
definitely not anti-OSGi.
To me, using Require-Bundle for dependencies is the anti-OSGi thing to
do, but that is a whole other debate.
> You don't seem to be using the bundle as a bundle, but rather as a
> simple,
> but very big, third party library (i.e. bunch of class files.) Yeah -
> it's
> self contained, but doesn't really take advantage of the modular
> nature of
> the OSGi infrastructure. However, I don't know the details of the
> bundles
> you are talking about and assume there are good reasons for doing it
> the way
> you are.
Nowhere did I say that you should do this for every dependency you
have, but only for the ones that it makes sense. For the rest, you let
the plugin generate Import-Package declarations and it is all
automatic.
> But, the case you made seems to only really make sense for poorly
> designed
> bundles (as this compendium bundle seems to be - including a logging
> API that
> can't be separated from the rest) I'd hope the maven plugin is
> designed with
> such a situation as the exception instead of the rule. Either you
> depend on
> compendium or you don't. In your case the answer is "Sort of. I drag
> what I
> need into my own bundle."
>
> I'm trying to target the 80% that are using the plugin like they use
> all
> other maven plugins. Via the POM I've expressed what the dependencies
> are
> and if I want them in the artifact. That should be enough to get them
> bundled. I can then fine tune visibility via the plugin's
> instructions.
If that is your definition of poorly designed, then I guess nearly all
JAR files are poorly designed judging by the amount of stuff that gets
downloaded by Maven for any simple operation. Pulling in 20MB of stuff
to compile a "hello world" program does scream "poor design", but it is
not the "hello world" program that is poorly designed.
Rarely any JAR file is perfectly cohesive and as a result dependencies
on a JAR file are generally going to pull in too much.
> As a start, I'd suggest that a <Bundle-ClassPath> instruction is
> added. You
> can specify "<none>" (do what it does today), or actual packages/jars.
> If it
> isn't specified at all then the dependencies are added to the
> Bundle-ClassPath manifest entry. Whether or not the .jars are actually
> packaged in the bundle would be determined by how the dependencies were
> defined. I'm shooting from the hip here but it could be a start. The
> interplay with Export-Package and Private-Package would have to be
> addressed.
Yes, I think we can look into it.
-> richard
>
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 4:13 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>> Sorry - thought it was implied. Since this is a maven plugin I'd want
>> the process automated (with reasonable overrides.) :)
>>
>> Again - like the war-plugin, osgi-plugin (and most other packaging
>> maving plugins that I am familiar with) jar dependencies (with the
>> compile scope) are automatically added to the artifact (in this case,
>> a bundle) as-is and made available to the runtime (in this case added
>> to Bundle-ClassPath.) Specifying where in the bundle the jars should
>> go (i.e. META-INF/lib, lib,
>> etc.) would be a bonus.
>>
>
> I still feel like my question wasn't totally answered. I understand
> that you
> want the process automated; we all do, which is why we have a plugin.
> What I
> don't understand is whether it is a requirement that you want the JAR
> file
> embedded or if inlining of the JAR is acceptable.
>
> I am asking this question to get a better understanding of how
> possibly to
> devise a solution.
>
>> With all due respect, having to specify the <Private-Package/>
>> instruction to pull in dependencies seems a little goofy and
>> anti-maven. Via the POM I already specified the dependencies and if
>> they need to be part of the artifact. Finer-grained visibility
>> control can then be done via the Export-Package instruction.
>>
>
> If you consider it anti-Maven, then maybe it is, I don't know. Maven
> doesn't
> really work exactly like I would like it to.
>
> For example, we have a very simple Log Service implementation in Felix.
> The actually Log Service interface package is in the compendium bundle.
> This means that the Log Service bundle has a dependency on the
> compendium
> bundle. If I follow the "pro-Maven" approach, then to use this very
> lightweight log service I have to download the fairly large compendium
> bundle
> and the servlet bundle, since compendium has a dependency on that.
>
> I don't know of any real "pro-Maven" approach for eliminating this
> situation
> other than copying the Log Service package source code from the
> compendium
> project into my Log Service project. The downside of this approach is
> that I
> now have to maintain two copies of the source code.
>
> With the maven-bundle-plugin, I can simply include the package I need
> from
> the compendium dependency and now I have a completely self-contained,
> lightweight Log Service bundle.
>
> This approach may not suit every purpose, but it definitely comes in
> handy if
> you ask me.
>
> I can see the other side to the argument too, so we just have to think
> up a
> good solution for both, I think.
>
> -> richard
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 3:26 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>> RH> You simply indicate which packages you want in your bundle and
>>> RH> they are
>>> copied into it.
>>>
>>> Huh?! So, if I write a bundle that uses the dom4j API (it is a
>>> <dependency/> in my bundle's POM) this plugin won't simply bundle
>>> dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I
>>> have to know what all of the packages are in dom4j.jar and explicitly
>>> *indicate* that they should be
>>> *copied* into the bundle so that they are available at runtime? Is
>>> that correct? I want to make sure I understand this correctly.
>>>
>>>
>>
>> Yes, you understand. Often the only thing that is required is
>> something
>> like:
>>
>> <Private-Package>org.dom4j.*</Private-Package>
>>
>> But you didn't answer my question, are you interested in having
>> embedded JAR files (as opposed to inlined JAR files) or interested in
>> simply automating the above process?
>>
>> -> richard
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 2:45 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>> Understood. A switch or option would be nice then. My
>>>> Import-Package property is huge and always looks like a mess.
>>>>
>>>>
>>>>
>>> If it is calculated, then it shouldn't be something to worry
>>> about...I am sure the byte code in my class files looks like a mess
>>> too. ;-)
>>>
>>>
>>>
>>>> Still wondering about jar dependencies and auto-generation of
>>>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>>>> supported this.
>>>>
>>>>
>>>>
>>> Yes, the new plugin promotes a different approach to creating
>>> bundles.
>>> You simply indicate which packages you want in your bundle and they
>>> are copied into it.
>>>
>>> Do you have the need for actually embedding JAR files into your
>>> bundle or is your desire to simply have some way to automatically
>>> embedded your dependencies (inlined or as JAR files) into your
>>> bundle?
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Tuesday, December 05, 2006 2:09 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Aaron Siri wrote:
>>>>
>>>>
>>>>
>>>>> Only dependencies that are of type bundle. Plain old jars would be
>>>>> added to the classpath. I guess it doesn't have to be the default
>>>>> behavior - just possible.
>>>>>
>>>>> As a side note. You create bundles that are dependent on other
>>>>> bundles (to compile, I assume) but then you don't want them to be
>>>>> required during runtime?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> The issue is Import-Package vs. Require-Bundle. I prefer
>>>> Import-Package over Require-Bundle for my dependencies.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>> -Aaron
>>>>>
>>>>> -----Original Message-----
>>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>>>> To: felix-dev@incubator.apache.org
>>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>>
>>>>> Aaron Siri wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I guess I'm expecting it to behave a little more like the
>>>>>> war-plugin with respect to dependency jars. Any dependency that
>>>>>> is of type jar and has a scope of something like compile will be
>>>>>> included in the bundle jar (and on the manifest classpath). For
>>>>>> that matter, any dependency that is of type bundle I'd expect to
>>>>>> be included in the manifest
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Required-Bundles property.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Well, I definitely would not want the default handling of
>>>>> dependencies to be converted to require-bundle...
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -Aaron
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>>>> To: Aaron Siri
>>>>>> Cc: felix-dev@incubator.apache.org
>>>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>>>
>>>>>> Sorry for the previous mail, was not finished yet.
>>>>>>
>>>>>> I think it is :
>>>>>>
>>>>>> <configuration>
>>>>>> <instructions>
>>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>>> </instructions>
>>>>>> </configuration>
>>>>>>
>>>>>> And not
>>>>>>
>>>>>> <configuration>
>>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>>> </configuration>
>>>>>>
>>>>>> You can always package the bundles as jars, you just have to
>>>>>> Include them as resources. However, this implies you know where to
>>>>>> find
>>>>>>
>> them.
>>
>>>>>> Please realize that the plugin was build for the OSGi model where
>>>>>> you have many small bundles. This implies that not all scenarios
>>>>>> are targeted with this plugin.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Peter Kriens
>>>>>>
>>>>>>
>>>>>> AS> I was going to start asking similar questions. I'm wondering
>>>>>> AS> how I get my dependencies packaged in the bundle (I prefer
>>>>>> AS> them as jars and not inlined.) Does this thread imply that
>>>>>> AS> there is no way for library jars to be packaged in the bundle
>>>>>> AS> using
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> maven-bundle-plugin?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>>>> AS> bundle
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> via:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> AS> <configuration>
>>>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>>>> AS> </configuration>
>>>>>>
>>>>>> AS> Which doesn't seem to be working. Is this the right way to
>>>>>> AS> get it
>>>>>> included?
>>>>>>
>>>>>> AS> -Aaron
>>>>>>
>>>>>> AS> -----Original Message-----
>>>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>>>> AS> To: Peter Kriens
>>>>>> AS> Cc: felix-dev@incubator.apache.org
>>>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>>>> AS> non-bundles
>>>>>>
>>>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Neither am I, but it actually means exclude. From
>>>>>> AS> http://maven.apache.org/pom.html:
>>>>>>
>>>>>> --- >>8 ---
>>>>>> AS> * scope: This element refers to the classpath of the task at
>>>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>>>
>>>>>>
>>> available:
>>>
>>>
>>>>>> AS> * compile - this is the default scope, used if none is
>>>>>>
>> specified.
>>
>>>>>> AS> Compile dependencies are available in all classpaths.
>>>>>> AS> * provided - this is much like compile, but indicates you
>>>>>> AS> expect the JDK or a container to provide it. It is only
>>>>>> AS> available on the compilation classpath, and is not transitive.
>>>>>> AS> * runtime - this scope indicates that the dependency is
>>>>>> AS> not required for compilation, but is for execution. It is in
>>>>>> AS> the runtime and test classpaths, but not the compile
>>>>>> classpath.
>>>>>> AS> * test - this scope indicates that the dependency is not
>>>>>> AS> required for normal use of the application, and is only
>>>>>> AS> available for the test compilation and execution phases.
>>>>>> AS> * system - this scope is similar to provided except that
>>>>>> AS> you have to provide the JAR which contains it explicitly. The
>>>>>> AS> artifact is always available and is not looked up in a
>>>>>> repository.
>>>>>> --- >>8 ---
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am
>>>>>> AS> on
>>>>>>
>> OSGi.
>>
>>>>>> AS> I just want stuff to work so I can build apps. :) But this is
>>>>>> AS> an Apache list, I'm sure others can chime in!
>>>>>>
>>>>>> AS> What I meant in my previous mail was that I don't understand
>>>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>>>> AS> It's an OSGi-aware
>>>>>> plugin...
>>>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>>>>> AS> plugin interaction going on there that I'm missing. In either
>>>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>>>
>>>>>>
>>>>>>
>>>> showstopper for us.
>>>>
>>>>
>>>>
>>>>>> AS> [snip]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>>>> AS> original example with my one-class bundle which depended on
>>>>>>
>>>>>>
>>> commons-logging.
>>>
>>>
>>>>>> AS> If the plugin would embed or inline the commons-logging jar
>>>>>> AS> AND generate Import-Package statements... that would break
>>>>>> AS> when we load it into the OSGi framework, right? No other
>>>>>> AS> bundle will export commons-logging stuff and, moreover, even
>>>>>> AS> if there is I want my bundle to
>>>>>> use the embedded stuff like I said in my POM.
>>>>>> AS> This is the core of the issue, as I see it.
>>>>>>
>>>>>> AS> Cheers,
>>>>>>
>>>>>> AS> -EE
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 5:47 PM, Steven E. Harris wrote:
> I brought up this point -- somewhat by accident -- just a few days
> ago, and the work I'm interrupting to type this once again has me
> considering whether it's worth it to rely upon the compendium
> bundle. In my case, I just wanted the org.osgi.util.tracker package,
> which consists of two files. But using the compendium bundle as it's
> intended has me also dragging in some servlet-related bundle -- and my
> application does nothing related to servlets.
>
> Is the compendium bundle's content specified by OSGi, or is this a
> Felix-specific combination of things? That is, would it still be
> possible to cut up the compendium bundle into smaller pieces without
> violating any OSGi specifications?
Yes, we can cut it up, but the reason the osgi.core and osgi.compendium
JARs are the way they are is to replicate the standard JAR files that
the OSGi Alliance makes available.
If you want to cut them up and you use the maven-bundle-plugin, you
don't need to do anything other than create a new pom file for a bundle
that depends on the compendium and grabs the packages you want to cut
out.
Any time you "cut out" a piece of another bundle/JA it implies that you
have some knowledge about what you are doing. If you don't know what
you are doing then you should just let the plugin generate
Import-Package statements. If you know what you are doing, then you can
cut it up. It doesn't really make a difference whether this cutting
happens on the source version or the binary version.
The main point is that the maven-bundle-plugin gives you another option
of dealing with less than perfectly cohesive dependencies, by allowing
you to grab what you need when it makes sense.
There is no requirement that forces anyone to cut up and copy pieces of
their dependencies; however, I admit that it could be easier for those
whom want to embed their dependencies wholesale, so maybe that can be
improved.
-> richard
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Steven E. Harris" <se...@panix.com>.
Aaron Siri <Aa...@efi.com> writes:
> But, the case you made seems to only really make sense for poorly
> designed bundles (as this compendium bundle seems to be - including
> a logging API that can't be separated from the rest) I'd hope the
> maven plugin is designed with such a situation as the exception
> instead of the rule. Either you depend on compendium or you don't.
> In your case the answer is "Sort of. I drag what I need into my own
> bundle."
I brought up this point -- somewhat by accident -- just a few days
ago, and the work I'm interrupting to type this once again has me
considering whether it's worth it to rely upon the compendium
bundle. In my case, I just wanted the org.osgi.util.tracker package,
which consists of two files. But using the compendium bundle as it's
intended has me also dragging in some servlet-related bundle -- and my
application does nothing related to servlets.
Is the compendium bundle's content specified by OSGi, or is this a
Felix-specific combination of things? That is, would it still be
possible to cut up the compendium bundle into smaller pieces without
violating any OSGi specifications?
--
Steven E. Harris
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
"...jar dependencies (with the compile scope) are automatically added to the
artifact (in this case, a bundle) as-is...". As-is, a bunch of .jar files in
a directory of my choosing, no inlining (can be optional.) I, personally,
don't want the innards of third-party jars all over my bundle. :)
I appreciate you wanting to make the plugin better. Also, just to be clear -
I'm coming from an equinox environment.
In your example, if I'm not mistaken, you are taking binaries from one bundle
and including them in your own bundle (instead of depending on the bundle at
runtime). Now this seems anti-OSGi :)
You don't seem to be using the bundle as a bundle, but rather as a simple,
but very big, third party library (i.e. bunch of class files.) Yeah - it's
self contained, but doesn't really take advantage of the modular nature of
the OSGi infrastructure. However, I don't know the details of the bundles
you are talking about and assume there are good reasons for doing it the way
you are.
But, the case you made seems to only really make sense for poorly designed
bundles (as this compendium bundle seems to be - including a logging API that
can't be separated from the rest) I'd hope the maven plugin is designed with
such a situation as the exception instead of the rule. Either you depend on
compendium or you don't. In your case the answer is "Sort of. I drag what I
need into my own bundle."
I'm trying to target the 80% that are using the plugin like they use all
other maven plugins. Via the POM I've expressed what the dependencies are
and if I want them in the artifact. That should be enough to get them
bundled. I can then fine tune visibility via the plugin's instructions.
As a start, I'd suggest that a <Bundle-ClassPath> instruction is added. You
can specify "<none>" (do what it does today), or actual packages/jars. If it
isn't specified at all then the dependencies are added to the
Bundle-ClassPath manifest entry. Whether or not the .jars are actually
packaged in the bundle would be determined by how the dependencies were
defined. I'm shooting from the hip here but it could be a start. The
interplay with Export-Package and Private-Package would have to be addressed.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, December 05, 2006 4:13 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
> Sorry - thought it was implied. Since this is a maven plugin I'd want
> the process automated (with reasonable overrides.) :)
>
> Again - like the war-plugin, osgi-plugin (and most other packaging
> maving plugins that I am familiar with) jar dependencies (with the
> compile scope) are automatically added to the artifact (in this case,
> a bundle) as-is and made available to the runtime (in this case added
> to Bundle-ClassPath.) Specifying where in the bundle the jars should
> go (i.e. META-INF/lib, lib,
> etc.) would be a bonus.
>
I still feel like my question wasn't totally answered. I understand that you
want the process automated; we all do, which is why we have a plugin. What I
don't understand is whether it is a requirement that you want the JAR file
embedded or if inlining of the JAR is acceptable.
I am asking this question to get a better understanding of how possibly to
devise a solution.
> With all due respect, having to specify the <Private-Package/>
> instruction to pull in dependencies seems a little goofy and
> anti-maven. Via the POM I already specified the dependencies and if
> they need to be part of the artifact. Finer-grained visibility
> control can then be done via the Export-Package instruction.
>
If you consider it anti-Maven, then maybe it is, I don't know. Maven doesn't
really work exactly like I would like it to.
For example, we have a very simple Log Service implementation in Felix.
The actually Log Service interface package is in the compendium bundle.
This means that the Log Service bundle has a dependency on the compendium
bundle. If I follow the "pro-Maven" approach, then to use this very
lightweight log service I have to download the fairly large compendium bundle
and the servlet bundle, since compendium has a dependency on that.
I don't know of any real "pro-Maven" approach for eliminating this situation
other than copying the Log Service package source code from the compendium
project into my Log Service project. The downside of this approach is that I
now have to maintain two copies of the source code.
With the maven-bundle-plugin, I can simply include the package I need from
the compendium dependency and now I have a completely self-contained,
lightweight Log Service bundle.
This approach may not suit every purpose, but it definitely comes in handy if
you ask me.
I can see the other side to the argument too, so we just have to think up a
good solution for both, I think.
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 3:26 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> RH> You simply indicate which packages you want in your bundle and
>> RH> they are
>> copied into it.
>>
>> Huh?! So, if I write a bundle that uses the dom4j API (it is a
>> <dependency/> in my bundle's POM) this plugin won't simply bundle
>> dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I
>> have to know what all of the packages are in dom4j.jar and explicitly
>> *indicate* that they should be
>> *copied* into the bundle so that they are available at runtime? Is
>> that correct? I want to make sure I understand this correctly.
>>
>>
>
> Yes, you understand. Often the only thing that is required is
> something
> like:
>
> <Private-Package>org.dom4j.*</Private-Package>
>
> But you didn't answer my question, are you interested in having
> embedded JAR files (as opposed to inlined JAR files) or interested in
> simply automating the above process?
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 2:45 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>
>>> Understood. A switch or option would be nice then. My
>>> Import-Package property is huge and always looks like a mess.
>>>
>>>
>>>
>> If it is calculated, then it shouldn't be something to worry
>> about...I am sure the byte code in my class files looks like a mess
>> too. ;-)
>>
>>
>>
>>> Still wondering about jar dependencies and auto-generation of
>>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>>> supported this.
>>>
>>>
>>>
>> Yes, the new plugin promotes a different approach to creating bundles.
>> You simply indicate which packages you want in your bundle and they
>> are copied into it.
>>
>> Do you have the need for actually embedding JAR files into your
>> bundle or is your desire to simply have some way to automatically
>> embedded your dependencies (inlined or as JAR files) into your bundle?
>>
>> -> richard
>>
>>
>>
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 2:09 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>
>>>> Only dependencies that are of type bundle. Plain old jars would be
>>>> added to the classpath. I guess it doesn't have to be the default
>>>> behavior - just possible.
>>>>
>>>> As a side note. You create bundles that are dependent on other
>>>> bundles (to compile, I assume) but then you don't want them to be
>>>> required during runtime?
>>>>
>>>>
>>>>
>>>>
>>> The issue is Import-Package vs. Require-Bundle. I prefer
>>> Import-Package over Require-Bundle for my dependencies.
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Aaron Siri wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> I guess I'm expecting it to behave a little more like the
>>>>> war-plugin with respect to dependency jars. Any dependency that
>>>>> is of type jar and has a scope of something like compile will be
>>>>> included in the bundle jar (and on the manifest classpath). For
>>>>> that matter, any dependency that is of type bundle I'd expect to
>>>>> be included in the manifest
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Required-Bundles property.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Well, I definitely would not want the default handling of
>>>> dependencies to be converted to require-bundle...
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -Aaron
>>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>>> To: Aaron Siri
>>>>> Cc: felix-dev@incubator.apache.org
>>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>>
>>>>> Sorry for the previous mail, was not finished yet.
>>>>>
>>>>> I think it is :
>>>>>
>>>>> <configuration>
>>>>> <instructions>
>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>> </instructions>
>>>>> </configuration>
>>>>>
>>>>> And not
>>>>>
>>>>> <configuration>
>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>> </configuration>
>>>>>
>>>>> You can always package the bundles as jars, you just have to
>>>>> Include them as resources. However, this implies you know where to
>>>>> find
>>>>>
> them.
>
>>>>> Please realize that the plugin was build for the OSGi model where
>>>>> you have many small bundles. This implies that not all scenarios
>>>>> are targeted with this plugin.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Peter Kriens
>>>>>
>>>>>
>>>>> AS> I was going to start asking similar questions. I'm wondering
>>>>> AS> how I get my dependencies packaged in the bundle (I prefer
>>>>> AS> them as jars and not inlined.) Does this thread imply that
>>>>> AS> there is no way for library jars to be packaged in the bundle
>>>>> AS> using
>>>>>
>>>>>
>>>>>
>>>>>
>>>> maven-bundle-plugin?
>>>>
>>>>
>>>>
>>>>
>>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>>> AS> bundle
>>>>>
>>>>>
>>>>>
>>>>>
>>>> via:
>>>>
>>>>
>>>>
>>>>
>>>>> AS> <configuration>
>>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>>> AS> </configuration>
>>>>>
>>>>> AS> Which doesn't seem to be working. Is this the right way to
>>>>> AS> get it
>>>>> included?
>>>>>
>>>>> AS> -Aaron
>>>>>
>>>>> AS> -----Original Message-----
>>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>>> AS> To: Peter Kriens
>>>>> AS> Cc: felix-dev@incubator.apache.org
>>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>>> AS> non-bundles
>>>>>
>>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> AS> Neither am I, but it actually means exclude. From
>>>>> AS> http://maven.apache.org/pom.html:
>>>>>
>>>>> --- >>8 ---
>>>>> AS> * scope: This element refers to the classpath of the task at
>>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>>
>>>>>
>> available:
>>
>>
>>>>> AS> * compile - this is the default scope, used if none is
>>>>>
> specified.
>
>>>>> AS> Compile dependencies are available in all classpaths.
>>>>> AS> * provided - this is much like compile, but indicates you
>>>>> AS> expect the JDK or a container to provide it. It is only
>>>>> AS> available on the compilation classpath, and is not transitive.
>>>>> AS> * runtime - this scope indicates that the dependency is
>>>>> AS> not required for compilation, but is for execution. It is in
>>>>> AS> the runtime and test classpaths, but not the compile classpath.
>>>>> AS> * test - this scope indicates that the dependency is not
>>>>> AS> required for normal use of the application, and is only
>>>>> AS> available for the test compilation and execution phases.
>>>>> AS> * system - this scope is similar to provided except that
>>>>> AS> you have to provide the JAR which contains it explicitly. The
>>>>> AS> artifact is always available and is not looked up in a repository.
>>>>> --- >>8 ---
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am
>>>>> AS> on
>>>>>
> OSGi.
>
>>>>> AS> I just want stuff to work so I can build apps. :) But this is
>>>>> AS> an Apache list, I'm sure others can chime in!
>>>>>
>>>>> AS> What I meant in my previous mail was that I don't understand
>>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>>> AS> It's an OSGi-aware
>>>>> plugin...
>>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>>>> AS> plugin interaction going on there that I'm missing. In either
>>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>>
>>>>>
>>>>>
>>> showstopper for us.
>>>
>>>
>>>
>>>>> AS> [snip]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>>> AS> original example with my one-class bundle which depended on
>>>>>
>>>>>
>> commons-logging.
>>
>>
>>>>> AS> If the plugin would embed or inline the commons-logging jar
>>>>> AS> AND generate Import-Package statements... that would break
>>>>> AS> when we load it into the OSGi framework, right? No other
>>>>> AS> bundle will export commons-logging stuff and, moreover, even
>>>>> AS> if there is I want my bundle to
>>>>> use the embedded stuff like I said in my POM.
>>>>> AS> This is the core of the issue, as I see it.
>>>>>
>>>>> AS> Cheers,
>>>>>
>>>>> AS> -EE
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> Sorry - thought it was implied. Since this is a maven plugin I'd want the
> process automated (with reasonable overrides.) :)
>
> Again - like the war-plugin, osgi-plugin (and most other packaging maving
> plugins that I am familiar with) jar dependencies (with the compile scope)
> are automatically added to the artifact (in this case, a bundle) as-is and
> made available to the runtime (in this case added to Bundle-ClassPath.)
> Specifying where in the bundle the jars should go (i.e. META-INF/lib, lib,
> etc.) would be a bonus.
>
I still feel like my question wasn't totally answered. I understand that
you want the process automated; we all do, which is why we have a
plugin. What I don't understand is whether it is a requirement that you
want the JAR file embedded or if inlining of the JAR is acceptable.
I am asking this question to get a better understanding of how possibly
to devise a solution.
> With all due respect, having to specify the <Private-Package/> instruction to
> pull in dependencies seems a little goofy and anti-maven. Via the POM I
> already specified the dependencies and if they need to be part of the
> artifact. Finer-grained visibility control can then be done via the
> Export-Package instruction.
>
If you consider it anti-Maven, then maybe it is, I don't know. Maven
doesn't really work exactly like I would like it to.
For example, we have a very simple Log Service implementation in Felix.
The actually Log Service interface package is in the compendium bundle.
This means that the Log Service bundle has a dependency on the
compendium bundle. If I follow the "pro-Maven" approach, then to use
this very lightweight log service I have to download the fairly large
compendium bundle and the servlet bundle, since compendium has a
dependency on that.
I don't know of any real "pro-Maven" approach for eliminating this
situation other than copying the Log Service package source code from
the compendium project into my Log Service project. The downside of this
approach is that I now have to maintain two copies of the source code.
With the maven-bundle-plugin, I can simply include the package I need
from the compendium dependency and now I have a completely
self-contained, lightweight Log Service bundle.
This approach may not suit every purpose, but it definitely comes in
handy if you ask me.
I can see the other side to the argument too, so we just have to think
up a good solution for both, I think.
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 3:26 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> RH> You simply indicate which packages you want in your bundle and
>> RH> they are
>> copied into it.
>>
>> Huh?! So, if I write a bundle that uses the dom4j API (it is a
>> <dependency/> in my bundle's POM) this plugin won't simply bundle
>> dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I
>> have to know what all of the packages are in dom4j.jar and explicitly
>> *indicate* that they should be
>> *copied* into the bundle so that they are available at runtime? Is
>> that correct? I want to make sure I understand this correctly.
>>
>>
>
> Yes, you understand. Often the only thing that is required is something
> like:
>
> <Private-Package>org.dom4j.*</Private-Package>
>
> But you didn't answer my question, are you interested in having embedded JAR
> files (as opposed to inlined JAR files) or interested in simply automating
> the above process?
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 2:45 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>
>>> Understood. A switch or option would be nice then. My
>>> Import-Package property is huge and always looks like a mess.
>>>
>>>
>>>
>> If it is calculated, then it shouldn't be something to worry about...I
>> am sure the byte code in my class files looks like a mess too. ;-)
>>
>>
>>
>>> Still wondering about jar dependencies and auto-generation of
>>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>>> supported this.
>>>
>>>
>>>
>> Yes, the new plugin promotes a different approach to creating bundles.
>> You simply indicate which packages you want in your bundle and they
>> are copied into it.
>>
>> Do you have the need for actually embedding JAR files into your bundle
>> or is your desire to simply have some way to automatically embedded
>> your dependencies (inlined or as JAR files) into your bundle?
>>
>> -> richard
>>
>>
>>
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 2:09 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>
>>>> Only dependencies that are of type bundle. Plain old jars would be
>>>> added to the classpath. I guess it doesn't have to be the default
>>>> behavior - just possible.
>>>>
>>>> As a side note. You create bundles that are dependent on other
>>>> bundles (to compile, I assume) but then you don't want them to be
>>>> required during runtime?
>>>>
>>>>
>>>>
>>>>
>>> The issue is Import-Package vs. Require-Bundle. I prefer
>>> Import-Package over Require-Bundle for my dependencies.
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Aaron Siri wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> I guess I'm expecting it to behave a little more like the
>>>>> war-plugin with respect to dependency jars. Any dependency that is
>>>>> of type jar and has a scope of something like compile will be
>>>>> included in the bundle jar (and on the manifest classpath). For
>>>>> that matter, any dependency that is of type bundle I'd expect to be
>>>>> included in the manifest
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Required-Bundles property.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Well, I definitely would not want the default handling of
>>>> dependencies to be converted to require-bundle...
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -Aaron
>>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>>> To: Aaron Siri
>>>>> Cc: felix-dev@incubator.apache.org
>>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>>
>>>>> Sorry for the previous mail, was not finished yet.
>>>>>
>>>>> I think it is :
>>>>>
>>>>> <configuration>
>>>>> <instructions>
>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>> </instructions>
>>>>> </configuration>
>>>>>
>>>>> And not
>>>>>
>>>>> <configuration>
>>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>>> </configuration>
>>>>>
>>>>> You can always package the bundles as jars, you just have to
>>>>> Include them as resources. However, this implies you know where to find
>>>>>
> them.
>
>>>>> Please realize that the plugin was build for the OSGi model where
>>>>> you have many small bundles. This implies that not all scenarios
>>>>> are targeted with this plugin.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Peter Kriens
>>>>>
>>>>>
>>>>> AS> I was going to start asking similar questions. I'm wondering
>>>>> AS> how I get my dependencies packaged in the bundle (I prefer them
>>>>> AS> as jars and not inlined.) Does this thread imply that there is
>>>>> AS> no way for library jars to be packaged in the bundle using
>>>>>
>>>>>
>>>>>
>>>>>
>>>> maven-bundle-plugin?
>>>>
>>>>
>>>>
>>>>
>>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>>> AS> bundle
>>>>>
>>>>>
>>>>>
>>>>>
>>>> via:
>>>>
>>>>
>>>>
>>>>
>>>>> AS> <configuration>
>>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>>> AS> </configuration>
>>>>>
>>>>> AS> Which doesn't seem to be working. Is this the right way to get
>>>>> AS> it
>>>>> included?
>>>>>
>>>>> AS> -Aaron
>>>>>
>>>>> AS> -----Original Message-----
>>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>>> AS> To: Peter Kriens
>>>>> AS> Cc: felix-dev@incubator.apache.org
>>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>>> AS> non-bundles
>>>>>
>>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> AS> Neither am I, but it actually means exclude. From
>>>>> AS> http://maven.apache.org/pom.html:
>>>>>
>>>>> --- >>8 ---
>>>>> AS> * scope: This element refers to the classpath of the task at
>>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>>
>>>>>
>> available:
>>
>>
>>>>> AS> * compile - this is the default scope, used if none is
>>>>>
> specified.
>
>>>>> AS> Compile dependencies are available in all classpaths.
>>>>> AS> * provided - this is much like compile, but indicates you
>>>>> AS> expect the JDK or a container to provide it. It is only
>>>>> AS> available on the compilation classpath, and is not transitive.
>>>>> AS> * runtime - this scope indicates that the dependency is not
>>>>> AS> required for compilation, but is for execution. It is in the
>>>>> AS> runtime and test classpaths, but not the compile classpath.
>>>>> AS> * test - this scope indicates that the dependency is not
>>>>> AS> required for normal use of the application, and is only
>>>>> AS> available for the test compilation and execution phases.
>>>>> AS> * system - this scope is similar to provided except that
>>>>> AS> you have to provide the JAR which contains it explicitly. The
>>>>> AS> artifact is always available and is not looked up in a repository.
>>>>> --- >>8 ---
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am on
>>>>>
> OSGi.
>
>>>>> AS> I just want stuff to work so I can build apps. :) But this is
>>>>> AS> an Apache list, I'm sure others can chime in!
>>>>>
>>>>> AS> What I meant in my previous mail was that I don't understand
>>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>>> AS> It's an OSGi-aware
>>>>> plugin...
>>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>>>> AS> plugin interaction going on there that I'm missing. In either
>>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>>
>>>>>
>>>>>
>>> showstopper for us.
>>>
>>>
>>>
>>>>> AS> [snip]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>>> AS> original example with my one-class bundle which depended on
>>>>>
>>>>>
>> commons-logging.
>>
>>
>>>>> AS> If the plugin would embed or inline the commons-logging jar AND
>>>>> AS> generate Import-Package statements... that would break when we
>>>>> AS> load it into the OSGi framework, right? No other bundle will
>>>>> AS> export commons-logging stuff and, moreover, even if there is I
>>>>> AS> want my bundle to
>>>>> use the embedded stuff like I said in my POM.
>>>>> AS> This is the core of the issue, as I see it.
>>>>>
>>>>> AS> Cheers,
>>>>>
>>>>> AS> -EE
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
Sorry - thought it was implied. Since this is a maven plugin I'd want the
process automated (with reasonable overrides.) :)
Again - like the war-plugin, osgi-plugin (and most other packaging maving
plugins that I am familiar with) jar dependencies (with the compile scope)
are automatically added to the artifact (in this case, a bundle) as-is and
made available to the runtime (in this case added to Bundle-ClassPath.)
Specifying where in the bundle the jars should go (i.e. META-INF/lib, lib,
etc.) would be a bonus.
With all due respect, having to specify the <Private-Package/> instruction to
pull in dependencies seems a little goofy and anti-maven. Via the POM I
already specified the dependencies and if they need to be part of the
artifact. Finer-grained visibility control can then be done via the
Export-Package instruction.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, December 05, 2006 3:26 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
> RH> You simply indicate which packages you want in your bundle and
> RH> they are
> copied into it.
>
> Huh?! So, if I write a bundle that uses the dom4j API (it is a
> <dependency/> in my bundle's POM) this plugin won't simply bundle
> dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I
> have to know what all of the packages are in dom4j.jar and explicitly
> *indicate* that they should be
> *copied* into the bundle so that they are available at runtime? Is
> that correct? I want to make sure I understand this correctly.
>
Yes, you understand. Often the only thing that is required is something
like:
<Private-Package>org.dom4j.*</Private-Package>
But you didn't answer my question, are you interested in having embedded JAR
files (as opposed to inlined JAR files) or interested in simply automating
the above process?
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 2:45 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> Understood. A switch or option would be nice then. My
>> Import-Package property is huge and always looks like a mess.
>>
>>
>
> If it is calculated, then it shouldn't be something to worry about...I
> am sure the byte code in my class files looks like a mess too. ;-)
>
>
>> Still wondering about jar dependencies and auto-generation of
>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>> supported this.
>>
>>
>
> Yes, the new plugin promotes a different approach to creating bundles.
> You simply indicate which packages you want in your bundle and they
> are copied into it.
>
> Do you have the need for actually embedding JAR files into your bundle
> or is your desire to simply have some way to automatically embedded
> your dependencies (inlined or as JAR files) into your bundle?
>
> -> richard
>
>
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 2:09 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>
>>> Only dependencies that are of type bundle. Plain old jars would be
>>> added to the classpath. I guess it doesn't have to be the default
>>> behavior - just possible.
>>>
>>> As a side note. You create bundles that are dependent on other
>>> bundles (to compile, I assume) but then you don't want them to be
>>> required during runtime?
>>>
>>>
>>>
>> The issue is Import-Package vs. Require-Bundle. I prefer
>> Import-Package over Require-Bundle for my dependencies.
>>
>> -> richard
>>
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>
>>>> I guess I'm expecting it to behave a little more like the
>>>> war-plugin with respect to dependency jars. Any dependency that is
>>>> of type jar and has a scope of something like compile will be
>>>> included in the bundle jar (and on the manifest classpath). For
>>>> that matter, any dependency that is of type bundle I'd expect to be
>>>> included in the manifest
>>>>
>>>>
>>>>
>>> Required-Bundles property.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>> Well, I definitely would not want the default handling of
>>> dependencies to be converted to require-bundle...
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>> To: Aaron Siri
>>>> Cc: felix-dev@incubator.apache.org
>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Sorry for the previous mail, was not finished yet.
>>>>
>>>> I think it is :
>>>>
>>>> <configuration>
>>>> <instructions>
>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>> </instructions>
>>>> </configuration>
>>>>
>>>> And not
>>>>
>>>> <configuration>
>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>> </configuration>
>>>>
>>>> You can always package the bundles as jars, you just have to
>>>> Include them as resources. However, this implies you know where to find
them.
>>>>
>>>> Please realize that the plugin was build for the OSGi model where
>>>> you have many small bundles. This implies that not all scenarios
>>>> are targeted with this plugin.
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>>
>>>> AS> I was going to start asking similar questions. I'm wondering
>>>> AS> how I get my dependencies packaged in the bundle (I prefer them
>>>> AS> as jars and not inlined.) Does this thread imply that there is
>>>> AS> no way for library jars to be packaged in the bundle using
>>>>
>>>>
>>>>
>>> maven-bundle-plugin?
>>>
>>>
>>>
>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>> AS> bundle
>>>>
>>>>
>>>>
>>> via:
>>>
>>>
>>>
>>>> AS> <configuration>
>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>> AS> </configuration>
>>>>
>>>> AS> Which doesn't seem to be working. Is this the right way to get
>>>> AS> it
>>>> included?
>>>>
>>>> AS> -Aaron
>>>>
>>>> AS> -----Original Message-----
>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>> AS> To: Peter Kriens
>>>> AS> Cc: felix-dev@incubator.apache.org
>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>> AS> non-bundles
>>>>
>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> AS> Neither am I, but it actually means exclude. From
>>>> AS> http://maven.apache.org/pom.html:
>>>>
>>>> --- >>8 ---
>>>> AS> * scope: This element refers to the classpath of the task at
>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>
> available:
>
>>>> AS> * compile - this is the default scope, used if none is
specified.
>>>> AS> Compile dependencies are available in all classpaths.
>>>> AS> * provided - this is much like compile, but indicates you
>>>> AS> expect the JDK or a container to provide it. It is only
>>>> AS> available on the compilation classpath, and is not transitive.
>>>> AS> * runtime - this scope indicates that the dependency is not
>>>> AS> required for compilation, but is for execution. It is in the
>>>> AS> runtime and test classpaths, but not the compile classpath.
>>>> AS> * test - this scope indicates that the dependency is not
>>>> AS> required for normal use of the application, and is only
>>>> AS> available for the test compilation and execution phases.
>>>> AS> * system - this scope is similar to provided except that
>>>> AS> you have to provide the JAR which contains it explicitly. The
>>>> AS> artifact is always available and is not looked up in a repository.
>>>> --- >>8 ---
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am on
OSGi.
>>>> AS> I just want stuff to work so I can build apps. :) But this is
>>>> AS> an Apache list, I'm sure others can chime in!
>>>>
>>>> AS> What I meant in my previous mail was that I don't understand
>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>> AS> It's an OSGi-aware
>>>> plugin...
>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>>> AS> plugin interaction going on there that I'm missing. In either
>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>
>>>>
>> showstopper for us.
>>
>>
>>>> AS> [snip]
>>>>
>>>>
>>>>
>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>> AS> original example with my one-class bundle which depended on
>>>>
> commons-logging.
>
>>>> AS> If the plugin would embed or inline the commons-logging jar AND
>>>> AS> generate Import-Package statements... that would break when we
>>>> AS> load it into the OSGi framework, right? No other bundle will
>>>> AS> export commons-logging stuff and, moreover, even if there is I
>>>> AS> want my bundle to
>>>> use the embedded stuff like I said in my POM.
>>>> AS> This is the core of the issue, as I see it.
>>>>
>>>> AS> Cheers,
>>>>
>>>> AS> -EE
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> RH> You simply indicate which packages you want in your bundle and they are
> copied into it.
>
> Huh?! So, if I write a bundle that uses the dom4j API (it is a <dependency/>
> in my bundle's POM) this plugin won't simply bundle dom4j.jar and add a
> reference to it to Bundle-ClassPath? Instead, I have to know what all of the
> packages are in dom4j.jar and explicitly *indicate* that they should be
> *copied* into the bundle so that they are available at runtime? Is that
> correct? I want to make sure I understand this correctly.
>
Yes, you understand. Often the only thing that is required is something
like:
<Private-Package>org.dom4j.*</Private-Package>
But you didn't answer my question, are you interested in having embedded
JAR files (as opposed to inlined JAR files) or interested in simply
automating the above process?
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 2:45 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> Understood. A switch or option would be nice then. My Import-Package
>> property is huge and always looks like a mess.
>>
>>
>
> If it is calculated, then it shouldn't be something to worry about...I am
> sure the byte code in my class files looks like a mess too. ;-)
>
>
>> Still wondering about jar dependencies and auto-generation of
>> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
>> supported this.
>>
>>
>
> Yes, the new plugin promotes a different approach to creating bundles.
> You simply indicate which packages you want in your bundle and they are
> copied into it.
>
> Do you have the need for actually embedding JAR files into your bundle or is
> your desire to simply have some way to automatically embedded your
> dependencies (inlined or as JAR files) into your bundle?
>
> -> richard
>
>
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 2:09 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>
>>> Only dependencies that are of type bundle. Plain old jars would be
>>> added to the classpath. I guess it doesn't have to be the default
>>> behavior - just possible.
>>>
>>> As a side note. You create bundles that are dependent on other
>>> bundles (to compile, I assume) but then you don't want them to be
>>> required during runtime?
>>>
>>>
>>>
>> The issue is Import-Package vs. Require-Bundle. I prefer
>> Import-Package over Require-Bundle for my dependencies.
>>
>> -> richard
>>
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>
>>>> I guess I'm expecting it to behave a little more like the war-plugin
>>>> with respect to dependency jars. Any dependency that is of type jar
>>>> and has a scope of something like compile will be included in the
>>>> bundle jar (and on the manifest classpath). For that matter, any
>>>> dependency that is of type bundle I'd expect to be included in the
>>>> manifest
>>>>
>>>>
>>>>
>>> Required-Bundles property.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>> Well, I definitely would not want the default handling of
>>> dependencies to be converted to require-bundle...
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>> To: Aaron Siri
>>>> Cc: felix-dev@incubator.apache.org
>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Sorry for the previous mail, was not finished yet.
>>>>
>>>> I think it is :
>>>>
>>>> <configuration>
>>>> <instructions>
>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>> </instructions>
>>>> </configuration>
>>>>
>>>> And not
>>>>
>>>> <configuration>
>>>> <Include-Resource>plugin.xml</Include-Resource>
>>>> </configuration>
>>>>
>>>> You can always package the bundles as jars, you just have to Include
>>>> them as resources. However, this implies you know where to find them.
>>>>
>>>> Please realize that the plugin was build for the OSGi model where
>>>> you have many small bundles. This implies that not all scenarios are
>>>> targeted with this plugin.
>>>>
>>>> Kind regards,
>>>>
>>>> Peter Kriens
>>>>
>>>>
>>>> AS> I was going to start asking similar questions. I'm wondering
>>>> AS> how I get my dependencies packaged in the bundle (I prefer them
>>>> AS> as jars and not inlined.) Does this thread imply that there is
>>>> AS> no way for library jars to be packaged in the bundle using
>>>>
>>>>
>>>>
>>> maven-bundle-plugin?
>>>
>>>
>>>
>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>> AS> bundle
>>>>
>>>>
>>>>
>>> via:
>>>
>>>
>>>
>>>> AS> <configuration>
>>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>>> AS> </configuration>
>>>>
>>>> AS> Which doesn't seem to be working. Is this the right way to get
>>>> AS> it
>>>> included?
>>>>
>>>> AS> -Aaron
>>>>
>>>> AS> -----Original Message-----
>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>> AS> To: Peter Kriens
>>>> AS> Cc: felix-dev@incubator.apache.org
>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>> AS> non-bundles
>>>>
>>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> AS> Neither am I, but it actually means exclude. From
>>>> AS> http://maven.apache.org/pom.html:
>>>>
>>>> --- >>8 ---
>>>> AS> * scope: This element refers to the classpath of the task at
>>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>
> available:
>
>>>> AS> * compile - this is the default scope, used if none is specified.
>>>> AS> Compile dependencies are available in all classpaths.
>>>> AS> * provided - this is much like compile, but indicates you
>>>> AS> expect the JDK or a container to provide it. It is only
>>>> AS> available on the compilation classpath, and is not transitive.
>>>> AS> * runtime - this scope indicates that the dependency is not
>>>> AS> required for compilation, but is for execution. It is in the
>>>> AS> runtime and test classpaths, but not the compile classpath.
>>>> AS> * test - this scope indicates that the dependency is not
>>>> AS> required for normal use of the application, and is only
>>>> AS> available for the test compilation and execution phases.
>>>> AS> * system - this scope is similar to provided except that you
>>>> AS> have to provide the JAR which contains it explicitly. The
>>>> AS> artifact is always available and is not looked up in a repository.
>>>> --- >>8 ---
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
>>>> AS> I just want stuff to work so I can build apps. :) But this is an
>>>> AS> Apache list, I'm sure others can chime in!
>>>>
>>>> AS> What I meant in my previous mail was that I don't understand why
>>>> AS> the plugin needs to know the <type> of the dependencies. It's an
>>>> AS> OSGi-aware
>>>> plugin...
>>>> AS> just have a peek in the jar file and figure it out? If it is,
>>>> AS> then generate Import-Package, if not then embed or inline it.
>>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>>> AS> plugin interaction going on there that I'm missing. In either
>>>> AS> case, this would be nice-to-have functionality but it's not a
>>>>
>>>>
>> showstopper for us.
>>
>>
>>>> AS> [snip]
>>>>
>>>>
>>>>
>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>> AS> original example with my one-class bundle which depended on
>>>>
> commons-logging.
>
>>>> AS> If the plugin would embed or inline the commons-logging jar AND
>>>> AS> generate Import-Package statements... that would break when we
>>>> AS> load it into the OSGi framework, right? No other bundle will
>>>> AS> export commons-logging stuff and, moreover, even if there is I
>>>> AS> want my bundle to
>>>> use the embedded stuff like I said in my POM.
>>>> AS> This is the core of the issue, as I see it.
>>>>
>>>> AS> Cheers,
>>>>
>>>> AS> -EE
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
RH> You simply indicate which packages you want in your bundle and they are
copied into it.
Huh?! So, if I write a bundle that uses the dom4j API (it is a <dependency/>
in my bundle's POM) this plugin won't simply bundle dom4j.jar and add a
reference to it to Bundle-ClassPath? Instead, I have to know what all of the
packages are in dom4j.jar and explicitly *indicate* that they should be
*copied* into the bundle so that they are available at runtime? Is that
correct? I want to make sure I understand this correctly.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, December 05, 2006 2:45 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
> Understood. A switch or option would be nice then. My Import-Package
> property is huge and always looks like a mess.
>
If it is calculated, then it shouldn't be something to worry about...I am
sure the byte code in my class files looks like a mess too. ;-)
> Still wondering about jar dependencies and auto-generation of
> Bundle-ClassPath (and packaging). The older maven-osgi-plugin
> supported this.
>
Yes, the new plugin promotes a different approach to creating bundles.
You simply indicate which packages you want in your bundle and they are
copied into it.
Do you have the need for actually embedding JAR files into your bundle or is
your desire to simply have some way to automatically embedded your
dependencies (inlined or as JAR files) into your bundle?
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 2:09 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> Only dependencies that are of type bundle. Plain old jars would be
>> added to the classpath. I guess it doesn't have to be the default
>> behavior - just possible.
>>
>> As a side note. You create bundles that are dependent on other
>> bundles (to compile, I assume) but then you don't want them to be
>> required during runtime?
>>
>>
>
> The issue is Import-Package vs. Require-Bundle. I prefer
> Import-Package over Require-Bundle for my dependencies.
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 1:56 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>
>>> I guess I'm expecting it to behave a little more like the war-plugin
>>> with respect to dependency jars. Any dependency that is of type jar
>>> and has a scope of something like compile will be included in the
>>> bundle jar (and on the manifest classpath). For that matter, any
>>> dependency that is of type bundle I'd expect to be included in the
>>> manifest
>>>
>>>
>> Required-Bundles property.
>>
>>
>>>
>>>
>>>
>> Well, I definitely would not want the default handling of
>> dependencies to be converted to require-bundle...
>>
>> -> richard
>>
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>> To: Aaron Siri
>>> Cc: felix-dev@incubator.apache.org
>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>
>>> Sorry for the previous mail, was not finished yet.
>>>
>>> I think it is :
>>>
>>> <configuration>
>>> <instructions>
>>> <Include-Resource>plugin.xml</Include-Resource>
>>> </instructions>
>>> </configuration>
>>>
>>> And not
>>>
>>> <configuration>
>>> <Include-Resource>plugin.xml</Include-Resource>
>>> </configuration>
>>>
>>> You can always package the bundles as jars, you just have to Include
>>> them as resources. However, this implies you know where to find them.
>>>
>>> Please realize that the plugin was build for the OSGi model where
>>> you have many small bundles. This implies that not all scenarios are
>>> targeted with this plugin.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> AS> I was going to start asking similar questions. I'm wondering
>>> AS> how I get my dependencies packaged in the bundle (I prefer them
>>> AS> as jars and not inlined.) Does this thread imply that there is
>>> AS> no way for library jars to be packaged in the bundle using
>>>
>>>
>> maven-bundle-plugin?
>>
>>
>>> AS> I'm also trying to get the plugin.xml file included into the
>>> AS> bundle
>>>
>>>
>> via:
>>
>>
>>> AS> <configuration>
>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>> AS> </configuration>
>>>
>>> AS> Which doesn't seem to be working. Is this the right way to get
>>> AS> it
>>> included?
>>>
>>> AS> -Aaron
>>>
>>> AS> -----Original Message-----
>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>> AS> To: Peter Kriens
>>> AS> Cc: felix-dev@incubator.apache.org
>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>> AS> non-bundles
>>>
>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>
>>>>>
>>>>>
>>> AS> Neither am I, but it actually means exclude. From
>>> AS> http://maven.apache.org/pom.html:
>>>
>>> --- >>8 ---
>>> AS> * scope: This element refers to the classpath of the task at
>>> AS> hand (compiling and runtime, testing, etc.) as well as how to
>>> AS> limit the transitivity of a depedency. There are five scopes
available:
>>> AS> * compile - this is the default scope, used if none is specified.
>>> AS> Compile dependencies are available in all classpaths.
>>> AS> * provided - this is much like compile, but indicates you
>>> AS> expect the JDK or a container to provide it. It is only
>>> AS> available on the compilation classpath, and is not transitive.
>>> AS> * runtime - this scope indicates that the dependency is not
>>> AS> required for compilation, but is for execution. It is in the
>>> AS> runtime and test classpaths, but not the compile classpath.
>>> AS> * test - this scope indicates that the dependency is not
>>> AS> required for normal use of the application, and is only
>>> AS> available for the test compilation and execution phases.
>>> AS> * system - this scope is similar to provided except that you
>>> AS> have to provide the JAR which contains it explicitly. The
>>> AS> artifact is always available and is not looked up in a repository.
>>> --- >>8 ---
>>>
>>>
>>>
>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
>>> AS> I just want stuff to work so I can build apps. :) But this is an
>>> AS> Apache list, I'm sure others can chime in!
>>>
>>> AS> What I meant in my previous mail was that I don't understand why
>>> AS> the plugin needs to know the <type> of the dependencies. It's an
>>> AS> OSGi-aware
>>> plugin...
>>> AS> just have a peek in the jar file and figure it out? If it is,
>>> AS> then generate Import-Package, if not then embed or inline it.
>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>> AS> plugin interaction going on there that I'm missing. In either
>>> AS> case, this would be nice-to-have functionality but it's not a
>>>
> showstopper for us.
>
>>> AS> [snip]
>>>
>>>
>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>> AS> Here's where I don't get it. Let's go back to the simple
>>> AS> original example with my one-class bundle which depended on
commons-logging.
>>> AS> If the plugin would embed or inline the commons-logging jar AND
>>> AS> generate Import-Package statements... that would break when we
>>> AS> load it into the OSGi framework, right? No other bundle will
>>> AS> export commons-logging stuff and, moreover, even if there is I
>>> AS> want my bundle to
>>> use the embedded stuff like I said in my POM.
>>> AS> This is the core of the issue, as I see it.
>>>
>>> AS> Cheers,
>>>
>>> AS> -EE
>>>
>>>
>>>
>>>
>>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> Understood. A switch or option would be nice then. My Import-Package
> property is huge and always looks like a mess.
>
If it is calculated, then it shouldn't be something to worry about...I
am sure the byte code in my class files looks like a mess too. ;-)
> Still wondering about jar dependencies and auto-generation of
> Bundle-ClassPath (and packaging). The older maven-osgi-plugin supported
> this.
>
Yes, the new plugin promotes a different approach to creating bundles.
You simply indicate which packages you want in your bundle and they are
copied into it.
Do you have the need for actually embedding JAR files into your bundle
or is your desire to simply have some way to automatically embedded your
dependencies (inlined or as JAR files) into your bundle?
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 2:09 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> Only dependencies that are of type bundle. Plain old jars would be
>> added to the classpath. I guess it doesn't have to be the default
>> behavior - just possible.
>>
>> As a side note. You create bundles that are dependent on other
>> bundles (to compile, I assume) but then you don't want them to be
>> required during runtime?
>>
>>
>
> The issue is Import-Package vs. Require-Bundle. I prefer Import-Package over
> Require-Bundle for my dependencies.
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 1:56 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>
>>> I guess I'm expecting it to behave a little more like the war-plugin
>>> with respect to dependency jars. Any dependency that is of type jar
>>> and has a scope of something like compile will be included in the
>>> bundle jar (and on the manifest classpath). For that matter, any
>>> dependency that is of type bundle I'd expect to be included in the
>>> manifest
>>>
>>>
>> Required-Bundles property.
>>
>>
>>>
>>>
>>>
>> Well, I definitely would not want the default handling of dependencies
>> to be converted to require-bundle...
>>
>> -> richard
>>
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>> To: Aaron Siri
>>> Cc: felix-dev@incubator.apache.org
>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>
>>> Sorry for the previous mail, was not finished yet.
>>>
>>> I think it is :
>>>
>>> <configuration>
>>> <instructions>
>>> <Include-Resource>plugin.xml</Include-Resource>
>>> </instructions>
>>> </configuration>
>>>
>>> And not
>>>
>>> <configuration>
>>> <Include-Resource>plugin.xml</Include-Resource>
>>> </configuration>
>>>
>>> You can always package the bundles as jars, you just have to Include
>>> them as resources. However, this implies you know where to find them.
>>>
>>> Please realize that the plugin was build for the OSGi model where you
>>> have many small bundles. This implies that not all scenarios are
>>> targeted with this plugin.
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>
>>> AS> I was going to start asking similar questions. I'm wondering how
>>> AS> I get my dependencies packaged in the bundle (I prefer them as
>>> AS> jars and not inlined.) Does this thread imply that there is no
>>> AS> way for library jars to be packaged in the bundle using
>>>
>>>
>> maven-bundle-plugin?
>>
>>
>>> AS> I'm also trying to get the plugin.xml file included into the
>>> AS> bundle
>>>
>>>
>> via:
>>
>>
>>> AS> <configuration>
>>> AS> <Include-Resource>plugin.xml</Include-Resource>
>>> AS> </configuration>
>>>
>>> AS> Which doesn't seem to be working. Is this the right way to get
>>> AS> it
>>> included?
>>>
>>> AS> -Aaron
>>>
>>> AS> -----Original Message-----
>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>> AS> To: Peter Kriens
>>> AS> Cc: felix-dev@incubator.apache.org
>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>> AS> non-bundles
>>>
>>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>>
>>>>>
>>>>>
>>> AS> Neither am I, but it actually means exclude. From
>>> AS> http://maven.apache.org/pom.html:
>>>
>>> --- >>8 ---
>>> AS> * scope: This element refers to the classpath of the task at hand
>>> AS> (compiling and runtime, testing, etc.) as well as how to limit
>>> AS> the transitivity of a depedency. There are five scopes available:
>>> AS> * compile - this is the default scope, used if none is specified.
>>> AS> Compile dependencies are available in all classpaths.
>>> AS> * provided - this is much like compile, but indicates you
>>> AS> expect the JDK or a container to provide it. It is only available
>>> AS> on the compilation classpath, and is not transitive.
>>> AS> * runtime - this scope indicates that the dependency is not
>>> AS> required for compilation, but is for execution. It is in the
>>> AS> runtime and test classpaths, but not the compile classpath.
>>> AS> * test - this scope indicates that the dependency is not
>>> AS> required for normal use of the application, and is only available
>>> AS> for the test compilation and execution phases.
>>> AS> * system - this scope is similar to provided except that you
>>> AS> have to provide the JAR which contains it explicitly. The
>>> AS> artifact is always available and is not looked up in a repository.
>>> --- >>8 ---
>>>
>>>
>>>
>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
>>> AS> I just want stuff to work so I can build apps. :) But this is an
>>> AS> Apache list, I'm sure others can chime in!
>>>
>>> AS> What I meant in my previous mail was that I don't understand why
>>> AS> the plugin needs to know the <type> of the dependencies. It's an
>>> AS> OSGi-aware
>>> plugin...
>>> AS> just have a peek in the jar file and figure it out? If it is,
>>> AS> then generate Import-Package, if not then embed or inline it.
>>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>>> AS> plugin interaction going on there that I'm missing. In either
>>> AS> case, this would be nice-to-have functionality but it's not a
>>>
> showstopper for us.
>
>>> AS> [snip]
>>>
>>>
>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>> AS> Here's where I don't get it. Let's go back to the simple original
>>> AS> example with my one-class bundle which depended on commons-logging.
>>> AS> If the plugin would embed or inline the commons-logging jar AND
>>> AS> generate Import-Package statements... that would break when we
>>> AS> load it into the OSGi framework, right? No other bundle will
>>> AS> export commons-logging stuff and, moreover, even if there is I
>>> AS> want my bundle to
>>> use the embedded stuff like I said in my POM.
>>> AS> This is the core of the issue, as I see it.
>>>
>>> AS> Cheers,
>>>
>>> AS> -EE
>>>
>>>
>>>
>>>
>>>
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
Understood. A switch or option would be nice then. My Import-Package
property is huge and always looks like a mess.
Still wondering about jar dependencies and auto-generation of
Bundle-ClassPath (and packaging). The older maven-osgi-plugin supported
this.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, December 05, 2006 2:09 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
> Only dependencies that are of type bundle. Plain old jars would be
> added to the classpath. I guess it doesn't have to be the default
> behavior - just possible.
>
> As a side note. You create bundles that are dependent on other
> bundles (to compile, I assume) but then you don't want them to be
> required during runtime?
>
The issue is Import-Package vs. Require-Bundle. I prefer Import-Package over
Require-Bundle for my dependencies.
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 1:56 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> I guess I'm expecting it to behave a little more like the war-plugin
>> with respect to dependency jars. Any dependency that is of type jar
>> and has a scope of something like compile will be included in the
>> bundle jar (and on the manifest classpath). For that matter, any
>> dependency that is of type bundle I'd expect to be included in the
>> manifest
>>
> Required-Bundles property.
>
>>
>>
>
> Well, I definitely would not want the default handling of dependencies
> to be converted to require-bundle...
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>> Sent: Tuesday, December 05, 2006 12:46 PM
>> To: Aaron Siri
>> Cc: felix-dev@incubator.apache.org
>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>
>> Sorry for the previous mail, was not finished yet.
>>
>> I think it is :
>>
>> <configuration>
>> <instructions>
>> <Include-Resource>plugin.xml</Include-Resource>
>> </instructions>
>> </configuration>
>>
>> And not
>>
>> <configuration>
>> <Include-Resource>plugin.xml</Include-Resource>
>> </configuration>
>>
>> You can always package the bundles as jars, you just have to Include
>> them as resources. However, this implies you know where to find them.
>>
>> Please realize that the plugin was build for the OSGi model where you
>> have many small bundles. This implies that not all scenarios are
>> targeted with this plugin.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> AS> I was going to start asking similar questions. I'm wondering how
>> AS> I get my dependencies packaged in the bundle (I prefer them as
>> AS> jars and not inlined.) Does this thread imply that there is no
>> AS> way for library jars to be packaged in the bundle using
>>
> maven-bundle-plugin?
>
>> AS> I'm also trying to get the plugin.xml file included into the
>> AS> bundle
>>
> via:
>
>> AS> <configuration>
>> AS> <Include-Resource>plugin.xml</Include-Resource>
>> AS> </configuration>
>>
>> AS> Which doesn't seem to be working. Is this the right way to get
>> AS> it
>> included?
>>
>> AS> -Aaron
>>
>> AS> -----Original Message-----
>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>> AS> To: Peter Kriens
>> AS> Cc: felix-dev@incubator.apache.org
>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>> AS> non-bundles
>>
>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>
>>>>
>> AS> Neither am I, but it actually means exclude. From
>> AS> http://maven.apache.org/pom.html:
>>
>> --- >>8 ---
>> AS> * scope: This element refers to the classpath of the task at hand
>> AS> (compiling and runtime, testing, etc.) as well as how to limit
>> AS> the transitivity of a depedency. There are five scopes available:
>> AS> * compile - this is the default scope, used if none is specified.
>> AS> Compile dependencies are available in all classpaths.
>> AS> * provided - this is much like compile, but indicates you
>> AS> expect the JDK or a container to provide it. It is only available
>> AS> on the compilation classpath, and is not transitive.
>> AS> * runtime - this scope indicates that the dependency is not
>> AS> required for compilation, but is for execution. It is in the
>> AS> runtime and test classpaths, but not the compile classpath.
>> AS> * test - this scope indicates that the dependency is not
>> AS> required for normal use of the application, and is only available
>> AS> for the test compilation and execution phases.
>> AS> * system - this scope is similar to provided except that you
>> AS> have to provide the JAR which contains it explicitly. The
>> AS> artifact is always available and is not looked up in a repository.
>> --- >>8 ---
>>
>>
>>
>>>> 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.
>>>>
>>>>
>> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
>> AS> I just want stuff to work so I can build apps. :) But this is an
>> AS> Apache list, I'm sure others can chime in!
>>
>> AS> What I meant in my previous mail was that I don't understand why
>> AS> the plugin needs to know the <type> of the dependencies. It's an
>> AS> OSGi-aware
>> plugin...
>> AS> just have a peek in the jar file and figure it out? If it is,
>> AS> then generate Import-Package, if not then embed or inline it.
>> AS> Would work nicely. But maybe there's some Maven core <-> Maven
>> AS> plugin interaction going on there that I'm missing. In either
>> AS> case, this would be nice-to-have functionality but it's not a
showstopper for us.
>>
>> AS> [snip]
>>
>>
>>>> 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.
>>>>
>>>>
>> AS> Here's where I don't get it. Let's go back to the simple original
>> AS> example with my one-class bundle which depended on commons-logging.
>> AS> If the plugin would embed or inline the commons-logging jar AND
>> AS> generate Import-Package statements... that would break when we
>> AS> load it into the OSGi framework, right? No other bundle will
>> AS> export commons-logging stuff and, moreover, even if there is I
>> AS> want my bundle to
>> use the embedded stuff like I said in my POM.
>> AS> This is the core of the issue, as I see it.
>>
>> AS> Cheers,
>>
>> AS> -EE
>>
>>
>>
>>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> Only dependencies that are of type bundle. Plain old jars would be added to
> the classpath. I guess it doesn't have to be the default behavior - just
> possible.
>
> As a side note. You create bundles that are dependent on other bundles (to
> compile, I assume) but then you don't want them to be required during
> runtime?
>
The issue is Import-Package vs. Require-Bundle. I prefer Import-Package
over Require-Bundle for my dependencies.
-> richard
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 1:56 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>
>> I guess I'm expecting it to behave a little more like the war-plugin
>> with respect to dependency jars. Any dependency that is of type jar
>> and has a scope of something like compile will be included in the
>> bundle jar (and on the manifest classpath). For that matter, any
>> dependency that is of type bundle I'd expect to be included in the manifest
>>
> Required-Bundles property.
>
>>
>>
>
> Well, I definitely would not want the default handling of dependencies to be
> converted to require-bundle...
>
> -> richard
>
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>> Sent: Tuesday, December 05, 2006 12:46 PM
>> To: Aaron Siri
>> Cc: felix-dev@incubator.apache.org
>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>
>> Sorry for the previous mail, was not finished yet.
>>
>> I think it is :
>>
>> <configuration>
>> <instructions>
>> <Include-Resource>plugin.xml</Include-Resource>
>> </instructions>
>> </configuration>
>>
>> And not
>>
>> <configuration>
>> <Include-Resource>plugin.xml</Include-Resource>
>> </configuration>
>>
>> You can always package the bundles as jars, you just have to Include
>> them as resources. However, this implies you know where to find them.
>>
>> Please realize that the plugin was build for the OSGi model where you
>> have many small bundles. This implies that not all scenarios are
>> targeted with this plugin.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> AS> I was going to start asking similar questions. I'm wondering how
>> AS> I get my dependencies packaged in the bundle (I prefer them as
>> AS> jars and not inlined.) Does this thread imply that there is no way
>> AS> for library jars to be packaged in the bundle using
>>
> maven-bundle-plugin?
>
>> AS> I'm also trying to get the plugin.xml file included into the bundle
>>
> via:
>
>> AS> <configuration>
>> AS> <Include-Resource>plugin.xml</Include-Resource>
>> AS> </configuration>
>>
>> AS> Which doesn't seem to be working. Is this the right way to get it
>> included?
>>
>> AS> -Aaron
>>
>> AS> -----Original Message-----
>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>> AS> To: Peter Kriens
>> AS> Cc: felix-dev@incubator.apache.org
>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>> AS> non-bundles
>>
>> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>>
>>>>
>> AS> Neither am I, but it actually means exclude. From
>> AS> http://maven.apache.org/pom.html:
>>
>> --- >>8 ---
>> AS> * scope: This element refers to the classpath of the task at hand
>> AS> (compiling and runtime, testing, etc.) as well as how to limit the
>> AS> transitivity of a depedency. There are five scopes available:
>> AS> * compile - this is the default scope, used if none is specified.
>> AS> Compile dependencies are available in all classpaths.
>> AS> * provided - this is much like compile, but indicates you
>> AS> expect the JDK or a container to provide it. It is only available
>> AS> on the compilation classpath, and is not transitive.
>> AS> * runtime - this scope indicates that the dependency is not
>> AS> required for compilation, but is for execution. It is in the
>> AS> runtime and test classpaths, but not the compile classpath.
>> AS> * test - this scope indicates that the dependency is not
>> AS> required for normal use of the application, and is only available
>> AS> for the test compilation and execution phases.
>> AS> * system - this scope is similar to provided except that you
>> AS> have to provide the JAR which contains it explicitly. The artifact
>> AS> is always available and is not looked up in a repository.
>> --- >>8 ---
>>
>>
>>
>>>> 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.
>>>>
>>>>
>> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
>> AS> I just want stuff to work so I can build apps. :) But this is an
>> AS> Apache list, I'm sure others can chime in!
>>
>> AS> What I meant in my previous mail was that I don't understand why
>> AS> the plugin needs to know the <type> of the dependencies. It's an
>> AS> OSGi-aware
>> plugin...
>> AS> just have a peek in the jar file and figure it out? If it is, then
>> AS> generate Import-Package, if not then embed or inline it. Would
>> AS> work nicely. But maybe there's some Maven core <-> Maven plugin
>> AS> interaction going on there that I'm missing. In either case, this
>> AS> would be nice-to-have functionality but it's not a showstopper for us.
>>
>> AS> [snip]
>>
>>
>>>> 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.
>>>>
>>>>
>> AS> Here's where I don't get it. Let's go back to the simple original
>> AS> example with my one-class bundle which depended on commons-logging.
>> AS> If the plugin would embed or inline the commons-logging jar AND
>> AS> generate Import-Package statements... that would break when we
>> AS> load it into the OSGi framework, right? No other bundle will
>> AS> export commons-logging stuff and, moreover, even if there is I
>> AS> want my bundle to
>> use the embedded stuff like I said in my POM.
>> AS> This is the core of the issue, as I see it.
>>
>> AS> Cheers,
>>
>> AS> -EE
>>
>>
>>
>>
RE: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
Only dependencies that are of type bundle. Plain old jars would be added to
the classpath. I guess it doesn't have to be the default behavior - just
possible.
As a side note. You create bundles that are dependent on other bundles (to
compile, I assume) but then you don't want them to be required during
runtime?
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, December 05, 2006 1:56 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
> I guess I'm expecting it to behave a little more like the war-plugin
> with respect to dependency jars. Any dependency that is of type jar
> and has a scope of something like compile will be included in the
> bundle jar (and on the manifest classpath). For that matter, any
> dependency that is of type bundle I'd expect to be included in the manifest
Required-Bundles property.
>
Well, I definitely would not want the default handling of dependencies to be
converted to require-bundle...
-> richard
> -Aaron
>
> -----Original Message-----
> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
> Sent: Tuesday, December 05, 2006 12:46 PM
> To: Aaron Siri
> Cc: felix-dev@incubator.apache.org
> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>
> Sorry for the previous mail, was not finished yet.
>
> I think it is :
>
> <configuration>
> <instructions>
> <Include-Resource>plugin.xml</Include-Resource>
> </instructions>
> </configuration>
>
> And not
>
> <configuration>
> <Include-Resource>plugin.xml</Include-Resource>
> </configuration>
>
> You can always package the bundles as jars, you just have to Include
> them as resources. However, this implies you know where to find them.
>
> Please realize that the plugin was build for the OSGi model where you
> have many small bundles. This implies that not all scenarios are
> targeted with this plugin.
>
> Kind regards,
>
> Peter Kriens
>
>
> AS> I was going to start asking similar questions. I'm wondering how
> AS> I get my dependencies packaged in the bundle (I prefer them as
> AS> jars and not inlined.) Does this thread imply that there is no way
> AS> for library jars to be packaged in the bundle using
maven-bundle-plugin?
>
> AS> I'm also trying to get the plugin.xml file included into the bundle
via:
>
> AS> <configuration>
> AS> <Include-Resource>plugin.xml</Include-Resource>
> AS> </configuration>
>
> AS> Which doesn't seem to be working. Is this the right way to get it
> included?
>
> AS> -Aaron
>
> AS> -----Original Message-----
> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
> AS> Sent: Tuesday, December 05, 2006 10:10 AM
> AS> To: Peter Kriens
> AS> Cc: felix-dev@incubator.apache.org
> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
> AS> non-bundles
>
> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>
>
> AS> Neither am I, but it actually means exclude. From
> AS> http://maven.apache.org/pom.html:
>
> --- >>8 ---
> AS> * scope: This element refers to the classpath of the task at hand
> AS> (compiling and runtime, testing, etc.) as well as how to limit the
> AS> transitivity of a depedency. There are five scopes available:
> AS> * compile - this is the default scope, used if none is specified.
> AS> Compile dependencies are available in all classpaths.
> AS> * provided - this is much like compile, but indicates you
> AS> expect the JDK or a container to provide it. It is only available
> AS> on the compilation classpath, and is not transitive.
> AS> * runtime - this scope indicates that the dependency is not
> AS> required for compilation, but is for execution. It is in the
> AS> runtime and test classpaths, but not the compile classpath.
> AS> * test - this scope indicates that the dependency is not
> AS> required for normal use of the application, and is only available
> AS> for the test compilation and execution phases.
> AS> * system - this scope is similar to provided except that you
> AS> have to provide the JAR which contains it explicitly. The artifact
> AS> is always available and is not looked up in a repository.
> --- >>8 ---
>
>
>>> 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.
>>>
>
> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
> AS> I just want stuff to work so I can build apps. :) But this is an
> AS> Apache list, I'm sure others can chime in!
>
> AS> What I meant in my previous mail was that I don't understand why
> AS> the plugin needs to know the <type> of the dependencies. It's an
> AS> OSGi-aware
> plugin...
> AS> just have a peek in the jar file and figure it out? If it is, then
> AS> generate Import-Package, if not then embed or inline it. Would
> AS> work nicely. But maybe there's some Maven core <-> Maven plugin
> AS> interaction going on there that I'm missing. In either case, this
> AS> would be nice-to-have functionality but it's not a showstopper for us.
>
> AS> [snip]
>
>>> 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.
>>>
>
> AS> Here's where I don't get it. Let's go back to the simple original
> AS> example with my one-class bundle which depended on commons-logging.
> AS> If the plugin would embed or inline the commons-logging jar AND
> AS> generate Import-Package statements... that would break when we
> AS> load it into the OSGi framework, right? No other bundle will
> AS> export commons-logging stuff and, moreover, even if there is I
> AS> want my bundle to
> use the embedded stuff like I said in my POM.
> AS> This is the core of the issue, as I see it.
>
> AS> Cheers,
>
> AS> -EE
>
>
>
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> I guess I'm expecting it to behave a little more like the war-plugin with
> respect to dependency jars. Any dependency that is of type jar and has a
> scope of something like compile will be included in the bundle jar (and on
> the manifest classpath). For that matter, any dependency that is of type
> bundle I'd expect to be included in the manifest Required-Bundles property.
>
Well, I definitely would not want the default handling of dependencies
to be converted to require-bundle...
-> richard
> -Aaron
>
> -----Original Message-----
> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
> Sent: Tuesday, December 05, 2006 12:46 PM
> To: Aaron Siri
> Cc: felix-dev@incubator.apache.org
> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>
> Sorry for the previous mail, was not finished yet.
>
> I think it is :
>
> <configuration>
> <instructions>
> <Include-Resource>plugin.xml</Include-Resource>
> </instructions>
> </configuration>
>
> And not
>
> <configuration>
> <Include-Resource>plugin.xml</Include-Resource>
> </configuration>
>
> You can always package the bundles as jars, you just have to Include them as
> resources. However, this implies you know where to find them.
>
> Please realize that the plugin was build for the OSGi model where you have
> many small bundles. This implies that not all scenarios are targeted with
> this plugin.
>
> Kind regards,
>
> Peter Kriens
>
>
> AS> I was going to start asking similar questions. I'm wondering how I
> AS> get my dependencies packaged in the bundle (I prefer them as jars
> AS> and not inlined.) Does this thread imply that there is no way for
> AS> library jars to be packaged in the bundle using maven-bundle-plugin?
>
> AS> I'm also trying to get the plugin.xml file included into the bundle via:
>
> AS> <configuration>
> AS> <Include-Resource>plugin.xml</Include-Resource>
> AS> </configuration>
>
> AS> Which doesn't seem to be working. Is this the right way to get it
> included?
>
> AS> -Aaron
>
> AS> -----Original Message-----
> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
> AS> Sent: Tuesday, December 05, 2006 10:10 AM
> AS> To: Peter Kriens
> AS> Cc: felix-dev@incubator.apache.org
> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
> AS> non-bundles
>
> AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
>>>
>
> AS> Neither am I, but it actually means exclude. From
> AS> http://maven.apache.org/pom.html:
>
> --- >>8 ---
> AS> * scope: This element refers to the classpath of the task at hand
> AS> (compiling and runtime, testing, etc.) as well as how to limit the
> AS> transitivity of a depedency. There are five scopes available:
> AS> * compile - this is the default scope, used if none is specified.
> AS> Compile dependencies are available in all classpaths.
> AS> * provided - this is much like compile, but indicates you expect
> AS> the JDK or a container to provide it. It is only available on the
> AS> compilation classpath, and is not transitive.
> AS> * runtime - this scope indicates that the dependency is not
> AS> required for compilation, but is for execution. It is in the runtime
> AS> and test classpaths, but not the compile classpath.
> AS> * test - this scope indicates that the dependency is not
> AS> required for normal use of the application, and is only available
> AS> for the test compilation and execution phases.
> AS> * system - this scope is similar to provided except that you
> AS> have to provide the JAR which contains it explicitly. The artifact
> AS> is always available and is not looked up in a repository.
> --- >>8 ---
>
>
>>> 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.
>>>
>
> AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
> AS> I just want stuff to work so I can build apps. :) But this is an
> AS> Apache list, I'm sure others can chime in!
>
> AS> What I meant in my previous mail was that I don't understand why the
> AS> plugin needs to know the <type> of the dependencies. It's an OSGi-aware
> plugin...
> AS> just have a peek in the jar file and figure it out? If it is, then
> AS> generate Import-Package, if not then embed or inline it. Would work
> AS> nicely. But maybe there's some Maven core <-> Maven plugin
> AS> interaction going on there that I'm missing. In either case, this
> AS> would be nice-to-have functionality but it's not a showstopper for us.
>
> AS> [snip]
>
>>> 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.
>>>
>
> AS> Here's where I don't get it. Let's go back to the simple original
> AS> example with my one-class bundle which depended on commons-logging.
> AS> If the plugin would embed or inline the commons-logging jar AND
> AS> generate Import-Package statements... that would break when we load
> AS> it into the OSGi framework, right? No other bundle will export
> AS> commons-logging stuff and, moreover, even if there is I want my bundle to
> use the embedded stuff like I said in my POM.
> AS> This is the core of the issue, as I see it.
>
> AS> Cheers,
>
> AS> -EE
>
>
>
RE: Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
That was it. Thanks for the help - don't know how I overlooked that.
About the packaging... isn't that basic maven behavior. Shouldn't the maven
plugin do *something* with the dependencies in the final package? Even if I
had many small bundles I'm not going to want to write the code for
everything. Even if I wanted a bundle that only provides xmlbeans support or
something similar how would I bundle the xmlbeans jar into the bundle jar?
Whether it is many small bundles with only one third-party,
dependency-defined jar or one bundle with many third-party,
dependency-defined jars I wouldn't think there is much difference.
I guess I'm expecting it to behave a little more like the war-plugin with
respect to dependency jars. Any dependency that is of type jar and has a
scope of something like compile will be included in the bundle jar (and on
the manifest classpath). For that matter, any dependency that is of type
bundle I'd expect to be included in the manifest Required-Bundles property.
-Aaron
-----Original Message-----
From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
Sent: Tuesday, December 05, 2006 12:46 PM
To: Aaron Siri
Cc: felix-dev@incubator.apache.org
Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
Sorry for the previous mail, was not finished yet.
I think it is :
<configuration>
<instructions>
<Include-Resource>plugin.xml</Include-Resource>
</instructions>
</configuration>
And not
<configuration>
<Include-Resource>plugin.xml</Include-Resource>
</configuration>
You can always package the bundles as jars, you just have to Include them as
resources. However, this implies you know where to find them.
Please realize that the plugin was build for the OSGi model where you have
many small bundles. This implies that not all scenarios are targeted with
this plugin.
Kind regards,
Peter Kriens
AS> I was going to start asking similar questions. I'm wondering how I
AS> get my dependencies packaged in the bundle (I prefer them as jars
AS> and not inlined.) Does this thread imply that there is no way for
AS> library jars to be packaged in the bundle using maven-bundle-plugin?
AS> I'm also trying to get the plugin.xml file included into the bundle via:
AS> <configuration>
AS> <Include-Resource>plugin.xml</Include-Resource>
AS> </configuration>
AS> Which doesn't seem to be working. Is this the right way to get it
included?
AS> -Aaron
AS> -----Original Message-----
AS> From: Emil Eifrém [mailto:emil@eifrem.com]
AS> Sent: Tuesday, December 05, 2006 10:10 AM
AS> To: Peter Kriens
AS> Cc: felix-dev@incubator.apache.org
AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
AS> non-bundles
AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
AS> Neither am I, but it actually means exclude. From
AS> http://maven.apache.org/pom.html:
--- >>8 ---
AS> * scope: This element refers to the classpath of the task at hand
AS> (compiling and runtime, testing, etc.) as well as how to limit the
AS> transitivity of a depedency. There are five scopes available:
AS> * compile - this is the default scope, used if none is specified.
AS> Compile dependencies are available in all classpaths.
AS> * provided - this is much like compile, but indicates you expect
AS> the JDK or a container to provide it. It is only available on the
AS> compilation classpath, and is not transitive.
AS> * runtime - this scope indicates that the dependency is not
AS> required for compilation, but is for execution. It is in the runtime
AS> and test classpaths, but not the compile classpath.
AS> * test - this scope indicates that the dependency is not
AS> required for normal use of the application, and is only available
AS> for the test compilation and execution phases.
AS> * system - this scope is similar to provided except that you
AS> have to provide the JAR which contains it explicitly. The artifact
AS> is always available and is not looked up in a repository.
--- >>8 ---
>>
>>
>> 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.
AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
AS> I just want stuff to work so I can build apps. :) But this is an
AS> Apache list, I'm sure others can chime in!
AS> What I meant in my previous mail was that I don't understand why the
AS> plugin needs to know the <type> of the dependencies. It's an OSGi-aware
plugin...
AS> just have a peek in the jar file and figure it out? If it is, then
AS> generate Import-Package, if not then embed or inline it. Would work
AS> nicely. But maybe there's some Maven core <-> Maven plugin
AS> interaction going on there that I'm missing. In either case, this
AS> would be nice-to-have functionality but it's not a showstopper for us.
AS> [snip]
>> 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.
AS> Here's where I don't get it. Let's go back to the simple original
AS> example with my one-class bundle which depended on commons-logging.
AS> If the plugin would embed or inline the commons-logging jar AND
AS> generate Import-Package statements... that would break when we load
AS> it into the OSGi framework, right? No other bundle will export
AS> commons-logging stuff and, moreover, even if there is I want my bundle to
use the embedded stuff like I said in my POM.
AS> This is the core of the issue, as I see it.
AS> Cheers,
AS> -EE
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by Peter Kriens <Pe...@aQute.biz>.
Sorry for the previous mail, was not finished yet.
I think it is :
<configuration>
<instructions>
<Include-Resource>plugin.xml</Include-Resource>
</instructions>
</configuration>
And not
<configuration>
<Include-Resource>plugin.xml</Include-Resource>
</configuration>
You can always package the bundles as jars, you just have to Include
them as resources. However, this implies you know where to find them.
Please realize that the plugin was build for the OSGi model where you
have many small bundles. This implies that not all scenarios are
targeted with this plugin.
Kind regards,
Peter Kriens
AS> I was going to start asking similar questions. I'm wondering how I get my
AS> dependencies packaged in the bundle (I prefer them as jars and not inlined.)
AS> Does this thread imply that there is no way for library jars to be packaged
AS> in the bundle using maven-bundle-plugin?
AS> I'm also trying to get the plugin.xml file included into the bundle via:
AS> <configuration>
AS> <Include-Resource>plugin.xml</Include-Resource>
AS> </configuration>
AS> Which doesn't seem to be working. Is this the right way to get it included?
AS> -Aaron
AS> -----Original Message-----
AS> From: Emil Eifrém [mailto:emil@eifrem.com]
AS> Sent: Tuesday, December 05, 2006 10:10 AM
AS> To: Peter Kriens
AS> Cc: felix-dev@incubator.apache.org
AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from non-bundles
AS> On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
AS> Neither am I, but it actually means exclude. From
AS> http://maven.apache.org/pom.html:
--- >>8 ---
AS> * scope: This element refers to the classpath of the task at hand (compiling
AS> and runtime, testing, etc.) as well as how to limit the transitivity of a
AS> depedency. There are five scopes available:
AS> * compile - this is the default scope, used if none is specified.
AS> Compile dependencies are available in all classpaths.
AS> * provided - this is much like compile, but indicates you expect the JDK
AS> or a container to provide it. It is only available on the compilation
AS> classpath, and is not transitive.
AS> * runtime - this scope indicates that the dependency is not required for
AS> compilation, but is for execution. It is in the runtime and test classpaths,
AS> but not the compile classpath.
AS> * test - this scope indicates that the dependency is not required for
AS> normal use of the application, and is only available for the test compilation
AS> and execution phases.
AS> * system - this scope is similar to provided except that you have to
AS> provide the JAR which contains it explicitly. The artifact is always
AS> available and is not looked up in a repository.
--- >>8 ---
>>
>>
>> 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.
AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
AS> I just want stuff to work so I can build apps. :) But this is an Apache list,
AS> I'm sure others can chime in!
AS> What I meant in my previous mail was that I don't understand why the plugin
AS> needs to know the <type> of the dependencies. It's an OSGi-aware plugin...
AS> just have a peek in the jar file and figure it out? If it is, then generate
AS> Import-Package, if not then embed or inline it. Would work nicely. But maybe
AS> there's some Maven core <-> Maven plugin interaction going on there that I'm
AS> missing. In either case, this would be nice-to-have functionality but it's
AS> not a showstopper for us.
AS> [snip]
>> 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.
AS> Here's where I don't get it. Let's go back to the simple original example
AS> with my one-class bundle which depended on commons-logging. If the plugin
AS> would embed or inline the commons-logging jar AND generate Import-Package
AS> statements... that would break when we load it into the OSGi framework,
AS> right? No other bundle will export commons-logging stuff and, moreover, even
AS> if there is I want my bundle to use the embedded stuff like I said in my POM.
AS> This is the core of the issue, as I see it.
AS> Cheers,
AS> -EE
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
RE: Re[4]: Bundle plugin: Importing packages from non-bundles
Posted by Aaron Siri <Aa...@efi.com>.
I was going to start asking similar questions. I'm wondering how I get my
dependencies packaged in the bundle (I prefer them as jars and not inlined.)
Does this thread imply that there is no way for library jars to be packaged
in the bundle using maven-bundle-plugin?
I'm also trying to get the plugin.xml file included into the bundle via:
<configuration>
<Include-Resource>plugin.xml</Include-Resource>
</configuration>
Which doesn't seem to be working. Is this the right way to get it included?
-Aaron
-----Original Message-----
From: Emil Eifrém [mailto:emil@eifrem.com]
Sent: Tuesday, December 05, 2006 10:10 AM
To: Peter Kriens
Cc: felix-dev@incubator.apache.org
Subject: Re: Re[4]: Bundle plugin: Importing packages from non-bundles
On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
Neither am I, but it actually means exclude. From
http://maven.apache.org/pom.html:
--- >8 ---
* scope: This element refers to the classpath of the task at hand (compiling
and runtime, testing, etc.) as well as how to limit the transitivity of a
depedency. There are five scopes available:
* compile - this is the default scope, used if none is specified.
Compile dependencies are available in all classpaths.
* 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.
* runtime - this scope indicates that the dependency is not required for
compilation, but is for execution. It is in the runtime and test classpaths,
but not the compile classpath.
* test - this scope indicates that the dependency is not required for
normal use of the application, and is only available for the test compilation
and execution phases.
* system - this scope is similar to provided except that you have to
provide the JAR which contains it explicitly. The artifact is always
available and is not looked up in a repository.
--- >8 ---
>
>
> 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.
Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
I just want stuff to work so I can build apps. :) But this is an Apache list,
I'm sure others can chime in!
What I meant in my previous mail was that I don't understand why the plugin
needs to know the <type> of the dependencies. It's an OSGi-aware plugin...
just have a peek in the jar file and figure it out? If it is, then generate
Import-Package, if not then embed or inline it. Would work nicely. But maybe
there's some Maven core <-> Maven plugin interaction going on there that I'm
missing. In either case, this would be nice-to-have functionality but it's
not a showstopper for us.
[snip]
> 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.
Here's where I don't get it. Let's go back to the simple original example
with my one-class bundle which depended on commons-logging. If the plugin
would embed or inline the commons-logging jar AND generate Import-Package
statements... that would break when we load it into the OSGi framework,
right? No other bundle will export commons-logging stuff and, moreover, even
if there is I want my bundle to use the embedded stuff like I said in my POM.
This is the core of the issue, as I see it.
Cheers,
-EE
Re: Re[4]: Bundle plugin: Importing packages from non-bundles
Posted by Emil Eifrém <em...@eifrem.com>.
On 12/5/06, Peter Kriens <Pe...@aqute.biz> 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?
Neither am I, but it actually means exclude. From
http://maven.apache.org/pom.html:
--- >8 ---
* scope: This element refers to the classpath of the task at hand
(compiling and runtime, testing, etc.) as well as how to limit the
transitivity of a depedency. There are five scopes available:
* compile - this is the default scope, used if none is specified.
Compile dependencies are available in all classpaths.
* 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.
* runtime - this scope indicates that the dependency is not
required for compilation, but is for execution. It is in the runtime
and test classpaths, but not the compile classpath.
* test - this scope indicates that the dependency is not required
for normal use of the application, and is only available for the test
compilation and execution phases.
* system - this scope is similar to provided except that you have
to provide the JAR which contains it explicitly. The artifact is
always available and is not looked up in a repository.
--- >8 ---
>
>
> 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.
Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
I just want stuff to work so I can build apps. :) But this is an
Apache list, I'm sure others can chime in!
What I meant in my previous mail was that I don't understand why the
plugin needs to know the <type> of the dependencies. It's an
OSGi-aware plugin... just have a peek in the jar file and figure it
out? If it is, then generate Import-Package, if not then embed or
inline it. Would work nicely. But maybe there's some Maven core <->
Maven plugin interaction going on there that I'm missing. In either
case, this would be nice-to-have functionality but it's not a
showstopper for us.
[snip]
> 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.
Here's where I don't get it. Let's go back to the simple original
example with my one-class bundle which depended on commons-logging. If
the plugin would embed or inline the commons-logging jar AND generate
Import-Package statements... that would break when we load it into the
OSGi framework, right? No other bundle will export commons-logging
stuff and, moreover, even if there is I want my bundle to use the
embedded stuff like I said in my POM. This is the core of the issue,
as I see it.
Cheers,
-EE