BTW please do unrelated cleanups of warnings (like adding @Override) in a normal commit prior to making the patch, so as to avoid cluttering the diff with a lot of stuff not relevant to the change you want to make.
[JG01] I don't think any new API is needed at all. You can already register actions in menus however you like, whether in the Tools menu or elsewhere; and you can use DynamicMenuContent to conditionally hide them. (I would love to see an easier and more efficient way to conditionally display actions, which could be used in a lot of places, but that is for a separate API review.)
It looks like we have <10 such actions, so converting them should not be a big deal. Making another magical global place to dump unrelated actions doesn't seem like a good idea to me.
In other words, it is not just manifest registration of actions that we need to deprecate, but ToolsAction itself. Deprecate it, remove it from the Tools menu, and tell people to use regular action registration.
Subsequent comments pertain to the current patch but I think it is the wrong direction.
[JG02] "ToolActions", not "ToolsActions".
[JG03] If openide.actions is to define the layer location, it should be actually define the <folder> in its own layer.xml.
[JG04] apichanges.xml should say deprecation="yes".
[JG05] The patch to j2ee.sun.appsrv81 looks suspicious. manifest.mf is not touched, and org-netbeans-modules-j2ee-sun-ide-j2ee-runtime-actions.instance looks like a CNFE.
Created attachment 94388[details]
New implementation without changes in o.n.core
The new patch is addressing Jesse's comments. I also agree that the tools action shall be subject for elimination, and I may use that in my conversation with the providers of such actions (Analyse folder, create a unit test, etc.), however I still prefer to implement this new API.