[slf4j-dev] Rearranging classes

[John E. Conlon]

Ceki Gülcü wrote:
> 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. :-)
>
>   
Will need to change release to 1.3.0-SNAPSHOT on parent pom.xml.  Okay?
John