I'm spending some energy trying to fix an add-on for beegin Plone 5 compatible but still trying to support Plone 4. The add-on is simple, the core is a JavaScript file.
I found that:
old style JS and CSS generic setup are supported
items are not loaded in portal_xxx tools (that are still empty) but automatically loaded in the new resource registry (which seems cool to me... initially)
Now problems: it's very difficult to drop the registry cache and there's inconsistent behavior.
enabling the "Development Mode" will spawn a lot of JS errors (not connected to the add-on)
restarting the instance will not lead to anything (old javascript is cached somewhere)
Using the "Build" button for plone-legacy is not working. After clicking "Build it" button in the overlay nothing happens... a rotating (broken) character continue indefinitely so probably there's a JS problem somewhere. However after somes minutes cache is not dropped (nothing logged by the instance and checking the Control_Panel/DebugInfo/manage_main page I see that no activity is running).
The only way I found is to reinstall the add-on, but now the funny part: seems that the JavaScript is loaded multiple times. At every reinstall it's added (let say appended) to the page one more time.
Probably also uninstall is not working (I've an uninstall JS profile which runs, but nothing is removed).
Yesterday I was able to fix the problem deleting the resources from the bundle, then saving but today this seem to not work (probably I also did something additional that I don't remember now).
About the dev mode spawing lots of errors, most of them are solved on the master branch, soon a new alpha/beta will be shipped without that errors.
If you are using the legacy js system, its cooked when you access a page if a new installation is done. Can you check that the plone-legacy-compiled has your code on it ?
The legacy ones does not need to compile if you don't change it.
About the multiple installation problem I'm sure its a bug, can you report at CMFPlone issue tracker ?
The most important thing is that when you are on dev mode you get the js/css form plone-legacy bundle one by one, on production mode you get the concat version of all the plone-legacy elements and its compiled on the first view after a product is installed with a jsregistry.xml or cssregistry.xml.
I'm using the buildout.coredev and all updated packages (2 days ago).
The JavaScript (even if added multiple times) seems to be always updated. I added a simple "alert" inside the documenteready and I get (n times) the text of the alert.
But I don't see this auto-cook behavior (or I don't get what you mean).
I'll check what you suggested.
About creating a new bundle: I need probably to read carefully what you linked but if this is the suggested way to do it seems will be more difficult to easily keep compatibility with old Plone (maybe another piece of documentation to be added to the migration guide?).
@keul regarding your problem with supporting Plone 4 + 5, here is just an idea: wouldn't it be an option to conditionally include a Plone 4 and a Plone 5 profile, where in Plone 4 you include everything via the cssregistry.xml/jsregistry.xml and in Plone 5 via registry.xml?
Yes, I will probably act this way... is more complex that expected but acceptable.
I'm just a little confused about all this complexity:
portal_javascript and portal_css are still there (deprecated, empty, but not removed)
using old way generic setup will not register stuff in portal_javascript but in the new registry panel
using old way generic setup for registering javascript is broken, it's better to use registry.xml
So I'm wondering why portal_something is still there as it seems you are not able to use it (for sure Python will still work, but no one ever used Python on it) and why generic setup still work in a such black magic way.
I've been working on the upgrade step to remove portal_* from plone but leads to tons of problems on tests that checks portal_* on other packages, so its a big task. The idea is to remove it on the first beta.
I planned to follow the @thet suggestion about using separate profiles for Plone 4 (XXregistry.xml) and Plone 5 (registry.xml).
The best way I know that I used sometimes in the past was to provide an install function inside a Extension/install.py script.
My idea was to provide common steps in the profiles/default, the from the install call the plone4 or plone5 profile.
Bad news: this is working if calling the install procedure from ZMI/quick_installer but the install (and not uninstall) is totally ignored when calling it from Plone add-on control panel.
Any motivation behind this behavior? As I said: these were working on Plone 4.
So: finally yesterday night I found some time to investigate this some more.
It seams that Plone 5 removed the Extensions/install.py support when installing an add-ons from Plone UI:
Docstrings explicitly says: "100% based on generic setup profiles now. Kinda. For products magic, use the zope quickinstaller I guess."
Question is: why? Is Plone planning to remove quickinstaller tool?
This create na incoherence from using ZMI/quick_installer and Plone UI and now it seems is not possible anymore to run different profiles at install time.
I think my only choice is to take another way which I discarded before:
register two "complete" profiles, one for Plone <5 and another for Plone 5, both named "default"
every GS registration will contain a zcml:condition with have and not-have
The ugly part is that I need to duplicate common GS files, both valid for Plone 4 and Plone 5 (like metadata.xml and other).
To be honest I don't like this very much. Plone 5b1 is near (I think) but the add-ons migration seems unfriendly.