Return-Path: Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org Received: (qmail 89836 invoked from network); 5 Dec 2006 22:39:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Dec 2006 22:39:08 -0000 Received: (qmail 12557 invoked by uid 500); 5 Dec 2006 22:39:16 -0000 Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org Received: (qmail 12524 invoked by uid 500); 5 Dec 2006 22:39:15 -0000 Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: felix-dev@incubator.apache.org Delivered-To: mailing list felix-dev@incubator.apache.org Received: (qmail 12513 invoked by uid 99); 5 Dec 2006 22:39:15 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Dec 2006 14:39:15 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=BIZ_TLD,SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [217.160.230.41] (HELO mout.perfora.net) (217.160.230.41) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Dec 2006 14:39:04 -0800 Received: from [75.21.241.89] (helo=[10.0.1.3]) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1Grivx1zMV-00043e; Tue, 05 Dec 2006 17:38:43 -0500 Mime-Version: 1.0 (Apple Message framework v624) In-Reply-To: <87F7A09D4DAF4C46A1EC7BFBF85047F3020E4D5F@pghexmb02.efi.internal> References: <1231377400.20061204075439@aQute.biz> <1128149406.20061205092749@aQute.biz> <1792889260.20061205154929@aQute.biz> <87F7A09D4DAF4C46A1EC7BFBF85047F3020559D2@pghexmb02.efi.internal> <57129481.20061205184535@aQute.biz> <87F7A09D4DAF4C46A1EC7BFBF85047F3020E4C80@pghexmb02.efi.internal> <4575C0A9.8080503@ungoverned.org> <87F7A09D4DAF4C46A1EC7BFBF85047F3020E4C99@pghexmb02.efi.internal> <4575C3B5.4070007@ungoverned.org> <87F7A09D4DAF4C46A1EC7BFBF85047F3020E4CB0@pghexmb02.efi.internal> <4575CC3A.1000005@ungoverned.org> <87F7A09D4DAF4C46A1EC7BFBF85047F3020E4CDD@pghexmb02.efi.internal> <4575D5F4.1030403@ungoverned.org> <87F7A09D4DAF4C46A1EC7BFBF85047F3020E4D0C@pghexmb02.efi.internal> <4575E0EF.1000502@ungoverned.org> <87F7A09D4DAF4C 46A1EC7BFBF85047F3020E4D5F@pghexmb02.efi.internal> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8de07c6ed6e9d207baae777948cb1804@ungoverned.org> Content-Transfer-Encoding: quoted-printable From: Richard S. Hall Subject: Re: Bundle plugin: Importing packages from non-bundles Date: Tue, 5 Dec 2006 17:29:54 -0500 To: felix-dev@incubator.apache.org X-Mailer: Apple Mail (2.624) X-Provags-ID: perfora.net abuse@perfora.net login:b399c17105f59dfa36985f08f30e623d X-Virus-Checked: Checked by ClamAV on apache.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=20= > bundle > and including them in your own bundle (instead of depending on the=20 > bundle at > runtime). Now this seems anti-OSGi :) Not at all anti-OSGi...the OSGi framework automatically deals with=20 multiple providers of the same package (in my example the Log Service=20 exports the log package). The spec used to recommend packaging a bundle=20= with its interfaces...I am not sure if it still does or not, but it is=20= definitely not anti-OSGi. To me, using Require-Bundle for dependencies is the anti-OSGi thing to=20= do, but that is a whole other debate. > You don't seem to be using the bundle as a bundle, but rather as a=20 > simple, > but very big, third party library (i.e. bunch of class files.) Yeah -=20= > it's > self contained, but doesn't really take advantage of the modular=20 > nature of > the OSGi infrastructure. However, I don't know the details of the=20 > bundles > you are talking about and assume there are good reasons for doing it=20= > the way > you are. Nowhere did I say that you should do this for every dependency you=20 have, but only for the ones that it makes sense. For the rest, you let=20= the plugin generate Import-Package declarations and it is all=20 automatic. > But, the case you made seems to only really make sense for poorly=20 > designed > bundles (as this compendium bundle seems to be - including a logging=20= > API that > can't be separated from the rest) I'd hope the maven plugin is=20 > designed with > such a situation as the exception instead of the rule. Either you=20 > depend on > compendium or you don't. In your case the answer is "Sort of. I drag=20= > what I > need into my own bundle." > > I'm trying to target the 80% that are using the plugin like they use=20= > all > other maven plugins. Via the POM I've expressed what the dependencies=20= > 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=20 > instructions. If that is your definition of poorly designed, then I guess nearly all=20= JAR files are poorly designed judging by the amount of stuff that gets=20= downloaded by Maven for any simple operation. Pulling in 20MB of stuff=20= to compile a "hello world" program does scream "poor design", but it is=20= not the "hello world" program that is poorly designed. Rarely any JAR file is perfectly cohesive and as a result dependencies=20= on a JAR file are generally going to pull in too much. > As a start, I'd suggest that a instruction is=20 > added. You > can specify "" (do what it does today), or actual packages/jars.=20= > 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=20 > 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=20 > that you > want the process automated; we all do, which is why we have a plugin.=20= > What I > don't understand is whether it is a requirement that you want the JAR=20= > file > embedded or if inlining of the JAR is acceptable. > > I am asking this question to get a better understanding of how=20 > possibly to > devise a solution. > >> With all due respect, having to specify the >> 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=20= > 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=20 > 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=20= > 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=20 > situation > other than copying the Log Service package source code from the=20 > compendium > project into my Log Service project. The downside of this approach is=20= > 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=20= > 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=20= > handy if > you ask me. > > I can see the other side to the argument too, so we just have to think=20= > 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 >>> 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: >> >> org.dom4j.* >> >> 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=20 >>> 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=20 >>> 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 : >>>>>> >>>>>> >>>>>> >>>>>> plugin.xml >>>>>> >>>>>> >>>>>> >>>>>> And not >>>>>> >>>>>> >>>>>> plugin.xml >>>>>> >>>>>> >>>>>> 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> >>>>>> AS> plugin.xml >>>>>> AS> >>>>>> >>>>>> 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=E9m [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 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=20 >>>>>> 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=20 >>>>>> repository. >>>>>> --- >>8 --- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> The bundle is required by maven as far as I know, >>>>>>>> as is the messy plugin setup. If you know a better way let me=20= >>>>>>>> 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 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>