You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <fe...@apache.org> on 2008/02/19 09:50:47 UTC
Placement of common libs (was Re: Decouple fo from skinconf (was
Re: svn commit: r618400 ))
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
Re: Placement of common libs (was Re: Decouple fo from skinconf (was
Re: svn commit: r618400 ))
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> David Crossley wrote:
>> Ferdinand Soethe wrote:
...
>>> - the create a branch pdf_plugin_03
>>
>> Why? We haven't created a branch for any other plugin.
>> Don't branch until we really need to.
>
> This was just to have the option of updating and releasing the plugin
> easily.
Why not do what I suggested. Tag the trunk and create a branch if we
need it.
>> Tagging the trunk is a good idea. We should add that
>> to our plugin development procedure howto doc.
>
> Does tagging mean that we mark the release where 0.3 changes to 0.4 and
> would be able to branch from there easily one there are updates to the
> stylesheets?
Yes, although if we want to be pedantic we are tagging the state 0.3
plugin was in when it was released.
SVN is a time machine. At any point you can go back in time and create a
branch from that moment. You do this with revision numbers. Tagging is
just a convenient was of marking important revisions.
Ross
Re: Placement of common libs (was Re: Decouple fo from skinconf (was
Re: svn commit: r618400 ))
Posted by Ferdinand Soethe <fe...@apache.org>.
David Crossley wrote:
> Ferdinand Soethe wrote:
>> OK, so I'll wait for Johannes to finish his tests, fix what
>> needs to be fixed then
>>
>> - copy the missing libs into the plugin, publish it as 0.3
>> requiring Forrest 0.8
>
> And deploy/release it before moving on with code.
yes, of course.
>> - the create a branch pdf_plugin_03
>
> Why? We haven't created a branch for any other plugin.
> Don't branch until we really need to.
This was just to have the option of updating and releasing
the plugin easily.
> It would be better to get moving with core 0.9 release.
From my own experience I think that people will not always
be able to follow us to a new release even if it was
released soon.
That's why I wanted to keep the option of updating the
plugin for 0.8
> Tagging the trunk is a good idea. We should add that
> to our plugin development procedure howto doc.
Does tagging mean that we mark the release where 0.3 changes
to 0.4 and would be able to branch from there easily one
there are updates to the stylesheets?
Best regards,
Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was Re: svn commit: r618400 ))
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
>
> OK, so I'll wait for Johannes to finish his tests, fix what
> needs to be fixed then
>
> - copy the missing libs into the plugin, publish it as 0.3
> requiring Forrest 0.8
And deploy/release it before moving on with code.
> - the create a branch pdf_plugin_03
Why? We haven't created a branch for any other plugin.
Don't branch until we really need to.
It would be better to get moving with core 0.9 release.
Tagging the trunk is a good idea. We should add that
to our plugin development procedure howto doc.
-David
> - then remove the libs from the plugin and publish it as 0.4
> requiring Forrest 0.9.
>
> Best regards,
> Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf
(was Re: svn commit: r618400 ))
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2008-02-21 at 18:13 +0100, Ferdinand Soethe wrote:
> Since Jeremias is about to release fop 0.95 with yet more
> significant improvements, I amend my proposal as follows
>
> Ferdinand Soethe wrote:
>
> > OK, so I'll wait for Johannes to finish his tests, fix what needs to be
> > fixed then
> >
> > - copy the missing libs into the plugin, publish it as 0.3
> > requiring Forrest 0.8
> >
> > - tag this state
> >
> > - then remove the libs from the plugin
> update fop to 0.95
> > and publish it as 0.4 dev
> > requiring Forrest 0.9.
>
> P.S.: Jeremias said that this update only requires an update
> of the lib itself. Wrapper and all the rest remain the
> same.
Perfect. Awesome work Jeremias, big compliment to you and the fop
community.
+1 for the proposal.
Thanks Ferdiand for taking the lead on this.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Placement of common libs (was Re: Decouple fo from skinconf (was
Re: svn commit: r618400 ))
Posted by Ferdinand Soethe <fe...@apache.org>.
Since Jeremias is about to release fop 0.95 with yet more
significant improvements, I amend my proposal as follows
Ferdinand Soethe wrote:
> OK, so I'll wait for Johannes to finish his tests, fix what needs to be
> fixed then
>
> - copy the missing libs into the plugin, publish it as 0.3
> requiring Forrest 0.8
>
> - tag this state
>
> - then remove the libs from the plugin
update fop to 0.95
> and publish it as 0.4 dev
> requiring Forrest 0.9.
P.S.: Jeremias said that this update only requires an update
of the lib itself. Wrapper and all the rest remain the
same.
Best regards,
Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf
(was Re: svn commit: r618400 ))
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Tue, 2008-02-19 at 12:00 +0100, Ferdinand Soethe wrote:
> OK, so I'll wait for Johannes to finish his tests, fix what
> needs to be fixed then
>
> - copy the missing libs into the plugin, publish it as 0.3
> requiring Forrest 0.8
>
> - the create a branch pdf_plugin_03
>
> - then remove the libs from the plugin and publish it as 0.4
> requiring Forrest 0.9.
+1
Thanks very much.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Placement of common libs (was Re: Decouple fo from skinconf (was
Re: svn commit: r618400 ))
Posted by Ferdinand Soethe <fe...@apache.org>.
OK, so I'll wait for Johannes to finish his tests, fix what
needs to be fixed then
- copy the missing libs into the plugin, publish it as 0.3
requiring Forrest 0.8
- the create a branch pdf_plugin_03
- then remove the libs from the plugin and publish it as 0.4
requiring Forrest 0.9.
Best regards,
Ferdinand Soethe
Re: Placement of common libs (was Re: Decouple fo from skinconf (was
Re: svn commit: r618400 ))
Posted by Ross Gardler <rg...@apache.org>.
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