forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Date Tue, 19 Feb 2008 10:50:09 GMT
Ferdinand Soethe wrote:
> Thorsten Scherler wrote:
>> On Mon, 2008-02-18 at 11:44 +0000, Ross Gardler wrote:
>>> Ferdinand Soethe wrote:
>>>> The pdf-plugin will not work with 0.8 as is because it was decided 
>>>> to move critical libs from the plugin back into core.
>>> I must have missed that. Why were they moved back in? 
>>
>> I think there was a misunderstanding.
>>
>> commons-io-1.3.1.jar -> should go into the plugin (because other code
>> does not seem to need it)
>>
>> commons-logging-1.1.1.jar -> tricky since in 08 we have
>> commons-logging-1.0.4.jar
>>
>>
>> xmlgraphics-commons-1.2.jar -> not in 0.8 but needed by the plugin
>> (should go into the plugin)
>>
> 
> No misunderstanding as far as I can tell.
> In the message http://marc.info/?l=forrest-dev&w=2&r=1&s=r618371&q=b
> you wrote
> 
>> That should not include common libs:
> 
> [...]
> 
>> The following needs to be in core:
>>
>>> Removed:
>>> forrest/branches/UpdateFOPto094/lib/core/commons-io-1.3.1.jar
>>> forrest/branches/UpdateFOPto094/lib/core/commons-logging-1.1.1.jar
>>> forrest/branches/UpdateFOPto094/lib/core/xmlgraphics-commons-1.2.jar
> 
> and so I moved these libs back into core.
> 
> And I think they should remain there now because _current common use_ is 
> not really a useful criterion for placement of these libs. Somewhere 
> along that road we'd start moving libs back into core when the next 
> plugin requires them.

Not if we get out act together and use IVY to retrieve libs. In this 
case not neither core nor plugins would require libs to be bundled.

> Your earlier approach makes a lot more sense to me. Place all libs that 
> could be of a common use in lib/core right away.

-0

I think that to have your FOP enhancements available in 0.8 without user 
intervention is important.

If I had the time to do the IVY migration I'd be -1 on the above, but 
I'm not sure I have the time right now - hence only a -0

>> IMO the plugin should work in 0.8 if the libs go back. We can release
>> the plugin in version 0.3  (compatible with 0.8) and then raise the
>> version to 0.4.
> 
> So I propose to _copy_ the missing libs into the plugin, publish it as 
> 0.3 requiring Forrest 0.8, then remove the libs from the plugin and 
> publish it as 0.4 requiring Forrest 0.9.

+1

> The only weak spot in proceeding like this is the difficulty of doing 
> bugfixes (which are certainly to be expected) in the 0.3 version.

Be sure to tag 0.3 and, if necessary, we can branch it for bug fixes.

> Ross: Is there really no way of maintaining two versions of a plugins 
> sources in our svn? We'd really need it in this case!

That's what branches are for.

Ross

Mime
View raw message