Hi Hanno,

On 11/22/06, Hanno Schlichting <[EMAIL PROTECTED]> 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

_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to