Generic Languages Framework (Project Schliemann)

Submitter:

• Jan Jancura (JJ)

Reviewers:

• Jarda Tulach (Y) (voting)
• Jesse Glick (JG) (voting)
• Petr Hrebejk (B) (voting)
• Dan Prusa (DP)

Issue: 90724 Review Project Schliemann before adding this project to NetBeans standard build.

Prg05, Agharta, Wed 7-Mar-2007, 4pm-5pm CET.
Ready access: 3009154
Sun: 44444

Review material

• Wiki
• SchliemannNBSLanguageDescription
• Source
• Issue

Talks during the review

JG: JG01 (see 90724) is better, JG02 fixed, JG03 better, JG04 Schliemann language description should be updated.

JJ: Yes, we should update our documentation and create some tutorial.

JG: JG05..

JJ: Still open issue. Its support class only, not API. I am not sure if we should move it to Completion API.

JG: It depends on some other Schliemann classes.

JJ: Yes. Another reason for this class is that we do not want to force Schliemann users to learn details of some other APIs (Completion API). JG05 is still open issue, we should rethink it.

JG: It has to be documented.

JG: JG06 Cookie has been renamed to Context, but there is still public constructor.

Y: remove constructor, keep factory method, make final.

JJ: OK.

JG: JG07 - renamed, JG08 - there should be some description of which grammars are accepted by the engine.

JJ: Yes, I will write it. Engine accepts LL (1-4) grammars. So, no left cycles.

JG: What about some optimalizations of cycles.

JJ: Not implemented yet. Optimalization algorithms have some side effects. There are some warnings for too complex grammars.

JG: JG09 ...

JJ: There are still some open issues with Context <> SyntaxContext. Java methods are called twice.

Y: its important issue - TCR. Should be review during API review.

JG: JG10 used in other module, JG11 fixed, JG12 fixed.

Y: Y11 so whats the URL?

DP: Editors/<mimeType>/language.nbs

Y: Y12

DP: I am working on that.

Y: Y13 dependency - why?

JJ: We need to set colorings for tokens.

Y: See issue 26338

JJ: We plan to use it.

Y: Y14 Preferences API should be used in place of SystemOptions - TCR. Y15 fixed, Y16 - tests.

JJ: Tests are fixed now.

Y: Y17

JJ: We will do it.

Y: Y18 - what about stability of APIs?

JJ: We are investion a lot to the API and we want our users use it, so it should be official.

B: development

JJ: Yes, for the next release it should be under development (/0), but we use org.netbeans.api packages, so the API should be official in the release after 6.0.

Y: Y19

JJ: We are still investigating this functionality.

Y: Y20

JJ: Should be fixed, but it will check it.

Y: Y21 - see JG05

B: javax.swing.text.Document and JTextComponent is used on several places. It can be problem for language embedding.

JJ: Implementation of some features requires access to editor and caret.

JG: You should better provide access to caret position and other such features, than exposing JTextComponent.

JJ: I will look at it.

Voting

Approved.

We will add engine, JavaScript sh, diff and other languages support to NetBeans build (distribution).

There will be next review 2-3 weeks before feature freeze (API review).

TCRs for 6.0

The final review did not happened 2-3 weeks before feature freeze (API review). As such jtulach proposes a TCR:

• repackage to other than official package for 6.0 and later - reasons: The right to release something marked as under development in official namespace is an exception not common case. This was first used for project APIs - well reviewed, documented, tested and lead by Jesse for whom "no reasonable compatible alternative" is not a empty sentence without meaning. As a result, the project APIs never in fact needed to do anything incompatible. Schliemann is not at that state and there is no guarantee it will be in it for 6.1

Option #1 (accept the project with the one TCR):

• Jaroslav Tulach

Option #2 (accept the project as it is in CVS, marked under development, make official in 6.1):

• Jesse Glick (too disruptive to move and will be used widely anyway; but TCA: consider doing a new detailed review ASAP before 6.0 release)
• Pavel Buzek (repackaging disruptive w/o value to most API users, will be used anyway, leave it for 6.0 and do a review in 6.1, minimize API changes)
• Petr Hrebejk (don't repackage for 6.0, do a review in 6.1)