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 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:[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 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
