[slf4j-dev] Rearranging classes

[John E. Conlon]

Ceki Gülcü wrote:
> At 09:07 PM 2/4/2007, John E. Conlon wrote:
>   
>> Ceki Gülcü wrote:
>>     
>
> [snip]
>
>   
>>> I propose that we include LoggerFactory in slf4j-api.jar. I think this 
>>>       
>> will
>>     
>>> further improve our OSGi-friendliness, because we won't need to export
>>> partial packages in our OSGi manifests as we currently do.
>>>
>>>       
>> Can we also likewise move the MarkerFactory to the sl44j-api.jar?
>>     
>
> Good idea.
>
> [snip]
>
>   
>> If there were a slf4j-api.jar bundle and a slf4j-nop.jar (or a
>> slf4j-log4j12.jar...) in an OSGi runtime than the slf4j-api.jar would
>> only need to export the org.sl4j package for user bundles  to import,
>> but it would have to import the org.slf4j.impl package from one of the
>> binding bundle impls.
>>     
>
> Yes. Trying to summarize, we would have:
>
> slf4j-api
> =========
> Export-Package: org.slf4j, org.slf4j.helpers
> Import-Package: org.slf4j.impl
>
> slf4j-<impl>
> ============
> Export-Package: org.slf4j.impl
> Import-Package: org.slf4j, org.slf4j.helpers
>
> Do you concur with my summary? 
Yes.
> There would be a cyclical dependence between 
> the two jars. 
This coupling is what got me thinking about the build time copying of 
packages I suggested using the plugin.
> Do you think that could be a problem?
>   
Potential concern(S) if we went with this approach. 
1.  Would we have a build problem with this?  Which project would be 
first to build?

2.  Would like to test it in all the OSGi frameworks to make sure both 
bundles would resolve. 
BTW -  I currently have a test environment based on Spring-OSGi ready to 
go that is using the current  layout with Require-Bundle. (It is just 
not committed yet. I will wait for you to proceed with the refactoring 
of packages.)



>   
>> So a minimal slf4j OSGi scenario would require at least two bundles the
>> slf4j-api.jar and an binding implementation bundle.
>>     
>
> Yep.
>
>   
>>> packages and the bindings (e.g. slf4j-nop, slf4j-log4j12, etc) would 
>>>       
>> export
>>     
>>> org.slf4j.impl package.
>>>       
>
> Yep.
>
>   
>> Great, no more 'split packages'.
>>     
>>> I'd like to emphasize that all these changes should be transparent to our
>>> end-users.
>>>
>>>       
>> Right the user bundles will still only import org.sl4j.
>>     
>
> Indeed.
>
>   
>> Agree with the above package refactorings, not only do they remove the
>> split packages, I think they make the api easier to understand as well.
>>
>> In addition to these I would like to pose  three other techniques that
>> could help ease issues with administration and management for us as
>> developers and offer more agility for OSGi system administrators as well.
>>
>> 1.  Don't offer our slf4j-api.jar as an OSGi bundle! ( This is radical
>> but bear with me...)
>>     
>
> If I understand you correctly, the slf4j-api.jar file would still be 
> constructed. Correct?
>   
Yes.  The slf4j-api project stays the same. (We just remove the OSGi files.)
>   
>> 2.  Use the org.apache.felix maven-bundle-plugin (This is based on Peter
>> Kreins Bnd tool) to craft our other projects as bundles.  (This gets rid
>> of maintaining a separate Manifest.mf files as everything is in the pom.xml)
>>
>> 3.  The maven-bundle-plugin also will allow us to add packages from the
>> classpath to the jar/bundle it creates. This is how we get the org.slf4j
>> package in our binding jar/bundles.  So when we build our binding
>> projects to create a bundle/jar (nop,simple,...) we instruct the plugin
>> to include the org.slf4j package in each of them.  These binding jar
>> bundles then would only export the org.slf4j package.  All other
>> packages would be private and not exported.
>>     
>
> If slf4j-api.jar is included within slf4j-<impl>.jar, wouldn't this be an 
> OSGi-only solution?
>   
No slf4j-api.jar would not be copied, but the classes themselves would 
be copied into the slf4j-<impl>.jar. 
Non-OSGi users would have fully functional log impls jars that would 
also be offering the org.slf4j classes.  Only now they would need just 
one jar instead of two.
>
>   
>> Benefits
>> Less files easier to maintain.
>>
>> Encapsulates our implementation packages.
>>
>> Minimal slf4j OSGi scenario would require only one bundle, which would
>> be a choice of one of the binding implementation bundles.
>>
>> More complicated slfj OSGi scenarios would allow for the installation of
>> multiple binding bundles in one OSGi runtime.  With client bundles bound
>> to their choice of binding bundles.   Client bundles that did not care
>> which binding would then only need to import org.slf4j.  Others that
>> wanted a specific binding could use something like
>> Import-Package: org.slf4j;bundle-symbolic-name=slf4j.simple
>> which would only bind that client bundle to a slf4j.simple bundle.
>>     
>
> Nice.
>
>   
>> Non OSGi projects would now only need to specify the bindings jar dep
>> they needed instead of adding both it and the slf4j-api.jar to their
>> maven deps.
>>     
>
> I'd need to see maven-bundle-plugin in action.
>
> Given that you seem to support the rearrangement, let me start with that. 
> We can build on top of those changes to integrate steps 2 and 3 you outlined.
>
> How does that sound?
>   
I am having second thoughts about the refactoring the packages.  Because 
of the Build issues I suspect we will have.

Alternative idea:
What if we did NOT do the refactorings at all?!
Just use the plugin to do the class copying with the packages and 
classes as they are now?... Wait let me try this...

Yep that works!
Tested this (in the testsuite that I mentioned above) and it works. Here 
is what the slf4j-simple pom.xml build looks like using the plugin:
<build>
        <plugins>   
        <plugin>
              <groupId>org.apache.felix</groupId>
              <artifactId>maven-bundle-plugin</artifactId>
              <extensions>true</extensions>
              <configuration>
                  <instructions>
                      <Export-Package>org.slf4j;version=1.3</Export-Package>
                      <Private-Package>org.slf4j.impl, 
org.slf4j.spi</Private-Package>
                      <Import-Package>!org.slf4j.*</Import-Package>
                  </instructions>
              </configuration>
          </plugin>
    </plugins>
</build>

Integration Test:
OSGi Integration test are deploying:
"org.slf4j"; "slf4j-simple",
"org.slf4j";"jcl104-over-slf4j",
"org.slf4j"; "slf4j-osgi-test-bundle",

All bundles resolve (finding all imports and exports),
Note: the slf4j-osgi-test-bundle uses both org.slf4j and jcl logging.


Summary:
No changes to classes, all projects are the same except fewer number of 
files.
No manifest.mf files,
The slf4j-simple.jar contains the superset of classes in org.slf4j and 
org.slffj.impl from both the slf4j-api.jar and its own jar.
   (This will be the same for all the bindings jars.)

If you like I can do the modifications to all the projects as suggested 
above, or
I can wait for you ( if you do not see a problem with the cyclical deps 
for the builds  and want to do the refactoring).

kind regards,
John