Martin Aspeli wrote:
>> > I assume this applies to base and extension profiles equally, then?
>> > So, it won't re-run the base CMFPlone profiles 'types.xml' if we
>> > activate Poi as an extension profile, nor will it re-run
>> > RichDocument's types.xml even if RichDocument was the previously
>> > installed/activated profile?
>> Correct.

Hhm, I was just looking into this in detail, but it's good to get my
suspicion verfied. I will write a test for it anyways ;)

> Rarely so happy be wrong :)
> So if we had a procedural way of doing uninstall/cleanup where it was
> necessary, I think we'd be pretty close with Hanno's QI branch. Yay :)

We have. As Alec pointed out the usual hooks of QI are still working, so
you can still use an Extensions.Install.uninstall to do any manual
cleanup you want.

I should note that I put the checks for extension profile based
installation after the ones based on external methods, so the external
method always wins and the new approach is only used if you have no
Extensions.Install.install method at all.

My hope right now is that with the new QI feature of extension profile
support (which works fine under Plone 2.5 as well) we could finally tell
Add-on product developers to use GenericSetup. Maybe we could include
this even in a minor release of Plone 2.5.x to enable people to switch
now, but at least for Plone 3.0 we need it to be able to deprecate the
old mechanism from Archetypes.

Of course we still need to fix the current Archetypes mechanism to work
with CMF 2.1. As we havn't deprecated it yet, we cannot brake it.

So for Plone 3.0 (or maybe 2.5.2 as well) we would have both traditional
AT-based and new GS-based installation support with deprecation warnings
for the AT-based one.


Framework-Team mailing list

Reply via email to