Factor out robotframework test dependency about plone.app.contenttypes HOT 4 OPEN

I think a classic UI package is the right place for these. CMFPlone is the common base for all frontends and should not include e2e tests for one specific frontend.

from plone.app.contenttypes.

@davisagli I agree. Though, we have Robot tests for ClassicUI in CMFPlone as well.

@mauritsvanrees since the robotframework dependencies are causing troubles. What do you think about starting a Classic UI package and at first just moving the Classic UI RF tests there? This would be a non-breaking change and it would allow us to get started and gain experience.

from plone.app.contenttypes.

A ClassicUI package would indeed be the best place. But in Plone 7 plone.app.contenttypes may be such a ClassicUI-only package: I think with plone.volto you do not use any of the ClassicUI content types, and it only imports a few interfaces from plone.app.contenttypes (plus some more in migration code). So maybe they can just stay here.

But yes, for Plone 6.1 it could be fine to move robot tests to a new package, maybe even a package that only contains tests, like plone.classicuirobottests. Just thinking out loud.

cc @ale-rt who started on https://github.com/plone/plone.classicui in February.

from plone.app.contenttypes.

@mauritsvanrees interesting idea. We indeed have our own Document/News Item/Event content types:

https://github.com/plone/plone.volto/blob/26e5fc1ed495aea740a5687029c7f860f2132b87/src/plone/volto/content.py#L4

However, all the other content types (Image, File, Link, Folder) still come from p.a.contenttypes. This would mean that for Plone 7 we would have to write upgrade steps that migrate all content objects away from p.a.contenttypes.

We also use the p.a.contenttypes test layer and always assume that the functionality is there. Therefore it could require significant effort to move away from p.a.contenttypes.

I need to think about this. Maybe others want to chime in.

from plone.app.contenttypes.