Make Jnario a pure Xbase language

[borisbrodski]

Jnario as a set of pure Xbase languages

Motivation

Jnario currently depends directly on Xtend. Since Xtend provides no official public stable API, even each minor release of Xtend may break Jnario and this already happened in the past.

The suggestion is to make Jnario pure Xbase language dropping dependency on Xtend.

Pros:

• Reliable dependency management (dependencies like [2.6.0,2.7.0) will not break Jnario)
• Less risk for users to end up with a broken installation
• Easy and quick upgrade to new major versions of Xtext

Cons:

• Drop support of the features
  • Class definitions inside specs
  • Anonymous classes
  • Template expressions (partially)
• Need to reimplement or copy some logic from Xtend

TOP PRIORITY

• [x] Fix outline (prevent outline update on any change, remove Xbase expression nodes)
• [x] Fix jump to spec/feature from JUnit view (double click) (@SebastianPoetzsch pls, take a look)?
• [ ] Test standalone batch compiler

Assignments

• Boris
  • [ ] Fix Formatter tests (writing basic formatters for spec & feature)
  • [ ] Test standalone batch compiler

Plan

• Common
  • [x] Fix tests: org.jnario.lib.tests
  • [x] Fix tests: org.jnario.standalone.tests
  • [x] Fix tests: org.jnario.tests
  • [x] Fix tests: org.jnario.ui.tests
  • [x] Migrate to the latest Xtext
  • [ ] Check GUI: preferences
  • [x] Fix Maven build without running test (mvn clean install -DskipTests)
  • [x] Fix Maven complete build (mvn clean install)
  • [ ] Test Jnario in production environments
  • [ ] Migrate to Java 8 (when Xtext does)
• Spec
  • [x] Regenerate EMF and Xtext code (xtend-free)
  • [x] Comment out as much as possible (adding // TODO NO_EXTEND marker)
  • [x] Get everything else compile
  • [x] Get everything else run
  • [ ] Uncomment TODO NO_EXTEND parts and get it to work
  • [ ] Rewrite Formatter
  • [ ] Check UI (outline, autocompletion, quick fixes, ...)
• Feature
  • [x] Regenerate EMF and Xtext code (xtend-free)
  • [x] Comment out as much as possible (adding // TODO NO_EXTEND marker)
  • [x] Get everything else compile
  • [x] Get everything else run
  • [ ] Uncomment TODO NO_EXTEND parts and get it to work
  • [ ] Rewrite Formatter
  • [ ] Check UI (outline, autocompletion, quick fixes, ...)
• Suite
  • [x] Regenerate EMF and Xtext code (xtend-free)
  • [x] Comment out as much as possible (adding // TODO NO_EXTEND marker)
  • [x] Get everything else compile
  • [x] Get everything else run
  • [ ] Uncomment TODO NO_EXTEND parts and get it to work
  • [ ] Rewrite Formatter
  • [ ] Check UI (outline, autocompletion, quick fixes, ...)

Infos

Progress:

• https://github.com/borisbrodski/Jnario/tree/no_xtend
• https://github.com/borisbrodski/Jnario/tree/no_xtend_xtext2.9

[sebastianbenz]

This would definitely make sense. Unfortunately, I don't have the time to work on this - and most likely will have even less time in the future. If you would like to tackle this, I would be happy to support you.

[borisbrodski]

Great! Yes, I and @oehme (I hope) will look into it.

[sebastianbenz]

That would be fantastic!

[oehme]

I'd love to help.

In my opinion, this would only be feasible if we drop Xtend features like

• class definitions
• anonymous classes
• template expressions

Otherwise we would end up copy-pasting large amounts of code from Xtend, which no-one would really have time to maintain. Loosing features isn't nice, but I guess it's more important to have a stable Jnario. One of our customers already dropped it because of the upgrade problems.

What do you guys think?

[sebastianbenz]

That's great Stefan!

I personally have no problem to drop features, as the alternative is even worse - being always one step behind in the migration process (besides the required maintenance effort). Class definitions and anonymous classes are only recent additions anyway. However, anonymous classes are really helpful when writing tests, some kind of alternative would be nice at least.

Template expressions are no problem either, as I would say that you are doing something wrong if you need them in our specs. A simple multiline string terminal should be sufficient.

[oehme]

Well we still have closures for SAM types. And I'd say you can mostly get rid of anonymous classes using stubs with some mocking framework. What use cases do you have in mind which couldn't be solved like that?

2014-11-05 11:38 GMT+01:00 Sebastian Benz [email protected]:

That's great Stefan!

I personally have no problem to drop features, as the alternative is even worse - being always one step behind in the migration process (besides the required maintenance effort). Class definitions and anonymous classes are only recent additions anyway. However, anonymous classes are really helpful when writing tests, some kind of alternative would be nice at least.

Template expressions are no problem either, as I would say that you are doing something wrong if you need them in our specs. A simple multiline string terminal should be sufficient.

— Reply to this email directly or view it on GitHub https://github.com/sebastianbenz/Jnario/issues/160#issuecomment-61788539 .

[sebastianbenz]

Sometimes it is more convenient to write stubs on you own (e.g. when working with callbacks). But this shouldn't be a reason to not migrate to xbase.

[borisbrodski]

I think, that rich strings my actually be pretty think. Consider following example:

def table {
  | param1 | mytag  |
  | 1      | "arg1" |
  | 2      | "arg2" |
}

fact "it works" {
  table.forEach [
    val xml = '''
      <request>
          <do-something param="«param1»">
             <«mytag»/>
          </do-something>
      </request>
    '''
    process(xml) should be "ok"
  ]
}

What's wrong with this? As far as I know, rich string support isn't really a big deal to implement and maintain.

PS Why it's not a part of the Xbase at the first place?

[borisbrodski]

Removed Xtend dependency from EMF-models and Xtext grammars. I run didn't EMF- and Xtext- generators, so everythings compiles sofar.

https://github.com/borisbrodski/Jnario/commit/edbf311825988873f9b8dbec2e2bc01578f2f3ba

Please, review the new modell.

I removed "create" functions. I also removed RichStrings replacing it with a TODO. I think we may add it later, if needed.

PS Where are some weird problem with newlines. I tried to use Windows and Unix newlines. In both cases I got newline changes :( Please, compare ignoring whitespace and newline changes.

[oehme]

Could you please fix your git config so it doesn't change newline characters? What OS are you on? What does git config --list print?

[borisbrodski]

So, here is the same commit without newline changes: https://github.com/borisbrodski/Jnario/commit/edbf311825988873f9b8dbec2e2bc01578f2f3ba

The only reliable way to remove white space and newline changes I found is to use this alias

alias.addNoWhitespace=!sh -c 'git diff -w --no-color $@ | git apply --cached --ignore-whitespace' -

[oehme]

Just to let you know, I will be at Devoxx next week, so I won't have time to work on this until late November.

[sebastianbenz]

Same here. I will be on a Hackathon next week. Starting the week afterwards I am on vacation for the rest of the year with limited internet connection. In January will be busy with moving to London. Unfortunately, this means that I will have almost no time to work on this, but I will try to be available for feedback most of the time.

[borisbrodski]

Thanks for the info. I will try to move forward on this in the mean time.

• My plan: (see issue description)

It looks like ModelInferrers must be almost rewritten from scratch (combining Xtend and old-Jnario Inferrer parts together)

Any comments are welcome!

[oehme]

What do you mean by "combining Xtend and old-Jnario Inferrer parts together"? We don't want to copy Xtend, we want a slim and maintainable Jnario. Am 07.11.2014 11:57 schrieb "Boris Brodski" [email protected]:

Thanks for the info. I will try to move forward on this in the mean time.

My plan:

• Regenerate EMF and Xtext code (xtend-free)
• Comment out as much as possible (adding // TODO NO_EXTEND marker)
• Get everything else compile
• Get everything else run
• Uncomment TODO NO_EXTEND parts and get it to work (can be easy parallelized)

It looks like ModelInferrers must be almost rewritten from scratch (combining Xtend and old-Jnario Inferrer parts together)

Any comments are welcome!

— Reply to this email directly or view it on GitHub https://github.com/sebastianbenz/Jnario/issues/160#issuecomment-62127403 .

[borisbrodski]

Yes, but there are some code needed in Jnario, that's not available in Xbase. (e.g. Validation of field annotations)

[borisbrodski]

@oehme Why actually Xbase (org.eclipse.xtext.xbase) has dependency on org.eclipse.xtend.lib?

[oehme]

It should only have an optional dependency, because we use Xtend code to implement Xbase. Am 11.11.2014 17:06 schrieb "Boris Brodski" [email protected]:

@oehme https://github.com/oehme Why actually Xbase ( org.eclipse.xtext.xbase) has dependency on org.eclipse.xtend.lib?

— Reply to this email directly or view it on GitHub https://github.com/sebastianbenz/Jnario/issues/160#issuecomment-62569275 .

[borisbrodski]

A dummy EMF question: How can I embed XxxImplCustom classes into class hierarchy?

- XtendMemberImpl
   - XtendMemberImplCustom
     - XtendTypeDeclarationImpl
       - XtendTypeDeclarationImplCustom
         - ...

My current approach is to modify Factories creating XxxImplCustom classes, but this seems to be the wrong one.

Thanks!

[oehme]

You shouldn't need to do anything special, just write the XxxImplCustom classes and they will be embedded into the factory.

2014-11-17 13:13 GMT+01:00 Boris Brodski [email protected]:

A dummy EMF question: How can I embed XxxImplCustom classes into class hierarchy?

• XtendMemberImpl
  • XtendMemberImplCustom
    • XtendTypeDeclarationImpl
      • XtendTypeDeclarationImplCustom
        • ...

My current approach is to modify Factories creating XxxImplCustom classes, but this seems to be the wrong one.

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/sebastianbenz/Jnario/issues/160#issuecomment-63296330 .

[sebastianbenz]

I had to patch the EcoreGenerator to get it to work (I think Xtend uses a different naming scheme).

    component = org.jnario.PatchedEcoreGenerator {
        genModel = "platform:/resource/${projectName}/model/Feature.genmodel"
        srcPath ="platform:/resource/${projectName}/src"
        srcPath ="platform:/resource/org.eclipse.xtext.common.types/src"
        srcPath ="platform:/resource/org.eclipse.xtext.xbase/src"
        srcPath ="platform:/resource/org.eclipse.xtend.core/src"
        srcPath ="platform:/resource/org.jnario/src"
    }

[borisbrodski]

Migrated "no_xtend" branch to Xtext 2.8.1

[sebastianbenz]

This is fantastic! How is your progress?

[borisbrodski]

Pretty good I think. Check it out: https://github.com/borisbrodski/Jnario/tree/no_xtend

With Xtext 2.8.1 (and no dependencies to Xtend) I'm able to compile and run very simple feature, very simple spec and a corresponding suite. :)

[sebastianbenz]

Great! Do think that it will be possible to port all features to your version?

On Thu, Apr 2, 2015 at 11:59 AM Boris Brodski [email protected] wrote:

Pretty good I think. Check it out: https://github.com/borisbrodski/Jnario/tree/no_xtend

With Xtext 2.8.1 (and no dependencies to Xtend) I'm able to compile and run very simple feature, very simple spec and a corresponding suite. :)

— Reply to this email directly or view it on GitHub https://github.com/sebastianbenz/Jnario/issues/160#issuecomment-88865548 .

[borisbrodski]

I'm not sure about all features, but most features with no doubt. Currently I'm going through the tests to better understand the situation.

[borisbrodski]

By the way, could you please help me to remove dependency to xtend-maven-plugin from the jnario-maven-plugin project?

I'm not that experienced in maven plugins and it's not a requirement for my project here.

[sebastianbenz]

Are you sure that the jnario maven plugin has a dependency to the xtend plugin? I think I duplicated the code anyway.

[borisbrodski]

Yes, at least

import org.eclipse.xtend.core.XtendStandaloneSetupGenerated;
import org.eclipse.xtend.core.xtend.XtendPackage;
import org.eclipse.xtend.core.XtendRuntimeModule;
import org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler;

Why do you need all this maven stuff any way? Xbase projects can be build from maven without any coding needed. Did you added some cool features to the maven build?

[sebastianbenz]

I think I copied the corresponding Xtend classes into the jnario plugin. I didn't add any new features, the only difference was the way the ResourceSet is loaded. However, I think all these moved into the JnarioBatchCompiler anyway.

On Tue, Apr 7, 2015 at 12:08 PM Boris Brodski [email protected] wrote:

Yes, at least

import org.eclipse.xtend.core.XtendStandaloneSetupGenerated; import org.eclipse.xtend.core.xtend.XtendPackage; import org.eclipse.xtend.core.XtendRuntimeModule; import org.eclipse.xtend.core.compiler.batch.XtendBatchCompiler;

Why do you need all this maven stuff any way? Xbase projects can be build from maven without any coding needed. Did you added some cool features to the maven build?

— Reply to this email directly or view it on GitHub https://github.com/sebastianbenz/Jnario/issues/160#issuecomment-90508398 .