Revision as of 09:50, 14 December 2009 by Rmichalsky (Talk | contribs)

Working draft, part of PlatformPoolOfRcpTopics planning.


Use Cases, Requirements

  1. have a big picture view of "extension points" and service providers in the platform / RCP app
  2. provide contextual documentation for #1 directly available in IDE
  3. add new "extension point" and/or service provider for it
  4. locate/edit service provider module / class
  5. locate/edit module processing SP's for given extension point
  6. work with annotation-based registrations as well as layer based ones

Currently This layer in context node editor doesn't support #2, #5 and #6 at all and locating service provider class is clumsy.

On the other hand most of the use cases/requirements are already available for annotation-based regs. with Search, Find Usages and javadoc (as Jesse has already pointed out several times), except for perhaps #1. Notably it allows to locate consumer of the extension point (#5), as it is usually the module that declares the annotation. This is basically unsolvable for XML layers.


For preceeding discussion see [#Possible Solutions] below.

This layer in context node editor cannot be dropped in near future. The main reason is that the 3-rd group of layer paths (see discussion below) - used by RCP developers but not planned to be annotation-registered - is much bigger than originally thought, there is e.g.:

  • javahelp
  • component palette
  • file type integration

and others. Also branding entries will always be written asi XML entries, even for layer paths usually registered by annotations.

In order to retain current This layer in context behavior and fix the deficiencies, new editor of layer.xml files - Layer editor - is proposed.

Layer Editor

It should have the following features:

  • shows up in editor area for convenience
  • offers several tabs with custom editors of various parts of the layer file (similar to e.g. web.xml editor in NB web project)
    • three always present tabs will be explorer views of current layer and layer in context, 3-rd view will be plain XML editor.
    • other editor tabs, like branding editor or e.g. services (former META-INF/Services) can be plugged in
  • as much as possible code for layer and layer in context tabs will be taken from current respective project nodes in order to speed up development
  • editor will NOT show live data, there will be manual Refresh button. This should improve performance and allow for easier integration of annotation-based regs. - see below
  • should also support drag&drop reordering for branding (lower priority)

New SPI should be added to allow modules to declare which layer paths they consume and to publish Javadoc URL for them.

Toolbar for layer in context tab:

  • Refresh
  • Filter annotation-based regs. (optionally only different icon & text)
  • Filter _HIDDEN entries
  • Optionally layer and layer in context will not be separate tabs, but another filtering option

Context menu in layer in context tab:

  • Open Declaration(s) - replaces current Open Layer File(s), works also for annotations
    • impl. for annotations relies on "navigation" comment placed into generated JAR by ann. processor - see discussion below
  • New -> Folder - as usual, New -> Empty File will be removed as it doesn't do anything useful
  • Find, Cut, Copy, Paste, Properties - will remain unchanged, some of them may be missing or behave differently for annotations, TBD
  • Delete - renamed to Hide, replaced with Un-hide (or Show ???) for _HIDDEN entries when not filtered out
  • Rename, Localize name and Pick Icon - will remain, corresponding reverse operations will be shown on branded (renamed, localized) entries
  • Move to original location - undo operation of items reordered in branding
  • Show Javadoc, Open Consumer Module - new actions; straightforward for annotations, for XML entries uses info published via new SPI (see above)

Possible Solutions

The easiest solution would be to let user edit important UI-related categories in separate branding editor (and not introduce annotations for them), add new annotations for entries that don't have one yet and are not important enough for dedicated editor and get rid of This layer and This layer in context nodes altogether. Special simple view for finding all annotations registering layer entries could be added to implement #1.

Alternative straightforward solution would be to somehow merge current layer view with annotations, e.g. by letting CoS create generated layers and use them. However there are several difficulties:

  • navigation from generated layer entry to the originating annotation would be hard or even impossible (but see below)
  • editing entries in UI would require automatic generation/editing of Java code or very different handling of XML and annotation-based entries

Or we could have a r/o view of the SFS for a suite project generated on demand (because it could take some time to process), say in the Output Window. Hyperlink every entry to the original layer.xml or annotation.

As to navigation from a layer entry to annotation: after cc1f043669a6 (in 6.9), there is now a comment associated with every generated layer entry (files and even some folders). If you can find the generated layer being merged (generally easy enough to do), just parse it to find the right file or folder element, look for a comment, and parse that comment to find a package name, class FQN, method name, etc.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo