[slf4j-dev] Rearranging classes

[Ceki Gülcü]

At 11:35 PM 2/5/2007, John E. Conlon wrote:
[snip]

> > 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?

D'oh. You are of course right. I can't believe I missed this.

We could get slf4j-api to compile by providing a bogus project providing 
the classes needed. However, the approach does not seem very elegant and I 
can't think of anything better.

>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.)

No, no. It was a half-baked idea.

[snip]

> > 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.

> > 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).

Go for it. :-)


>kind regards,
>John

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