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.

Bug 167446 - Lookups.forPaths or similar mechanism for merging layer folders
Summary: Lookups.forPaths or similar mechanism for merging layer folders
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jaroslav Tulach
Keywords: API
Depends on:
Blocks: 182488
  Show dependency tree
Reported: 2009-06-22 09:26 UTC by vieiro
Modified: 2013-01-10 08:02 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description vieiro 2009-06-22 09:26:09 UTC
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.


Comment 1 Jesse Glick 2009-06-22 16:24:07 UTC
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/*/*
Comment 2 vieiro 2009-06-22 17:17:51 UTC
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)...

Comment 3 Jesse Glick 2009-06-22 17:25:09 UTC
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).
Comment 4 Jesse Glick 2009-09-20 00:01:17 UTC
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.
Comment 5 Jesse Glick 2010-03-24 14:14:01 UTC
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.

Comment 6 Jaroslav Tulach 2013-01-10 08:02:55 UTC
Solving the generate case is probably too ambitious. Closing. I am however ready to accept contributions.