commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Date Fri, 22 Feb 2013 20:47:34 GMT
On 02/22/2013 08:17 PM, Benedikt Ritter wrote:
> 2013/2/22 Thomas Neidhart <thomas.neidhart@gmail.com>
> 
>> On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
>>> Hi Thomas,
>>>
>>>
>>> 2013/2/22 Thomas Neidhart <thomas.neidhart@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 tn@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message