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