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 _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
