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. HTH, Benedikt [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf [2] http://semver.org [3] http://wiki.osgi.org/wiki/DynamicImport-Package Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
