Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Jnario a pure Xbase language #160

Open
21 of 36 tasks
borisbrodski opened this issue Nov 5, 2014 · 104 comments
Open
21 of 36 tasks

Make Jnario a pure Xbase language #160

borisbrodski opened this issue Nov 5, 2014 · 104 comments

Comments

@borisbrodski
Copy link
Collaborator

borisbrodski commented Nov 5, 2014

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

  • Fix outline (prevent outline update on any change, remove Xbase expression nodes)
  • 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
    • Fix tests: org.jnario.lib.tests
    • Fix tests: org.jnario.standalone.tests
    • Fix tests: org.jnario.tests
    • Fix tests: org.jnario.ui.tests
    • Migrate to the latest Xtext
    • Check GUI: preferences
    • Fix Maven build without running test (mvn clean install -DskipTests)
    • Fix Maven complete build (mvn clean install)
    • Test Jnario in production environments
    • Migrate to Java 8 (when Xtext does)
  • Spec
    • 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
    • Rewrite Formatter
    • Check UI (outline, autocompletion, quick fixes, ...)
  • Feature
    • 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
    • Rewrite Formatter
    • Check UI (outline, autocompletion, quick fixes, ...)
  • Suite
    • 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
    • Rewrite Formatter
    • Check UI (outline, autocompletion, quick fixes, ...)

Infos

Progress:

@sebastianbenz
Copy link
Owner

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
Copy link
Collaborator Author

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

@sebastianbenz
Copy link
Owner

That would be fantastic!

@oehme
Copy link
Contributor

oehme commented Nov 5, 2014

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
Copy link
Owner

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
Copy link
Contributor

oehme commented Nov 5, 2014

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 notifications@github.com:

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
#160 (comment)
.

@sebastianbenz
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

borisbrodski@edbf311

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
Copy link
Contributor

oehme commented Nov 5, 2014

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
Copy link
Collaborator Author

So, here is the same commit without newline changes: borisbrodski@edbf311

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
Copy link
Contributor

oehme commented Nov 7, 2014

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
Copy link
Owner

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
Copy link
Collaborator Author

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
Copy link
Contributor

oehme commented Nov 7, 2014

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" notifications@github.com:

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
#160 (comment)
.

@borisbrodski
Copy link
Collaborator Author

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

@borisbrodski
Copy link
Collaborator Author

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

@oehme
Copy link
Contributor

oehme commented Nov 11, 2014

It should only have an optional dependency, because we use Xtend code to
implement Xbase.
Am 11.11.2014 17:06 schrieb "Boris Brodski" notifications@github.com:

@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
#160 (comment)
.

@borisbrodski
Copy link
Collaborator Author

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
Copy link
Contributor

oehme commented Nov 17, 2014

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 notifications@github.com:

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
#160 (comment)
.

@sebastianbenz
Copy link
Owner

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
Copy link
Collaborator Author

Migrated "no_xtend" branch to Xtext 2.8.1

@sebastianbenz
Copy link
Owner

sebastianbenz commented Apr 1, 2015 via email

@borisbrodski
Copy link
Collaborator Author

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
Copy link
Owner

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 notifications@github.com
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
#160 (comment)
.

@borisbrodski
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Owner

sebastianbenz commented Apr 7, 2015 via email

@borisbrodski
Copy link
Collaborator Author

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
Copy link
Owner

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 notifications@github.com
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
#160 (comment)
.

@ghaith
Copy link

ghaith commented Sep 30, 2015

Hello @borisbrodski ,
@riederm, @chrismathis and me will be trying to run Jnario on our code base to see what is still missing from a "real world project"'s point of view and start tackling these tasks. Our tests code is based 99% on Specs. We use Richstrings extensively as well as lambdas and in some cases methods defined within the spec. So we could probably assume that this is where our focus would be.

@borisbrodski
Copy link
Collaborator Author

Hello,

Great! The lambdas and methods defined within specs shouldn't be a problem. The RichString support on the other hand is currently very restricted. You can use neither placeholders nor FOR and IF expressions. The indentation would work as expected though.

So, what do you need to start testing Jnario?

@borisbrodski
Copy link
Collaborator Author

@oehme One question: It looks like with Xtext 2.9 scoping in Jnario stops working. Binding with bindXbaseBatchScopeProvider, getScope get called only for importedType and type references for a fairly large spec file. Any ideas why?

@oehme
Copy link
Contributor

oehme commented Oct 1, 2015

No, nothing that comes to mind. You'll have to debug DefaultLinkingService#getLinkedObjects to see why your ScopeProvider is not called.

@borisbrodski
Copy link
Collaborator Author

One question: How can I write a validator for a terminal?
I would like to issue an error, if guillemets are used (that we don't support yet). Thanks.

PS
Just ran Jnario with our big project. Looks great!

@oehme
Copy link
Contributor

oehme commented Oct 5, 2015

You can write a ValueConverter and throw a ValueConverterException.

2015-10-05 17:10 GMT+02:00 Boris Brodski notifications@github.com:

One question: How can I write a validator for a terminal?
I would like to issue an error, if guillemets are used (that we don't
support yet). Thanks.

PS
Just ran Jnario with our big project. Looks great!


Reply to this email directly or view it on GitHub
#160 (comment)
.

@borisbrodski
Copy link
Collaborator Author

@oehme It looks like the new Formatter API is still buggy. I get a bunch of weird exceptions trying to port the formatter to 2.9.latest. I can't reproduce those exceptions with domain-model-example easily though (to report bugs), but I think, the problem is in Xtext (at least there are some checks with good error messages missing).

Stack traces: borisbrodski#5

Could you (or Moritz) just clone the Jnario and take a look of the exceptions ourselves please?
(Before Xtext 2.9 officially released!)

Repo+Branch: https://github.com/borisbrodski/Jnario/tree/no_xtend_xtext2.9

Try to open and format ExampleColumn.spec and you will get exceptions, like in borisbrodski#5

Thank you!

@oehme
Copy link
Contributor

oehme commented Oct 7, 2015

I forwarded this to Moritz, hopefully he'll be able to take a look.

@meysholdt
Copy link

ok, I'll try to take a look later this/next week.

Exceptions thrown from org.eclipse.xtext.formatting2.regionaccess.** are always a bug in Xtext.

@borisbrodski
Copy link
Collaborator Author

@meysholdt Thank you! I think, may be the following bug is also connected to the problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=478711

@borisbrodski
Copy link
Collaborator Author

Hi @meysholdt ! Is there a chance, that you will find a minute (or an hour :) ) to fix this formatter bug prior to the 2.9.0 release? Thank you!

@borisbrodski
Copy link
Collaborator Author

Come and hear me talking about Jnario at DemoCamp Bonn :)
https://wiki.eclipse.org/Eclipse_DemoCamp_November_2015/Bonn

@borisbrodski
Copy link
Collaborator Author

Migrated to Xtext 2.9 (latest)

  • mvn clean install => BUILD SUCCESS
  • mvn org.jnario:report:generate => BUILD SUCCESS

Had to completely rewrite the Maven plugins and maven example.

@sebastianbenz Could you please review the "Complete rework Maven build" commit?
(I added a JUnit test to the example project, that makes sure, that all files get generated.
Should I pull it into a separate project?)

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

@borisbrodski
Copy link
Collaborator Author

Jnario working good with Xtext 2.9 by now. Do we need the 'Xtext 2.8.x' version of Jnario?

If no, I would push the current 'Xtext 2.9.x' version of Jnario to our no_xtend branch and continue from there.

@ghaith
Copy link

ghaith commented Jan 12, 2016

TLDR: I have some rich string fixes but i will port them to 2.9

I have some edits on a 2.8 based version that I have not yet pushed to your branch, they are basically a rework of rich strings because of some inconsitencies we got running our tests. The state can be found in my branch called usable_no_xtend I hadn't had the chance to clean them up and create a pull request, what's missing there is to actually make this change on a higher level and not just for specs. Also the shortcuts for adding placeholders is still not enabled. The implementation itself is close to what xtend did, it converts the rich string segment into a StringConcatination but is still missing some of the smart indentation features that xtend has.
I will be eventually working on porting these changes to 2.9 so there is no need to pull these changes yet into the 2.8 branch, nor would I recommend it as it only works with specs as mentioned above.

@borisbrodski
Copy link
Collaborator Author

This sounds great! I leave both branches for a while. My new commits I will push to the no_xtend_xtext2.9 though.

@borisbrodski
Copy link
Collaborator Author

Java 8 say:

'_' should not be used as an identifier, since it is a reserved keyword from source level 1.8 on

We should fix this as well.

@borisbrodski
Copy link
Collaborator Author

Hi!

One question: exampleTable.forEach doesn't bind to Each.forEach(ExampleTable<T> table, Procedure1<T> assertion) any more. This breaks pretty example table exception messages, like this one:

        example failed

                | value1     | value2     | sum     |
                | 1          | 2          | 3       | ✓
                | 4          | 5          | 7       | ✘     (1)
                | 7          | 8          | 14      | ✘     (2)

Instead it binds to org.jnario.lib.ExampleTable.forEach

We register the Each class in JnarioImplicitlyImportedFeatures as a static and extension class. Any ideas, why this may happen?

Thanks!

@borisbrodski
Copy link
Collaborator Author

Ok, the problem is weird :(

In Java 8 the Iterator interface defines default method forEach(), that gets bound prior to our extension method Each.forEach(). The new default method signature is

public interface Iterable<T> {
  default void forEach(Consumer<? super T> action);
}

Since Jnario get compiled with Java 6, I can't override this method in ExampleTable (No Consumer class defined yet).

My solution: override getBestCandidate() method (in JnarioTypeComputer) letting Each.forEach method always win:

    /*
     * The method {@link Each#forEach(org.jnario.lib.ExampleTable, org.eclipse.xtext.xbase.lib.Procedures.Procedure1)} get shadowed by
     * Java 8 method <code>Iterable.forEach(...)</code>. This will be overritten here. The our <code>forEach</code> always win.
     */
    @Override
    protected ILinkingCandidate getBestCandidate(List<? extends ILinkingCandidate> candidates) {
        for (ILinkingCandidate candidate : candidates) {
            if (candidate.getFeature() instanceof JvmOperation && candidate.getFeature().eContainer() instanceof JvmGenericType) {
                JvmOperation feature = (JvmOperation) candidate.getFeature();
                JvmGenericType type = (JvmGenericType) feature.eContainer();
                if (Each.class.getName().equals(type.getQualifiedName()) && "forEach".equals(feature.getSimpleName())) {
                    return candidate;
                }
            }
        }
        return super.getBestCandidate(candidates);
    }

Any objections to this solution? (Silence will be considered as "great job!") :))))

@oehme
Copy link
Contributor

oehme commented May 20, 2016

Why not override the forEach method in ExampleTable to execute the logic you want?

@borisbrodski
Copy link
Collaborator Author

Because the class Consumer is not on the classpath :(

@oehme
Copy link
Contributor

oehme commented May 20, 2016

You can accept Object and do a little reflection magic ;)

@borisbrodski
Copy link
Collaborator Author

Unfortunately it didn't worked out:
image

Xbase still bounds to iterator.forEach:
image

Changing method signature to public <T> void forEach(Procedure1<T> prod) I get:
image

So I see no other way, but to mess up with the TypeComputer...

@borisbrodski
Copy link
Collaborator Author

I would like to automate release process a bit. Is there a particular reason, why we gave 3 different groupIds in the project:

  • org.jnario
  • org.jnario.feature
  • org.jnario.plugin

The problem is, that the tycho set-version plugin only supports changing versions within a single groupId (see artifacts attribute). https://eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/set-version-mojo.html

Should I change this?

@SebastianPoetzsch
Copy link
Contributor

SebastianPoetzsch commented Jun 9, 2016

    #[1,2,3] => [
        forEach [println(it)]
    ]

not working after override forEach in getBestCandidate() method.

Workaround: it.forEach[...]

@borisbrodski
Copy link
Collaborator Author

Considering set-version post from above:

I will write XSLT and run it use org.codehaus.mojo:xml-maven-plugin:transform like this

<configuration>
  <transformationSets>
    <transformationSet>
      <dir>.</dir>
      <outputDir>.</outputDir>
      <includes>
        <include>pom.xml</include>
        <include>plugins/org.jnario/pom.xml</include>
        <include>plugins/org.jnario.lib/pom.xml</include>
        ...
      </includes>
      <stylesheet>set-version-override-parent-version.xslt</stylesheet>
      <parameters>
        <parameter>
          <name>VERSION</name>
          <value>${VERSION}</value>
        </parameter>
      </parameters>
    </transformationSet>
  </transformationSets>
</configuration>

This will allow us to change version of the Jnario with a single call

mvn org.codehaus.mojo:xml-maven-plugin:transform "-DVERSION=$1"

Any objections to this?

@riederm
Copy link

riederm commented Apr 12, 2017

I created a branch where I added a common base-Grammar for the Spec and the Feature-grammars in Jnario. It is basically Xbase with the Richstrings (Template-Expressions) from Xtend. I called it XbaseWithRichstrings. I also ported all Richstring-related code from Xtend to this grammar-plugin. https://github.com/riederm/Jnario/tree/xbaseWithRichstrings_2.11

So this means that Specs and Features can use Richstrings exactly like we were used to them when Jnario was based on Xtend. Following features are supported:

  • Syntax Highlighting (including syntax highlighting of the resulting indentation)
  • Template expressions
  • FOR-loops inside Richstrings including BEFORE, SEPARATOR, AFTER
  • IF inside Richstrings
  • AutoEdit strategy that handles Richstrings correctly

The only thing that does not work atm are Comments inside Richstrings («« comment »») - but I guess this will not take too long to add this feature as well.
I did this because we use richstrings quite intensively in our company, and its really a pain without the proper syntax-highlighting. Sometimes I also feel that the indentation behaviour did not exactly match the Xtend behavior. Also the suggestions form @oehme, to use Xtend-files in combination with specs and features feels somehow disruptive (at least for me?).

I also moved the Xtext-version to Xtext 2.11. This means that I also moved the Java versions to Java 1.8. So the Branch has a lot of changes, I regenerated the grammars and the version-switch obviously means that basically all generated files look somehow different, so really a ton of changes in terms of git :-(. I pulled the last changes from @borisbrodski 's Xtext2.9 branch and it also successfully builds on travis (https://travis-ci.org/riederm/Jnario/builds/221095372).

So @borisbrodski what do you think? You feel like integrating this stuff into your latest branch and eventually we gonna move everything finally to master? I know that @oehme suggested to drop the Xtend-Template-Expressions from Jnario, I find it not really satisfying. I also think that maybe what I did for the XbaseWithRichstrings-Grammar could eventually be merged into the original Xbase-grammar since I guess Jnario could show that Richstrings successfully work in pure xbase languages?

Whats the proper workflow here? since i also did a version-jump it feels strange to merge it back into the Xtext.29 branch?

@borisbrodski
Copy link
Collaborator Author

That is fantastic!

The Xtend-RichStrings is definitely one of the key Xtend- or actually Xbase-features.
Great to have it in Jnario again.

I will build and test it with our "big" project.

@borisbrodski
Copy link
Collaborator Author

Just pushed most resent version of Jnario https://github.com/borisbrodski/Jnario/tree/master incorporating work of

  • Mathias Rieder
  • Ghaith Hachem
  • Sebastian Pötzsch
  • Dominik Gabriel

(sorry, if some was not mentioned)

and adding following

  • Migration to Xtext 2.14
  • Migration from PegDown to FlexMark
  • Improving performance (see Should: let equals() do the type checking commit)
  • Fixing some bugs
    • Fix "Organize Imports including Jnario"
    • Fix "Open generated file"
    • Fix Guillemet (Ctrl+<, Ctrl+Shift+<)

HUGE thank you to all of you!

Please, if possible, test the last Jnario with your projects!

I plan to create a new issue, like "Make Jnario great again", in order to discuss further steps towards Jnario 2.0 release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants