You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Heger <ol...@oliver-heger.de> on 2013/02/20 21:33:37 UTC
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
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?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/23/2013 05:53 PM, Benedikt Ritter wrote:
> Christian Schneider from the felix project has posted some useful
> information to the felix dev ML [1].
> Maybe we should just add document for using JCL in OSGi (via pax logging
> for example) to the website?
Thanks, sounds like a good plan.
I have also no interest to dive more into OSGi atm, and if there is a
working solution we should document it.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Benedikt Ritter <br...@apache.org>.
Christian Schneider from the felix project has posted some useful
information to the felix dev ML [1].
Maybe we should just add document for using JCL in OSGi (via pax logging
for example) to the website?
Benedikt
[1] http://www.mail-archive.com/dev%40felix.apache.org/msg28887.html
2013/2/22 Benedikt Ritter <br...@apache.org>
>
>
>
> 2013/2/22 Thomas Neidhart <th...@gmail.com>
>
>> On 02/22/2013 08:17 PM, Benedikt Ritter wrote:
>> > 2013/2/22 Thomas Neidhart <th...@gmail.com>
>> >
>> >> On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
>> >>> Hi Thomas,
>> >>>
>> >>>
>> >>> 2013/2/22 Thomas Neidhart <th...@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).
>>
>
> The generated MANIFEST looks better. I still wonder if we have to export
> the impl package. Users should never use Log implementations directly,
> right? So there is no need to export the impl package, I guess.
>
> I'm wondering if we get problems with all the classloader and
> Class.forName stuff LogFactory and LogFactoryImpl do... Because there is no
> flat classpath that contains all classes in OSGi, it is not recommended to
> use this facilities in an OSGi environment.
>
> For example: if a bundle contains a commons-logging.properties can the
> [logging] bundle classloader discover this resource? Maybe you can add a
> properties file to your example bundle and test this.
>
>
>>
>> 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
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Benedikt Ritter <br...@apache.org>.
2013/2/22 Thomas Neidhart <th...@gmail.com>
> On 02/22/2013 08:17 PM, Benedikt Ritter wrote:
> > 2013/2/22 Thomas Neidhart <th...@gmail.com>
> >
> >> On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
> >>> Hi Thomas,
> >>>
> >>>
> >>> 2013/2/22 Thomas Neidhart <th...@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).
>
The generated MANIFEST looks better. I still wonder if we have to export
the impl package. Users should never use Log implementations directly,
right? So there is no need to export the impl package, I guess.
I'm wondering if we get problems with all the classloader and Class.forName
stuff LogFactory and LogFactoryImpl do... Because there is no flat
classpath that contains all classes in OSGi, it is not recommended to use
this facilities in an OSGi environment.
For example: if a bundle contains a commons-logging.properties can the
[logging] bundle classloader discover this resource? Maybe you can add a
properties file to your example bundle and test this.
>
> 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
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/22/2013 08:17 PM, Benedikt Ritter wrote:
> 2013/2/22 Thomas Neidhart <th...@gmail.com>
>
>> On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
>>> Hi Thomas,
>>>
>>>
>>> 2013/2/22 Thomas Neidhart <th...@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
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Benedikt Ritter <be...@gmail.com>.
2013/2/22 Thomas Neidhart <th...@gmail.com>
> On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
> > Hi Thomas,
> >
> >
> > 2013/2/22 Thomas Neidhart <th...@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.
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@gmail.com>.
On 02/22/2013 05:50 PM, Benedikt Ritter wrote:
> Hi Thomas,
>
>
> 2013/2/22 Thomas Neidhart <th...@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?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Benedikt Ritter <br...@apache.org>.
Hi Thomas,
2013/2/22 Thomas Neidhart <th...@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.
Benedikt
>
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 22.02.2013 17:43, schrieb Thomas Neidhart:
> 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
It is said that the maven-bundle-plugin could determine optional
dependencies automatically based on optional attributes in the maven
dependencies. However, when I tried this the last time - about half a
year ago - I could not get this to work.
The pom for [configuration] can be used as an example for an alternative
approach. It declares a number of optional dependencies explicitly. This
is done by setting the commons.osgi.import property (which is evaluated
by the configuration of the maven-bundle-plugin inherited from the
parent pom).
Oliver
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@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
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@gmail.com>.
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?
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@gmail.com>.
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?
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Jörg Schaible <jo...@gmx.de>.
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.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1448251 - /commons/proper/logging/trunk/src/conf/MANIFEST.MF
Posted by Thomas Neidhart <th...@gmail.com>.
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?
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.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org