| <?xml version="1.0" encoding="UTF-8"?> |
| <!-- |
| |
| Licensed to the Apache Software Foundation (ASF) under one |
| or more contributor license agreements. See the NOTICE file |
| distributed with this work for additional information |
| regarding copyright ownership. The ASF licenses this file |
| to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, |
| software distributed under the License is distributed on an |
| "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| KIND, either express or implied. See the License for the |
| specific language governing permissions and limitations |
| under the License. |
| |
| --> |
| <!DOCTYPE api-answers PUBLIC "-//NetBeans//DTD Arch Answers//EN" "../nbbuild/antsrc/org/netbeans/nbbuild/Arch.dtd" [ |
| <!ENTITY api-questions SYSTEM "../nbbuild/antsrc/org/netbeans/nbbuild/Arch-api-questions.xml"> |
| ]> |
| <api-answers |
| question-version="1.29" |
| author="tor@netbeans.org" |
| > |
| |
| &api-questions; |
| |
| |
| <!-- |
| <question id="arch-overall" when="init"> |
| Describe the overall architecture. |
| <hint> |
| What will be API for |
| <a href="http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi"> |
| clients and what support API</a>? |
| What parts will be pluggable? |
| How will plug-ins be registered? Please use <code><api type="export"/></code> |
| to describe your general APIs and specify their |
| <a href="http://openide.netbeans.org/tutorial/api-design.html#category-private"> |
| stability categories</a>. |
| If possible please provide simple diagrams. |
| </hint> |
| </question> |
| --> |
| <answer id="arch-overall"> |
| <p> |
| GSF is a set of APIs to make it easier to provide editing support for new languages. |
| The goal is to make it as easy as possible to write first-rate support, such that |
| language developers can focus only on aspects of their language, not on infrastructure |
| tasks. Language plugin developers don't write editor actions, event listeners, and so on. |
| Instead, they implement their own lexers, parsers, and narrow feature APIs where they |
| use their own lexer token sequences and parse trees to implement the language-specific |
| aspects of features like code completion, go to declaration, semantic highlighting and so on. |
| </p> |
| <p> |
| GSF can be seen as a layer on top of some of the existing NetBeans editing APIs. |
| It directly uses the Lexer API, and while it has its own parsing API, the plan |
| is to replace that with the upcoming NetBeans Parsing API. It defines a number |
| of additional feature APIs, such as "keystroke handler", and "code completion handler", |
| which lets modules go and implement for example logic that should be run when |
| the user presses Return, without the need to go in and implement a custom |
| data loader, editor kit, default editing actions, and so on. |
| </p> |
| <p> |
| Here's an illustration of this: |
| <br/> |
| <br/> |
| <img class="inline" src="@TOP@/gsf-architecture.png" alt="Diagram showing GSF's architecture" /> |
| <br/> |
| <br/> |
| The language plugins shown above (Ruby, Groovy, etc.) are the targets of the |
| GSF API. GSF provides interfaces (and in many cases, optional default |
| abstract class implementations) that the language plugins implement and |
| register. These implementations are then invoked as part of feature |
| implementations provided by GSF. All the generic work and UI involved |
| in writing various language features are handled by GSF, and it delegates |
| to language plugins for the actual language-specific logic. |
| </p> |
| <p> |
| The key thing here is that the GSF implementation provides implementations for |
| a lot of the non-language-specific code that is currently required to implement |
| language features. For example, semantic highlighting involves writing an |
| editing highlighting layer, scheduling parsing jobs when the editor is |
| modified, and iterating the parse tree to pull out interesting information, |
| and then mapping this to the editing highlighting layer. Only the parse |
| tree analysis part here is specific per language, so GSF handles all the |
| other aspects and simply delegates to the language plugin for this |
| specific part. |
| </p> |
| <p> |
| Here's another example of this, for the Instant Rename feature: |
| <br/> |
| <br/> |
| <img class="inline" src="@TOP@/instant-rename.png" alt="Diagram showing instant rename operation" /> |
| <br/> |
| <br/> |
| This diagram shows the division of labor, with GSF on the left hand side |
| and the language plugin on the right. The parser task handled by the language |
| plugin is reused for nearly all features. The language plugin implements |
| a lexer, an optional parser, and an optional indexer, and these are then |
| invoked as necessary before asking the language plugin to provide answers |
| for specific features like go to declaration, code completion, and so on. |
| </p> |
| <p> |
| Language plugins register their services via the default file system layer. |
| This is described in more detail in the |
| <a href="@TOP@/registration.html">Registration Document</a>. |
| NOTE - many details of registration are still TBD. There |
| are some significant implementation problems with the current approach |
| and I'd really like to find a better way to do it. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-quality" when="init"> |
| How will the <a href="http://www.netbeans.org/community/guidelines/q-evangelism.html">quality</a> |
| of your code be tested and |
| how are future regressions going to be prevented? |
| <hint> |
| What kind of testing do |
| you want to use? How much functionality, in which areas, |
| should be covered by the tests? How you find out that your |
| project was successful? |
| </hint> |
| </question> |
| --> |
| <answer id="arch-quality"> |
| <p> |
| Unit tests. GSF needs more. GSF provides unit testing support for its clients, |
| which makes it really trivial to test that your (say) code completion handler |
| works correctly. You just subclass GSF's <code>TestCase</code> implementation (which in |
| turn is a subclass of <code>NbTestCase</code>), and then there are a number |
| of feature specific assertion methods you can call. To test your semantic highlighter, |
| or your keystroke handler, or your code completion handler, you typically just |
| have to write a single line, such as "checkCompletion", and hand it a test file |
| and a caret location, and GSF handles calling your parser, calling your |
| feature handler, golden file generation and diffing, etc. |
| </p> |
| <p> |
| This is call described in more detail in the <a href="@TOP@/unit-testing.html">unit testing document</a>. |
| </p> |
| <p> |
| However, GSF <b>itself</b> needs more testing. GSF is all about infrastructure, |
| and UI, so it's much trickier to test. I've been relying on a lot of manual testing |
| at this point; e.g. unit tests cover Ruby and JavaScript's correct result computation |
| of say code completion data, and I've manually tested that these code completion |
| results show correctly on the screen. |
| </p> |
| <p> |
| I'd really like to get some help in writing infrastructure tests to ensure |
| that all of this is correct. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-time" when="init"> |
| What are the time estimates of the work? |
| <hint> |
| Please express your estimates of how long the design, implementation, |
| stabilization are likely to last. How many people will be needed to |
| implement this and what is the expected milestone by which the work should be |
| ready? |
| </hint> |
| </question> |
| --> |
| <answer id="arch-time"> |
| <p> |
| There are a lot of unknown factors involved here; fixing GSF registration, adapting |
| to the Parsing API (which will require a number of API and implementation changes), |
| as well as competing resources for the Ruby and JavaScript editor maintenance as well |
| as consulting on other language support projects like the Python one. |
| </p> |
| <p> |
| However, an educated guess would be something along the order of six months. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-usecases" when="init"> |
| <hint> |
| Content of this answer will be displayed as part of page at |
| http://www.netbeans.org/download/dev/javadoc/usecases.html |
| You can use tags <usecase name="name> regular html description </usecase> |
| and if you want to use an URL you can prefix if with @TOP@ to begin |
| at the root of your javadoc |
| </hint> |
| |
| Describe the main <a href="http://openide.netbeans.org/tutorial/api-design.html#usecase"> |
| use cases</a> of the new API. Who will use it under |
| what circumstances? What kind of code would typically need to be written |
| to use the module? |
| </question> |
| --> |
| <answer id="arch-usecases"> |
| <p> |
| XXX no answer for arch-usecases |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-what" when="init"> |
| What is this project good for? |
| <hint> |
| Please provide here a few lines describing the project, |
| what problem it should solve, provide links to documentation, |
| specifications, etc. |
| </hint> |
| </question> |
| --> |
| <answer id="arch-what"> |
| <p> |
| GSF attempts to make adding deep editing support for new languages in NetBeans as easy as |
| possible, attempting to reuse existing lexers and parsers, and making it possible to |
| add advanced features like quickfixes, code completion, semantic highlighting, and so on. |
| GSF also attempts to let language plugin developers focus <b>only</b> on the language |
| specific aspects of the editing support. GSF handles infrastructure tasks like |
| parser scheduling, editor kit, loader and action implementations, UI, and so on. |
| As a language plugin developer, "all" you have to do is implement (usually via |
| delegation) your own lexer, parser, indexer, and then implement thin feature APIs |
| like a keystroke handler, a code completion handler, a declaration finder, and so on, |
| based on your own lexing, parser, and indexed data. |
| </p> |
| <p> |
| There is a lot of additional documentation for GSF in its |
| <a href="@TOP@/overview-summary.html">overview document</a>. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="arch-where" when="impl"> |
| Where one can find sources for your module? |
| <hint> |
| Please provide link to the Hg web client at |
| http://hg.netbeans.org/ |
| or just use tag defaultanswer generate='here' |
| </hint> |
| </question> |
| --> |
| <answer id="arch-where"> |
| <defaultanswer generate='here' /> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-deprecation" when="init"> |
| How the introduction of your project influences functionality |
| provided by previous version of the product? |
| <hint> |
| If you are planning to deprecate/remove/change any existing APIs, |
| list them here accompanied with the reason explaining why you |
| are doing so. |
| </hint> |
| </question> |
| --> |
| <answer id="compat-deprecation"> |
| <p> |
| GSF will not deprecate any existing APIs, but it provides a much |
| simpler way to implement functionality that is covered by other |
| APIs. Instead of implementing your own DataLoader, DataObject, |
| EditorKit, various editor actions etc., you can simply reuse |
| GSF's default implementations of these, which will delegate to |
| your plugin only for the language-specific aspects. |
| </p> |
| <p> |
| In some cases, not all the functionality in the existing APIs are |
| exposed through GSF, so there may be cases where developers want |
| to register with the base editing API instead of the GSF layer |
| on top. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-i18n" when="impl"> |
| Is your module correctly internationalized? |
| <hint> |
| Correct internationalization means that it obeys instructions |
| at <a href="http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/i18n-branding.html"> |
| NetBeans I18N pages</a>. |
| </hint> |
| </question> |
| --> |
| <answer id="compat-i18n"> |
| <p> |
| Yes, GSF is properly i18n'ized. Any exceptions are unintentional bugs. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-standards" when="init"> |
| Does the module implement or define any standards? Is the |
| implementation exact or does it deviate somehow? |
| </question> |
| --> |
| <answer id="compat-standards"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="compat-version" when="impl"> |
| Can your module coexist with earlier and future |
| versions of itself? Can you correctly read all old settings? Will future |
| versions be able to read your current settings? Can you read |
| or politely ignore settings stored by a future version? |
| |
| <hint> |
| Very helpful for reading settings is to store version number |
| there, so future versions can decide whether how to read/convert |
| the settings and older versions can ignore the new ones. |
| </hint> |
| </question> |
| --> |
| <answer id="compat-version"> |
| <p> |
| GSF was included in 6.0 (as part of the Ruby cluster), and in 6.1 (as part of the GSF |
| cluster used by JavaScript, HTML and Ruby), and probably in 6.5. In each version, |
| GSF has changed incompatibly. |
| </p> |
| <p> |
| GSF doesn't have any settings that need to be preserved compatibly (that I can |
| think of). There is a tricky area around editor kit settings (for things like |
| indentation size, tab versus space selection, etc). For architectural reasons, |
| this has been a problem for GSF, where a single EditorKit is shared by multiple |
| mime types, which isn't compatible with the old BaseOptions approach (where |
| each mimetype needed its own editor kit). This is being addressed in NetBeans 6.5 |
| and will hopefully not be an issue in the future. |
| </p> |
| <p> |
| One area of concern is the way GSF registers editing services. In order to |
| implement various editing (and navigation and tasklist) functionality, it needs |
| to expose its implementations of various services to other modules that are |
| doing system file system lookup. It does this by actually writing into the system |
| file system at startup. This is persisted in the user directory, under |
| <code>config/Editors/<i>mimetype</i></code>. This hardcodes in for example |
| the full package and class name of the implementation classes for GSF. I have |
| dealt with this in the past by having various logic in my code go and look |
| for old registration files and removing them. And furthermore, the settings migration |
| wizard for 6.1 had specific rules to block these files. |
| </p> |
| <p> |
| This mechanism (registering services with the editor, navigation api and |
| tasklist api) is one I'd <b>really</b> like to improve. I had hoped to |
| use the pluggable system file system (see |
| <a href="http://ruby.netbeans.org/issues/show_bug.cgi?id=26338">issue 26338</a>), |
| but I couldn't get it to work. Hopefully the GSF inception review will |
| come up with some advise for this area. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-jre" when="final"> |
| Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? |
| <hint> |
| It is expected that if your module runs on 1.x that it will run |
| on 1.x+1 if no, state that please. Also describe here cases where |
| you run different code on different versions of JRE and why. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-jre"> |
| <p> |
| I'm using JRE 5.0+ features and APIs. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-jrejdk" when="final"> |
| Do you require the JDK or is the JRE enough? |
| </question> |
| --> |
| <answer id="dep-jrejdk"> |
| <p> |
| I believe the JRE is enough but I haven't tested this. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-nb" when="init"> |
| What other NetBeans projects and modules does this one depend on? |
| <hint> |
| Depending on other NetBeans projects influnces the ability of |
| users of your work to customize their own branded version of |
| NetBeans by enabling and disabling some modules. Too |
| much dependencies restrict this kind of customization. If that |
| is your case, then you may want to split your functionality into |
| pieces of autoload, eager and regular modules which can be |
| enabled independently. Usually the answer to this question |
| is generated from your <code>project.xml</code> file, but |
| if it is not guessed correctly, you can suppress it by |
| specifying <defaultanswer generate="none"/> and |
| write here your own. Please describe such projects as imported APIs using |
| the <code><api name="identification" type="import or export" category="stable" url="where is the description" /></code>. |
| By doing this information gets listed in the summary page of your |
| javadoc. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-nb"> |
| <defaultanswer generate='here' /> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-non-nb" when="init"> |
| What other projects outside NetBeans does this one depend on? |
| |
| <hint> |
| Depending on 3rd party libraries is always problematic, |
| especially if they are not open source, as that complicates |
| the licensing scheme of NetBeans. Please enumerate your |
| external dependencies here, so it is correctly understood since |
| the begining what are the legal implications of your project. |
| Also please note that |
| some non-NetBeans projects are packaged as NetBeans modules |
| (see <a href="http://libs.netbeans.org/">libraries</a>) and |
| it is preferred to use this approach when more modules may |
| depend and share such third-party libraries. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-non-nb"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="dep-platform" when="init"> |
| On which platforms does your module run? Does it run in the same |
| way on each? |
| <hint> |
| If you plan any dependency on OS or any usage of native code, |
| please describe why you are doing so and describe how you envision |
| to enforce the portability of your code. |
| Please note that there is a support for <a href="http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-os-specific">OS conditionally |
| enabled modules</a> which together with autoload/eager modules |
| can allow you to enable to provide the best OS aware support |
| on certain OSes while providing compatibility bridge on the not |
| supported ones. |
| Also please list the supported |
| OSes/HW platforms and mentioned the lovest version of JDK required |
| for your project to run on. Also state whether JRE is enough or |
| you really need JDK. |
| </hint> |
| </question> |
| --> |
| <answer id="dep-platform"> |
| <p> |
| GSF should work on all platforms and all versions of Java, for JDK 5.0 and higher. |
| </p> |
| <p> |
| There is only one OS-specific item in GSF: The code which chooses the delay for |
| parse jobs defaults to 2 seconds on Windows and 1 second elsewhere. I'm not |
| sure why this was done; this is code copied from Retouche (and is still there |
| in the <code>java.source RepositoryUpdater.java</code> file.) |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-dependencies" when="final"> |
| What do other modules need to do to declare a dependency on this one, |
| in addition to or instead of the normal module dependency declaration |
| (e.g. tokens to require)? |
| <hint> |
| Provide a sample of the actual lines you would add to a module manifest |
| to declare a dependency, for example OpenIDE-Module-Requires: some.token. |
| If other modules should not depend on this module, or should just use a |
| simple regular module dependency, you can just answer "nothing". If you |
| intentionally expose a semistable API to clients using implementation |
| dependencies, you should mention that here (but there is no need to give |
| an example of usage). |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-dependencies"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-jar" when="impl"> |
| Do you deploy just module JAR file(s) or other files as well? |
| <hint> |
| Usually a module consist of one JAR file (perhaps with Class-Path |
| extensions) and also a configuration file that enables it. If you |
| have any other files, use |
| <api group="java.io.File" name="yourname" type="export" category="friend">...</api> |
| to define the location, name and stability of your files (of course |
| changing "yourname" and "friend" to suit your needs). |
| |
| If it uses more than one JAR, describe where they are located, how |
| they refer to each other. |
| If it consist of module JAR(s) and other files, please describe |
| what is their purpose, why other files are necessary. Please |
| make sure that installation/uninstallation leaves the system |
| in state as it was before installation. |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-jar"> |
| <p> |
| GSF does not have any extra files or jars. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-nbm" when="impl"> |
| Can you deploy an NBM via the Update Center? |
| <hint> |
| If not why? |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-nbm"> |
| <p> |
| Yes |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-packages" when="init"> |
| Are packages of your module made inaccessible by not declaring them |
| public? |
| |
| <hint> |
| By default NetBeans build harness treats all packages are private. |
| If you export some of them - either as public or friend packages, |
| you should have a reason. If the reason is described elsewhere |
| in this document, you can ignore this question. |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-packages"> |
| <p> |
| Yes. The API packages in the <code>gsf.api</code> module |
| will be exposed as public (they are currently |
| friend only until GSF is API reviewed and approved). |
| The implementation classes in the <code>gsf</code> module |
| will not be made public. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="deploy-shared" when="final"> |
| Do you need to be installed in the shared location only, or in the user directory only, |
| or can your module be installed anywhere? |
| <hint> |
| Installation location shall not matter, if it does explain why. |
| Consider also whether <code>InstalledFileLocator</code> can help. |
| </hint> |
| </question> |
| --> |
| <answer id="deploy-shared"> |
| <p> |
| GSF can be installed anywhere. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-ant-tasks" when="impl"> |
| Do you define or register any ant tasks that other can use? |
| |
| <hint> |
| If you provide an ant task that users can use, you need to be very |
| careful about its syntax and behaviour, as it most likely forms an |
| API for end users and as there is a lot of end users, their reaction |
| when such API gets broken can be pretty strong. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-ant-tasks"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-classloader" when="impl"> |
| Does your code create its own class loader(s)? |
| <hint> |
| A bit unusual. Please explain why and what for. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-classloader"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-component" when="impl"> |
| Is execution of your code influenced by any (string) property |
| of any of your components? |
| |
| <hint> |
| Often <code>JComponent.getClientProperty</code>, <code>Action.getValue</code> |
| or <code>PropertyDescriptor.getValue</code>, etc. are used to influence |
| a behavior of some code. This of course forms an interface that should |
| be documented. Also if one depends on some interface that an object |
| implements (<code>component instanceof Runnable</code>) that forms an |
| API as well. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-component"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-introspection" when="impl"> |
| Does your module use any kind of runtime type information (<code>instanceof</code>, |
| work with <code>java.lang.Class</code>, etc.)? |
| <hint> |
| Check for cases when you have an object of type A and you also |
| expect it to (possibly) be of type B and do some special action. That |
| should be documented. The same applies on operations in meta-level |
| (Class.isInstance(...), Class.isAssignableFrom(...), etc.). |
| </hint> |
| </question> |
| --> |
| <answer id="exec-introspection"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-privateaccess" when="final"> |
| Are you aware of any other parts of the system calling some of |
| your methods by reflection? |
| <hint> |
| If so, describe the "contract" as an API. Likely private or friend one, but |
| still API and consider rewrite of it. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-privateaccess"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-process" when="impl"> |
| Do you execute an external process from your module? How do you ensure |
| that the result is the same on different platforms? Do you parse output? |
| Do you depend on result code? |
| <hint> |
| If you feed an input, parse the output please declare that as an API. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-process"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-property" when="impl"> |
| Is execution of your code influenced by any environment or |
| Java system (<code>System.getProperty</code>) property? |
| On a similar note, is there something interesting that you |
| pass to <code>java.util.logging.Logger</code>? Or do you observe |
| what others log? |
| <hint> |
| If there is a property that can change the behavior of your |
| code, somebody will likely use it. You should describe what it does |
| and the <a href="http://openide.netbeans.org/tutorial/api-design.html#life">stability category</a> |
| of this API. You may use |
| <pre> |
| <api type="export" group="property" name="id" category="private" url="http://..."> |
| description of the property, where it is used, what it influence, etc. |
| </api> |
| </pre> |
| </hint> |
| </question> |
| --> |
| <answer id="exec-property"> |
| <table border="1"> |
| <tr> |
| <th>Property</th><th>Default</th><th>Purpose</th> |
| </tr> |
| <tr> |
| <td>no-ruby-camel-case-style-navigation</td><td>false</td><td>Ability to turn off camel case navigation.</td> |
| </tr> |
| <tr> |
| <td>org.netbeans.javacore.ignoreDirectories</td><td>SCCS CVS .svn</td><td>Directories to skip during indexing. Copied from Retouche.</td> |
| </tr> |
| <tr> |
| <td>org.netbeans.modules.gsf.enableMBeans</td><td>false</td><td>Turn on to enable MBeans to introspect memory usage and settings etc.</td> |
| </tr> |
| <tr> |
| <td>gsf.im_feeling_lucky</td><td>false</td><td>Tell the Go To Declaration code to skip ambiguous results popup and just jump to first match</td> |
| </tr> |
| <tr> |
| <td>LuceneIndex.debugIndexMerge</td><td>false</td><td>Enable Lucene index merging debugging. Not sure what this is for (copied code).</td> |
| </tr> |
| <tr> |
| <td>gsf.preindexing</td><td>false</td><td>Tell GSF it's running as part of pre-indexing. This is used to compute indexes for libraries in advance for startup speedup. |
| Used as part of various scripts in the Ruby support which also look at this flag.</td> |
| </tr> |
| <tr> |
| <td>netbeans.javacore.noscan</td><td>false</td><td>Turn off file system scanning. Inherited from Java support.</td> |
| </tr> |
| <tr> |
| <td>perf.refactoring.test</td><td>false</td><td>Set by performance tests?</td> |
| </tr> |
| <tr> |
| <td>org.netbeans.napi.gsfret.source.Source.reportSlowTasks</td><td>false</td><td>If set, times source tasks and reports tasks that take more than 250 ms</td> |
| </tr> |
| </table> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-reflection" when="impl"> |
| Does your code use Java Reflection to execute other code? |
| <hint> |
| This usually indicates a missing or insufficient API in the other |
| part of the system. If the other side is not aware of your dependency |
| this contract can be easily broken. |
| </hint> |
| </question> |
| --> |
| <answer id="exec-reflection"> |
| <p> |
| There is one instance of this, inherited from Retouche, where the code is using |
| <code>Class.forName</code> to get access to some code which is hidden from the API. |
| The class is called <code>SourceAccessor</code> and it provides access to the <code>Source</code> class. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="exec-threading" when="init"> |
| What threading models, if any, does your module adhere to? How the |
| project behaves with respect to threading? |
| <hint> |
| Is your API threadsafe? Can it be accessed from any threads or |
| just from some dedicated ones? Any special relation to AWT and |
| its Event Dispatch thread? Also |
| if your module calls foreign APIs which have a specific threading model, |
| indicate how you comply with the requirements for multithreaded access |
| (synchronization, mutexes, etc.) applicable to those APIs. |
| If your module defines any APIs, or has complex internal structures |
| that might be used from multiple threads, declare how you protect |
| data against concurrent access, race conditions, deadlocks, etc., |
| and whether such rules are enforced by runtime warnings, errors, assertions, etc. |
| Examples: a class might be non-thread-safe (like Java Collections); might |
| be fully thread-safe (internal locking); might require access through a mutex |
| (and may or may not automatically acquire that mutex on behalf of a client method); |
| might be able to run only in the event queue; etc. |
| Also describe when any events are fired: synchronously, asynchronously, etc. |
| Ideas: <a href="http://core.netbeans.org/proposals/threading/index.html#recommendations">Threading Recommendations</a> (in progress) |
| </hint> |
| </question> |
| --> |
| <answer id="exec-threading"> |
| <p> |
| Most GSF code isn't interesting from a threading perspective, but there is one exception: |
| The <code>Source</code> and <code>RepositoryUpdater</code> classes. These correspond to |
| the <code>JavaSource</code> and <code>RepositoryUpdater</code> classes in the Java Source |
| module, and they perform task schedling etc. in very carefully crafted multi threaded code. |
| I plan to replace this code with the Parsing API, which should make this all go away. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="format-clipboard" when="impl"> |
| Which data flavors (if any) does your code read from or insert to |
| the clipboard (by access to clipboard on means calling methods on <code>java.awt.datatransfer.Transferable</code>? |
| |
| <hint> |
| Often Node's deal with clipboard by usage of <code>Node.clipboardCopy, Node.clipboardCut and Node.pasteTypes</code>. |
| Check your code for overriding these methods. |
| </hint> |
| </question> |
| --> |
| <answer id="format-clipboard"> |
| <p> |
| None. |
| </p> |
| <p> |
| In the future, I'd like to automatically supply an HTML transferable when the |
| user copies text in the editor, such that the clipboard contains a fully syntax |
| highlighted (including semantic colors) copy of the code they can paste |
| into for example open office or a mail program. It would be even better if |
| this could be done in the editor itself without language plugin support, |
| but if it will require specific EditorKit support, GSF will have it. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="format-dnd" when="impl"> |
| Which protocols (if any) does your code understand during Drag & Drop? |
| <hint> |
| Often Node's deal with clipboard by usage of <code>Node.drag, Node.getDropType</code>. |
| Check your code for overriding these methods. Btw. if they are not overridden, they |
| by default delegate to <code>Node.clipboardCopy, Node.clipboardCut and Node.pasteTypes</code>. |
| </hint> |
| </question> |
| --> |
| <answer id="format-dnd"> |
| <p> |
| None. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="format-types" when="impl"> |
| Which protocols and file formats (if any) does your module read or write on disk, |
| or transmit or receive over the network? Do you generate an ant build script? |
| Can it be edited and modified? |
| |
| <hint> |
| <p> |
| Files can be read and written by other programs, modules and users. If they influence |
| your behaviour, make sure you either document the format or claim that it is a private |
| api (using the <api> tag). |
| </p> |
| |
| <p> |
| If you generate an ant build file, this is very likely going to be seen by end users and |
| they will be attempted to edit it. You should be ready for that and provide here a link |
| to documentation that you have for such purposes and also describe how you are going to |
| understand such files during next release, when you (very likely) slightly change the |
| format. |
| </p> |
| </hint> |
| </question> |
| --> |
| <answer id="format-types"> |
| <p> |
| The only persistence GSF is involved with is the Lucene index it creates for each |
| language that wants indexing and querying services. In this case, it creates |
| a separate Lucene index for each combination of a language and a source or library |
| root. These are all located under <code>var/cache/gsf-index</code>. This is similar |
| to the Java Source module, except in GSF's case there is an extra directory |
| per language such that languages have their own unique and isolated Lucene index. |
| Each Lucene database is also indexed by two version numbers: one supplied by |
| GSF, which is incremented when GSF changes the Lucene data format (for example |
| by upgrading to a new version of GSF) and another supplied by each language |
| (when they change their stored data incompatibly). |
| For example, in my user dir I see these directories: |
| </p> |
| <pre> |
| var/cache/gsf-index/1.118/php/0.4.2/ |
| var/cache/gsf-index/1.118/ruby/6.103/ |
| var/cache/gsf-index/1.118/scala/6.118/ |
| </pre> |
| <p> |
| Here, <code>1.118</code> is the current GSF data format version, and |
| <code>0.4.2</code> is the current version of the data supplied by PHP, |
| <code>6.103</code> by the Ruby plugin, and so on. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="lookup-lookup" when="init"> |
| Does your module use <code>org.openide.util.Lookup</code> |
| or any similar technology to find any components to communicate with? Which ones? |
| |
| <hint> |
| NetBeans is build around a generic registry of services called |
| lookup. It is preferable to use it for registration and discovery |
| if possible. See |
| <a href="http://www.netbeans.org/download/dev/javadoc/org-openide-util/org/openide/util/lookup/doc-files/index.html"> |
| The Solution to Comunication Between Components |
| </a>. If you do not plan to use lookup and insist usage |
| of other solution, then please describe why it is not working for |
| you. |
| <br/> |
| When filling the final version of your arch document, please |
| describe the interfaces you are searching for, where |
| are defined, whether you are searching for just one or more of them, |
| if the order is important, etc. Also classify the stability of such |
| API contract. Use <api group=&lookup& /> tag, so |
| your information gets listed in the summary page of your javadoc. |
| </hint> |
| </question> |
| --> |
| <answer id="lookup-lookup"> |
| <p> |
| GSF uses lookup to communicate between the API module and the implementation |
| module. For example, the GSF API interfaces |
| <code>org.netbeans.modules.gsf.api.EditRegions</code>, |
| <code>org.netbeans.modules.gsf.api.EditorOptionsFactory</code>, |
| <code>org.netbeans.modules.gsf.api.HintsProvider$Factory</code>, |
| and <code>org.netbeans.modules.gsf.api.SourceModelFactory</code> |
| are provided in the GSF API and implemented by the GSF module. The |
| <code>org.netbeans.modules.gsf.api.TypeSearcher</code> interface can be implemented |
| by language clients and is looked up by GSF. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="lookup-register" when="final"> |
| Do you register anything into lookup for other code to find? |
| <hint> |
| Do you register using layer file or using <code>META-INF/services</code>? |
| Who is supposed to find your component? |
| </hint> |
| </question> |
| --> |
| <answer id="lookup-register"> |
| <p> |
| Yes. GSF provides implementations for a wide variety of editing APIs as well |
| as the tasklist and navigation APIs. |
| |
| <api group="lookup" name="org.openide.loaders.CreateFromTemplateAttributesProvider" type="export" category="official"> |
| Attributes provider is registered in <code>META-INF/services</code>. It provides |
| <code>package</code> attribute for java templates using scripting support. |
| </api> |
| |
| |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="lookup-remove" when="final"> |
| Do you remove entries of other modules from lookup? |
| <hint> |
| Why? Of course, that is possible, but it can be dangerous. Is the module |
| your are masking resource from aware of what you are doing? |
| </hint> |
| </question> |
| --> |
| <answer id="lookup-remove"> |
| <p> |
| None |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-exit" when="final"> |
| Does your module run any code on exit? |
| </question> |
| --> |
| <answer id="perf-exit"> |
| <p> |
| Yes. On <code>ModuleInstall.closing()</code>, the module closes the open Lucene indices, |
| unregisters file system listeners and cancels scheduled parsing jobs. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-huge_dialogs" when="final"> |
| Does your module contain any dialogs or wizards with a large number of |
| GUI controls such as combo boxes, lists, trees, or text areas? |
| </question> |
| --> |
| <answer id="perf-huge_dialogs"> |
| <p> |
| Define "large number" please :) There aren't many dialogs in GSF, |
| but GSF does provide an Options panel for quickfixes (for language |
| clients that request it, currently only Ruby), which will add |
| a checkbox for every available hint. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-limit" when="init"> |
| Are there any hard-coded or practical limits in the number or size of |
| elements your code can handle? |
| <hint> |
| Most of algorithms have increasing memory and speed complexity |
| with respect to size of data they operate on. What is the critical |
| part of your project that can be seen as a bottleneck with |
| respect to speed or required memory? What are the practical |
| sizes of data you tested your project with? What is your estimate |
| of potential size of data that would cause visible performance |
| problems? Is there some kind of check to detect such situation |
| and prevent "hard" crashes - for example the CloneableEditorSupport |
| checks for size of a file to be opened in editor |
| and if it is larger than 1Mb it shows a dialog giving the |
| user the right to decide - e.g. to cancel or commit suicide. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-limit"> |
| <p> |
| None that I can think of. |
| </p> |
| <p> |
| There may be performance problems supporting really huge |
| source files. There was a bug with huge HTML files in the navigator, |
| where GSF's code which expands all nodes caused some problems. |
| when there are thousands and thousands of nested elements. |
| |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-mem" when="final"> |
| How much memory does your component consume? Estimate |
| with a relation to the number of windows, etc. |
| </question> |
| --> |
| <answer id="perf-mem"> |
| <p> |
| GSF itself shouldn't need to hold much memory. Typically, the memory |
| consumption will come from GSF's language clients, which will create |
| lexing hierarchies and parsing trees which may require a fair bit of space. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-menus" when="final"> |
| Does your module use dynamically updated context menus, or |
| context-sensitive actions with complicated and slow enablement logic? |
| <hint> |
| If you do a lot of tricks when adding actions to regular or context menus, you can significantly |
| slow down display of the menu, even when the user is not using your action. Pay attention to |
| actions you add to the main menu bar, and to context menus of foreign nodes or components. If |
| the action is conditionally enabled, or changes its display dynamically, you need to check the |
| impact on performance. In some cases it may be more appropriate to make a simple action that is |
| always enabled but does more detailed checks in a dialog if it is actually run. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-menus"> |
| <p> |
| GSF adds some actions to editor context menus which are enabled/disabled on the fly. |
| There aren't many of these. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-progress" when="final"> |
| Does your module execute any long-running tasks? |
| |
| <hint>Long running tasks should never block |
| AWT thread as it badly hurts the UI |
| <a href="http://performance.netbeans.org/responsiveness/issues.html"> |
| responsiveness</a>. |
| Tasks like connecting over |
| network, computing huge amount of data, compilation |
| be done asynchronously (for example |
| using <code>RequestProcessor</code>), definitively it should |
| not block AWT thread. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-progress"> |
| <p> |
| Yes, GSF runs parsing tasks which can often take a while. The most visible |
| such task is the startup indexing task, which iterates over all the source |
| folders in the user's project, checks each timestamp to see if the file |
| has changed since last indexing operation, and if not, indexes the file. |
| </p> |
| <p> |
| This should all be occurring in proper background threads. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-scale" when="init"> |
| Which external criteria influence the performance of your |
| program (size of file in editor, number of files in menu, |
| in source directory, etc.) and how well your code scales? |
| <hint> |
| Please include some estimates, there are other more detailed |
| questions to answer in later phases of implementation. |
| </hint> |
| </question> |
| --> |
| <answer id="perf-scale"> |
| <p> |
| The performance of GSF typically depends on the size of the |
| source file, and the speed of the lexer and parser for each |
| language (which is supplied by the language plugins). For example, |
| most bottlenecks I've seen in Ruby development have come from |
| JRuby parsing. Another slow operation I've seen is type analysis, |
| which is performed by the JavaScript language plugin. GSF itself |
| shouldn't cause performance problems. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-spi" when="init"> |
| How the performance of the plugged in code will be enforced? |
| <hint> |
| If you allow foreign code to be plugged into your own module, how |
| do you enforce that it will behave correctly and quickly and will not |
| negatively influence the performance of your own module? |
| </hint> |
| </question> |
| --> |
| <answer id="perf-spi"> |
| <p> |
| GSF doesn't do this. Arguably, it should. There is a flag (documented |
| in the properties section) which when set will complain about long |
| running parsing tasks. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-startup" when="final"> |
| Does your module run any code on startup? |
| </question> |
| --> |
| <answer id="perf-startup"> |
| <p> |
| Yes. It initializes the parsing task scheduler (called RepositoryUpdater) which |
| will listen for project opening events, kick off background indexing tasks, etc. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="perf-wakeup" when="final"> |
| Does any piece of your code wake up periodically and do something |
| even when the system is otherwise idle (no user interaction)? |
| </question> |
| --> |
| <answer id="perf-wakeup"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-file" when="final"> |
| Does your module use <code>java.io.File</code> directly? |
| |
| <hint> |
| NetBeans provide a logical wrapper over plain files called |
| <code>org.openide.filesystems.FileObject</code> that |
| provides uniform access to such resources and is the preferred |
| way that should be used. But of course there can be situations when |
| this is not suitable. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-file"> |
| <p> |
| Yes. The startup indexing code is (like the Java Source module) using the |
| java.io.File API to quickly scan files during startup to look for files |
| that should be indexed. This was deliberately using java.io.File in the Java |
| module for performance reasons, and I'm doing the same thing for GSF. |
| Once a file is identified as a source file to be indexed, it will have its |
| FileObject looked up and the parser proceeds from there. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-layer" when="final"> |
| Does your module provide own layer? Does it create any files or |
| folders in it? What it is trying to communicate by that and with which |
| components? |
| |
| <hint> |
| NetBeans allows automatic and declarative installation of resources |
| by module layers. Module register files into appropriate places |
| and other components use that information to perform their task |
| (build menu, toolbar, window layout, list of templates, set of |
| options, etc.). |
| </hint> |
| </question> |
| --> |
| <answer id="resources-layer"> |
| <p> |
| Yes, GSF writes entries into the layer on behalf of all the language clients which registers |
| GSF implementations that provide implementations for Editor APIs, Navigation APIs, Tasklist APIs, etc. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-mask" when="final"> |
| Does your module mask/hide/override any resources provided by other modules in |
| their layers? |
| |
| <hint> |
| If you mask a file provided by another module, you probably depend |
| on that and do not want the other module to (for example) change |
| the file's name. That module shall thus make that file available as an API |
| of some stability category. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-mask"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-preferences" when="final"> |
| Does your module uses preferences via Preferences API? Does your module use NbPreferences or |
| or regular JDK Preferences ? Does it read, write or both ? |
| Does it share preferences with other modules ? If so, then why ? |
| <hint> |
| You may use |
| <api type="export" group="preferences" |
| name="preference node name" category="private"> |
| description of individual keys, where it is used, what it |
| influences, whether the module reads/write it, etc. |
| </api> |
| Due to XML ID restrictions, rather than /org/netbeans/modules/foo give the "name" as org.netbeans.modules.foo. |
| Note that if you use NbPreferences this name will then be the same as the code name base of the module. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-preferences"> |
| <p> |
| Yes. The GSF hints implementation uses the Preferences API to store persistent state for |
| hints that should be enabled/disabled. When a GSF quickfix offers a solution, it also |
| adds a fix named something like "Disable this hint", and if you select that, the Preferences API |
| will be called to turn off that hint. This setting is consulted by the hints infrastructure |
| as well as the options UI code in GSF. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="resources-read" when="final"> |
| Does your module read any resources from layers? For what purpose? |
| |
| <hint> |
| As this is some kind of intermodule dependency, it is a kind of API. |
| Please describe it and classify according to |
| <a href="http://openide.netbeans.org/tutorial/api-design.html#categories"> |
| common stability categories</a>. |
| </hint> |
| </question> |
| --> |
| <answer id="resources-read"> |
| <p> |
| No. |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="security-grant" when="final"> |
| Does your code grant additional rights to some other code? |
| <hint>Avoid using a class loader that adds extra |
| permissions to loaded code unless really necessary. |
| Also note that your API implementation |
| can also expose unneeded permissions to enemy code by |
| calling AccessController.doPrivileged().</hint> |
| </question> |
| --> |
| <answer id="security-grant"> |
| <p> |
| No |
| </p> |
| </answer> |
| |
| |
| |
| <!-- |
| <question id="security-policy" when="final"> |
| Does your functionality require modifications to the standard policy file? |
| <hint>Your code might pass control to third-party code not |
| coming from trusted domains. This could be code downloaded over the |
| network or code coming from libraries that are not bundled |
| with NetBeans. Which permissions need to be granted to which domains?</hint> |
| </question> |
| --> |
| <answer id="security-policy"> |
| <p> |
| No |
| </p> |
| </answer> |
| </api-answers> |
