[Framework-Team] Re: 3.0 bundle broken?

[Martin Aspeli]

Hi Hanno,

On 11/22/06, Hanno Schlichting <plone at hannosch.info> wrote:
> Hi.
>
> /me is back from ten days of vacation in the southern parts of Spain
> without an Internet connection :)

Hope you had a good time!

> Martin Aspeli wrote:
> >> Same happend to me last night and I was too tired to debug this :-(
>
> I circumvented the problem for now, by pointing GenericSetup to an
> explicit older revision. The problem resulted from the merge of my
> GSLocalAddons product into GenericSetup by Jens Vagelpohl.

Annoying. In line with Alex's comments and my earlier ones, I'd say we
should not keep doing this (obviously) for longer than necessary.

> The exact problem is that we have an exportimport handler registered in
> GenericSetup itself for zope.component.interfaces.IComponentRegistry now
> and a second one in plone.app.portlets.

Then that's my fault for not thinking very far. plone.app.portlets
can't hog the only import handler for IComponentRegistry (specific vs.
generic...). We'll need to find a better way for plone.app.portlets to
import its stuff.

> This means we have two adapters registered for the exact same interface
> combination which isn't possible and results in a
> ConfigurationConflictError.

So how do we normally deal with this? I would've thought it'd be
possible to do more than one adapter on say, the portal root. Named
adapters?

The portlets import handler
(http://svn.plone.org/svn/plone/plone.app.portlets/trunk/plone/app/portlets/exportimport/portlets.py)
could just as well work on the portal root, but we'd obviously need
some way of disambiguating here as well.

> I'm not sure what the best way is to fix this problem properly :(

Me neither. At least we know what the problem is now. It really is
this call in the portlets import handler:

importObjects(sm, '', context)

which I presume does the adaptation of 'sm' to IBody, that needs to do
some disambiguation. Perhaps we can sidestep importObjects() entirely?

> The main problems with the 3.0 bundle I have seen so far resulted either
> from changes in the CMF or PAS. It might actually make sense to point
> these externals to specific revisions as there is quite some work going
> on at least in the CMF. This is the prize we have to pay for catching up
> with the latest version ;)
>
> For review bundles it might actually make sense to point to specific
> revisions of all but your own products/branches. This way you could
> guarantee that your bundle actually works without having to recheck
> everyday if some changes in some other code broke anything.

But then they'll break when we merge :)

> The only problem I can see with this is that the task of merging a
> review bundle into the main development line becomes a bigger task as
> quite some new problems might occur. But I think this is a good
> trade-off if we get reliable review bundles this way.

I think maybe a better idea is to have shorter review cycles and merge sooner :)

What if we let them track trunk normally, but maintain some kind of
"last known good" bundle configuration that we could use if something
breaks beyond the contrl of the bundle author?

Martin