This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I would like to add a set of actions to a specific project type (J2SE Projects, for instance) while not enabling those actions for other project types (web projects, for instance). I follow the advice at [1], so I register my actions at the "Projects/Actions" subfolder to register a context-sensitive action, but then I don't have a portable/standard way to know the exact project's type (whether this is a J2SE Project or a web project). I think we could add a "Projects/specific-project-type/Actions" subfolder (or a "Projects/Actions/specific-project-type") to register project-specific actions in an easy and portable way. This could work the same way we're registering specific "LookupProviders" to existing project types. Thanks, Antonio [1] http://wiki.netbeans.org/DevFaqActionAddProjectTypePopUp
Reasonable request, and has been brought up before I think. Need some way of merging generic with type-specific actions. MIME Lookup API is most obvious analogue, though this is not exactly what we want because the types are not MIME types. Currently most project types should be using Actions.forPath which only handles a single folder. Without any special help you can do this kind of merging using MultiFileSystem. (In fact that is how MIME Lookup API implements it.) We might however want a more general framework for specifying that SFS folders are intended to be merged together, to help with tooling: - ValidateLayerConsistencyTest should check positions, _hidden, etc. in merged folder, as it does now for Editors/*/* - apisupport.project could display merged folders specially in layer view - IndexLayerPaths should show merge results, as now for Editors/*/*
And what about allowing an org.netbeans.spi.project.ActionProvider to be included in the Lookup returned by a org.netbeans.spi.project.LookupProvider? After all actors for this use case (adding actions to a project) will usually want to have a LookupProvider too, I think, and composing two (or more) ActionProviders (the project's and the providers') could be done quickly (with some collection handling)...
You can already register a @ProjectServiceProvider(service=ActionProvider.class, project=...) to add context-sensitive actions to certain files in a project. (If the project does not already have a LookupMerger<ActionProvider> then you would need to add one of these as well using @LM.R.) groovy.project does exactly this. But this is unrelated to registering items into the context menu of a project's root node, which (1) only applies to project-global actions, (2) does not require any ActionProvider participation (you simply add a custom context menu item of your choice).
I've had some thoughts about a mechanism that might be helpful for customizer panel registration as well, and perhaps other things. The basic problem is collecting two or more SFS folders which could contain more generic or more specific registrations, collating their entries by position, applying any masks, and returning a composite result suitable for conversion into a typed collection of objects. My first thought was something like FileObject FileUtil.mergedConfigFolder(String... paths) which would use MultiFileSystem and merge together the named subfolders of the SFS (if they existed - could also listen for them to be created). This would be a straightforward utility method, mostly copied from code in editor.mimelookup.impl. The problem is that the mimelookup code in fact uses the FileObject's from the _original_ SFS, just in the merged order - so as not to be loading InstanceDataObject's from a non-SFS filesystem, and this may be an important consideration. This could be solved by returning List<FileObject> of files from the original SFS, but this is then nontrivial to convert into a list of objects (no FolderLookup etc.). Perhaps better would be to have something like Lookups.forPaths(String... paths) which would merge together those paths (and interpret position attrs and *_hidden files). This would give full control to the caller over what the merge. It might however be smoother for the merging of folders to be done automatically, so calling code does not need to change (useful for project customizers which have the inverse problem to what is requested here); in that case Lookups.forPath(String) should know how to look for certain folders to merge in. Ideally you could specify e.g. <folder name="Projects"> <folder name="Actions"> <attr name="mergesInto" stringvalue="Projects/[^/]+/Actions"/> but then a call to Lookups.forPath("Projects/some-type/Actions") would not know to look at Projects/Actions. (Searching the whole SFS for this attr is not an option.) Having global lookup merging objects also seems inefficient, and would not work well for static analysis such as for 'ant index-layer-paths'. A variant which might work better: <folder name="Projects"> <attr name="mergesInto:[^/]+/Actions" stringvalue="Actions"/> where a query on Projects/some-type/Actions would search up the tree looking for mergesInto:* attrs which might match its path. Needs study.
See bug #182488 for specific case of project action registration; making this more general - a way of create a MimeLookup-like (*) merging scheme for things which are not driven by MIME type. (*) http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-mimelookup/org/netbeans/api/editor/mimelookup/MimeLookup.html#getLookup%28java.lang.String%29
Solving the generate case is probably too ambitious. Closing. I am however ready to accept contributions.