[slf4j-dev] svn commit: r735 - in slf4j/trunk: . slf4j-osgi-test-bundle

[Ceki Gülcü]

At 08:06 PM 2/18/2007, John E. Conlon wrote:
>There are  two problems with using the spring osgi testing project
>snapshots for slf4j testing.
>
>1. Volatility of spring-osgi snapshots.
>  This is the primary reason I at did not initially include the
>spring-osgi testing projects in our parent build.
>
>Ceki, we had similar problems at Apache Directory and I am afraid these
>problems may be related to the changes happening to the spring-osgi apis
>and the intermittent deployment to the repos.  Perhaps I was wrong to
>add the osgi testing project before the spring-osgi stabilized?

As long as building the osgi-specific modules depend on a specific profile, 
I don't see why we shouldn't attempt to test SLF4J's OSGi functionality.

>I thought it best to have some testing visibility at least done somewhere
>regarding the osgi functionality of the bundles.  Allow me to
>investigate further and respond over the next few days with more details
>and recommendations.

I fully agree with your assessment. The goal of my previous message was to 
inform you about the problems I encountered with the various osgi-related 
modules. The current situation is fine with me.

>For now take a look at the artifacts that you couldn't load from repos.
>They are not only spring-osgi built artifacts they are sl4fj
>implementations too!

:-)

>org.springframework.osgi:jcl104-over-slf4j.osgi:jar:1.1.0
>org.slf4j:slf4j-log4j-full:jar:1.1.0
>
>This brings me to the second problem.
>
>2. Spring-OSGi uses slf4j internally, so we are faced with a potential
>problem of mixing slf4j code from the Spring-OSGi testing environment
>with the releases we are testing.  Interesting problem huh?  How can we
>keep different sl4fj versions from mixing in the OSGi runtime and
>invalidating our tests?  Actually this is sort of a good problem to be
>faced with, as it sets a standard for testing and building osgi bundles
>that we should be upholding anyway - the exportation of packages with
>version metadata and the importation of packages with version-range
>metadata.
>
>If you noticed in our binding project poms:
><Export-Package>
>                               org.slf4j;version=1.3,
>org.slf4j.spi;version=1.3
></Export-Package>
>
>and in our client project poms:
><Import-Package>
>         org.slf4j;version="[1.3,1.4)", org.slf4j.spi;version="[1.3,1.4)"
></Import-Package>
>
>These metadata attributes will insure that we only are testing (and
>latter for deployment) utilizing the proper release of slf4j and are not
>picking up the spring-osgi sl4fj.

Given my level of knowledge about the spring-osgi module, I am afraid I 
can't make an intelligent comment, except saying the problem is quite 
interesting.


>cheers,
>John

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch