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.
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
