forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Date Tue, 19 Feb 2008 08:50:47 GMT
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
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.

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.

> 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 

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.

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!

Best regards,
Ferdinand Soethe

View raw message