-
Notifications
You must be signed in to change notification settings - Fork 38
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
Comments
This would definitely make sense. Unfortunately, I don't have the time to |
Great! Yes, I and @oehme (I hope) will look into it. |
That would be fantastic! |
I'd love to help. In my opinion, this would only be feasible if we drop Xtend features like
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? |
That's great Stefan! I personally have no problem to drop features, as the alternative is even Template expressions are no problem either, as I would say that you are |
Well we still have closures for SAM types. And I'd say you can mostly get 2014-11-05 11:38 GMT+01:00 Sebastian Benz [email protected]:
|
Sometimes it is more convenient to write stubs on you own (e.g. when |
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? PS |
Removed Xtend dependency from EMF-models and Xtext grammars. I run didn't EMF- and Xtext- generators, so everythings compiles sofar. 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 |
Could you please fix your git config so it doesn't change newline characters? What OS are you on? What does |
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
|
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. |
Same here. I will be on a Hackathon next week. Starting the week afterwards |
Thanks for the info. I will try to move forward on this in the mean time.
It looks like ModelInferrers must be almost rewritten from scratch (combining Xtend and old-Jnario Inferrer parts together) Any comments are welcome! |
What do you mean by "combining Xtend and old-Jnario Inferrer parts
|
Yes, but there are some code needed in Jnario, that's not available in Xbase. |
@oehme Why actually Xbase ( |
It should only have an optional dependency, because we use Xtend code to
|
A dummy EMF question: How can I embed XxxImplCustom classes into class hierarchy?
My current approach is to modify Factories creating XxxImplCustom classes, but this seems to be the wrong one. Thanks! |
You shouldn't need to do anything special, just write the XxxImplCustom 2014-11-17 13:13 GMT+01:00 Boris Brodski [email protected]:
|
I had to patch the EcoreGenerator to get it to work (I think Xtend uses a different naming scheme).
|
Migrated "no_xtend" branch to Xtext 2.8.1 |
This is fantastic! How is your progress?
|
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. :) |
Great! Do think that it will be possible to port all features to your On Thu, Apr 2, 2015 at 11:59 AM Boris Brodski [email protected]
|
I'm not sure about all features, but most features with no doubt. |
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. |
Are you sure that the jnario maven plugin has a dependency to the xtend
plugin? I think I duplicated the code anyway.
|
Yes, at least
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? |
I think I copied the corresponding Xtend classes into the jnario plugin. I On Tue, Apr 7, 2015 at 12:08 PM Boris Brodski [email protected]
|
Hello @borisbrodski , |
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? |
@oehme One question: It looks like with Xtext 2.9 scoping in Jnario stops working. Binding with |
No, nothing that comes to mind. You'll have to debug DefaultLinkingService#getLinkedObjects to see why your ScopeProvider is not called. |
One question: How can I write a validator for a terminal? PS |
You can write a ValueConverter and throw a ValueConverterException. 2015-10-05 17:10 GMT+02:00 Boris Brodski [email protected]:
|
@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? 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! |
I forwarded this to Moritz, hopefully he'll be able to take a look. |
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. |
@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 |
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! |
Come and hear me talking about Jnario at DemoCamp Bonn :) |
Migrated to Xtext 2.9 (latest)
Had to completely rewrite the Maven plugins and maven example. @sebastianbenz Could you please review the "Complete rework Maven build" commit? https://github.com/borisbrodski/Jnario/tree/no_xtend_xtext2.9 |
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. |
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. |
This sounds great! I leave both branches for a while. My new commits I will push to the |
Java 8 say:
We should fix this as well. |
Hi! One question:
Instead it binds to We register the Thanks! |
Ok, the problem is weird :( In Java 8 the 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 My solution: override /*
* 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!") :)))) |
Why not override the forEach method in |
Because the class |
You can accept |
I would like to automate release process a bit. Is there a particular reason, why we gave 3 different groupIds in the project:
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? |
not working after override Workaround: |
Considering set-version post from above: I will write XSLT and run it use
This will allow us to change version of the Jnario with a single call
Any objections to this? |
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:
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 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? |
That is fantastic! The Xtend-RichStrings is definitely one of the key Xtend- or actually Xbase-features. I will build and test it with our "big" project. |
Just pushed most resent version of Jnario https://github.com/borisbrodski/Jnario/tree/master incorporating work of
(sorry, if some was not mentioned) and adding following
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! |
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:
[2.6.0,2.7.0)
will not break Jnario)Cons:
TOP PRIORITY
Assignments
Plan
mvn clean install -DskipTests
)mvn clean install
)// TODO NO_EXTEND
marker)TODO NO_EXTEND
parts and get it to work// TODO NO_EXTEND
marker)TODO NO_EXTEND
parts and get it to work// TODO NO_EXTEND
marker)TODO NO_EXTEND
parts and get it to workInfos
Progress:
The text was updated successfully, but these errors were encountered: