On 02/22/2013 08:17 PM, Benedikt Ritter wrote: > 2013/2/22 Thomas Neidhart <thomas.neidh...@gmail.com> > >> On 02/22/2013 05:50 PM, Benedikt Ritter wrote: >>> Hi Thomas, >>> >>> >>> 2013/2/22 Thomas Neidhart <thomas.neidh...@gmail.com> >>> >>>> On 02/22/2013 05:35 PM, Thomas Neidhart wrote: >>>>> On 02/22/2013 05:09 PM, Thomas Neidhart wrote: >>>>>> On 02/20/2013 09:48 PM, Jörg Schaible wrote: >>>>>>> Hi Thomas, >>>>>>> >>>>>>> Thomas Neidhart wrote: >>>>>>> >>>>>>>> On 02/20/2013 09:33 PM, Oliver Heger wrote: >>>>>>>>> Am 20.02.2013 16:42, schrieb t...@apache.org: >>>>>>>>>> Author: tn >>>>>>>>>> Date: Wed Feb 20 15:42:09 2013 >>>>>>>>>> New Revision: 1448251 >>>>>>>>>> >>>>>>>>>> URL: http://svn.apache.org/r1448251 >>>>>>>>>> Log: >>>>>>>>>> Update version info >>>>>>>>>> >>>>>>>>>> Modified: >>>>>>>>>> commons/proper/logging/trunk/src/conf/MANIFEST.MF >>>>>>>>>> >>>>>>>>>> Modified: commons/proper/logging/trunk/src/conf/MANIFEST.MF >>>>>>>>>> URL: >>>>>>>>>> >>>>>>> >>>> >> http://svn.apache.org/viewvc/commons/proper/logging/trunk/src/conf/MANIFEST.MF?rev=1448251&r1=1448250&r2=1448251&view=diff >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>> >> ============================================================================== >>>>>>>>>> >>>>>>>>>> --- commons/proper/logging/trunk/src/conf/MANIFEST.MF (original) >>>>>>>>>> +++ commons/proper/logging/trunk/src/conf/MANIFEST.MF Wed Feb 20 >>>>>>>>>> 15:42:09 2013 >>>>>>>>>> @@ -5,4 +5,4 @@ Specification-Version: 1.0 >>>>>>>>>> Implementation-Title: Commons Logging >>>>>>>>>> Implementation-Vendor-Id: org.apache >>>>>>>>>> Implementation-Vendor: Apache Software Foundation >>>>>>>>>> -Implementation-Version: 1.1.1 >>>>>>>>>> +Implementation-Version: 1.1.2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Just wondering whether this is necessary. Doesn't the maven build >>>>>>>>> automatically generate a fully configured MANIFEST including OSGi >>>> meta >>>>>>>>> data? >>>>>>> >>>>>>> wondered about exactly the same. >>>>>>> >>>>>>>> >>>>>>>> yes, but somehow the ant build script is still in use (e.g. for >> gump) >>>>>>>> and both ant & maven refer to this hard-coded manifest. >>>>>>> >>>>>>> If Gump uses Ant here, this is just for historical reasons. Gump can >>>> use >>>>>>> Maven since quite some time now. >>>>>> >>>>>> Ok, when I try to remove the hard-coded manifest, the >>>>>> maven-bundle-plugin steps in and automatically creates one. >>>>>> >>>>>> This is fine, but the Import-Package contains all (optional) >>>>>> dependencies which are not marked like that. >>>>>> >>>>>> I am not so familiar with these things, does somebody know how to >>>>>> specify this? >>>>>> >>>>>> Or would this not work at all, as already outlined in LOGGING-124? >>>>> >>>>> After some research, I started with this: >>>>> >>>>> <plugin> >>>>> <groupId>org.apache.felix</groupId> >>>>> <artifactId>maven-bundle-plugin</artifactId> >>>>> <inherited>true</inherited> >>>>> <configuration> >>>>> <instructions> >>>>> <Import-Package>*;resolution:=optional</Import-Package> >>>>> <DynamicImport-Package>*</DynamicImport-Package> >>>>> </instructions> >>>>> </configuration> >>>>> </plugin> >>>>> >>>>> All dependencies are optional, so this should be fine. >>>>> I added the DynamicImport but this may be to generic, and has to be >>>>> limited to the actual packages that are loaded dynamically by the >>>>> discovery process. >>>>> >>>>> Can anybody provide me with a simple test bundle to see if logging >> would >>>>> work when loaded in e.g. apache felix? >>>> >>>> Well, I have not yet a clue about osgi, and I see that felix has >>>> re-bundled commons-logging in a total different way: >>>> >>>> >> http://svn.apache.org/repos/asf/felix/trunk/commons/commons-logging/pom.xml >>> >>> >>> I have some experience with osgi (although I'm no expert either ;-). I >> can >>> have a look tonight when I'm at home. We can also ask the felix ML. They >>> have been supportive with OSGi meta data. >> >> ok thanks, >> >> another thing I have found as comment in LOGGING-124: >> >> Spring seems to rebundle commons-logging with proper meta data. >> >> see >> >> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.logging&version=1.1.1&searchType=bundlesByName&searchQuery=logging >> >> Using these settings from their manifest into our pom: >> >> <commons.osgi.import> >> javax.servlet;version="[2.1.0, 3.0.0)";resolution:=optional, >> org.apache.avalon.framework.logger;version="[4.1.3, >> 4.1.5]";resolution:=optional, >> org.apache.log;version="[1.0.1, 1.0.1]";resolution:=optional, >> org.apache.log4j;version="[1.2.15, 2.0.0)";resolution:=optional >> </commons.osgi.import> >> >> Does anybody have experience with using this spring bundle and whether >> this works? >> >> Reading all theses (negative) threads about osgi and commons-logging >> makes me wonder if this is really still valid with version 1.1+? >> >> Lots of things have changed, and there are several bundles of >> commons-logging from other sources (spring, felix), so I guess it will >> work? >> >> > I'm at home now and have started logging through the build config. > There are a few things about OSGi that one should know. > OSGi defines special meta data for bundles that allow an OSGi framework to > start a bundle in different versions. This means, that the class > com.example.MyClass can be loaded several times in an OSGi framework by > different class loaders. > For this to work there are some requirements: > - Bundles have to define a versionin a well defined form (called semantic > versioning [1,2]) > - Bundles have to tell the OSGi framework what they provide for other > bundles (this is what can be expressed in the bundle Export-Package header) > - Bundles have to tell the OSGi framework what they need to be resolved > (this is what can be expressed in the bundle Import-Package header) > > Now looking at what you have posted so far I can see that: > > Without changes to trunk: > - the version number looks valid although. I'm not sure about the > ".SNAPSHOT" part, but this will be snipped for the release. > - we will export the impl package. There is no need to export this package > as it is internal. Users should always use the interfaces defined in > o.a.c.logging (right?). Not exporting this package means, that no other > bundle can use for example o.a.c.l.impl.AvalonLogger directly. > - we import everthing we have defined a import in one of our classes. This > means that even if a user decides to use [logging] together with Log4J he > will have to provide javax.servlet, avalon, o.a.log and o.a.log4j > > With the configuration you proposed for [logging] > - we have defined a DynamicImport [3]. I don't think this is necessary, > because we know what optional dependecies we have. > - we still export the impl package > - we have marked all imports as optional (I think this is correct) > > What is missing: > - I think we should add version info to our imports like spring does > > Thinks I unsure about: > - do we have to export the impl package? Spring does this. Looks like they > do this to define that thie package is using the optinonal dependencies.
I updated the pom with the bundle data I posted before (should also be available from snapshot repository). I did a very simple test with it: * create an example that uses commons-logging as log device * install apache felix * install the commons-logging bundle * install my example bundle * start the example bundle -> logging works so it seems to work, although this was just a very simple example. Maybe other people can do more tests? btw. I had to add a definition for the fulljar to the maven-jar-plugin, as otherwise the last definition there was used to deploy the project jar: * before adaptersjar was the last definition * the adapters jar was used to deploy the project jar, see output below: [INFO] Installing /home/tn/workspace/apache/logging/target/commons-logging-adapters-1.1.2-SNAPSHOT.jar to /home/tn/.m2/repository/commons-logging/commons-logging/1.1.2-SNAPSHOT/commons-logging-1.1.2-SNAPSHOT.jar Weird. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
