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