Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Xtend nearly unusable in big files
Xtend nearly unusable in big files [message #720750] Wed, 31 August 2011 07:56 Go to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
Hi developers.

I'm currently writing some xtend code generation templates and it really frustrates me.

Nearly time I save my xtend code files Eclipse needs to Build my Workspace twice! It seems xtend build the workspace before the validation starts (to check whether all referenced elements are available). Then the validation starts and the code generation of xtend to java is triggered. And afterwards the whole workspace is rebuilt again because of the new classes.

Each time I save my file the whole Eclipse instance gets unusable (sometimes even unresponsive) till this build process is finished. I tried to disable the automatic build but even then xtend triggers the code generation and therefore the workspace rebuild.

It takes me hours to write templates that really frustrates. I have two template files in my project. One is 1400 lines long and the other 400. Of course xtend needs some heavy operations for validation but on bigger files you get really stuck using xtend.

But on each save new progress tasks get enqueued. If I make changes and hit save a "workspace building" and an "xtext validation" task is enqueued. Sometimes the elements are enqueued twice. I make some additional changes till Eclipse is responsive and hit save again. Then I have 4-6 tasks in my progress queue and can get a cup of coffee till those tasks are complete.

The parts: "Updating resource description x of y" and "Invoking build participants" take the most of the time which is up to 2 minutes.

Is this simply my fault or is it really xtend that becomes quite unusable on huge template files?

Cheers
Daniel
Re: Xtend nearly unusable in big files [message #720755 is a reply to message #720750] Wed, 31 August 2011 08:11 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
Hi,

we are facing the same problems. The Xtext Guys work on that. There are some bugs in bugzilla on that. e.g.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=353321
Feel free to file a new performance bug and attach reproducable samples.

~Christian


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Xtend nearly unusable in big files [message #720773 is a reply to message #720755] Wed, 31 August 2011 08:31 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
Awesome thanks. I couldn't find the bug but I probably used wrong search terms. (I was always searching about the workspace building problem).
My current language is too big that I could simply attach it to a bug. I hope this feature is available soon.

[edit]
I made a comment on the bug and requested a reopening since a turn-off setting is really needed.

[Updated on: Wed, 31 August 2011 08:48]

Report message to a moderator

Re: Xtend nearly unusable in big files [message #720776 is a reply to message #720750] Wed, 31 August 2011 08:19 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Daniel

Thanks for some extra insight. I thought it was just me with problems.

I see exactly the same issues and I don't use Xtend at all (except in so
far as Xtext does on my behalf). I use MWE2 and Acceleo and Xtext.

I stepped a bit of MWE when I had some URI resolution bug and saw some
double work going on, though I think it was plugin scanning, but perhaps
that triggers builds.

Anyway, perhaps MWE rather than Xtend or Acceleo is at fault.

I find the situation gets particularly bad after a GIT switch-to-branch,
since rebuilds start long before GIT has finished and so a sequence of
partial builds block GIT progress and fight to complete before GIT and a
clean build can complete. Disabling auto-build till GIT completes is
almost mandatory.

Regards

Ed Willink


On 31/08/2011 08:56, Daniel wrote:
> Hi developers.
> I'm currently writing some xtend code generation templates and it
> really frustrates me.
> Nearly time I save my xtend code files Eclipse needs to Build my
> Workspace twice! It seems xtend build the workspace before the
> validation starts (to check whether all referenced elements are
> available). Then the validation starts and the code generation of
> xtend to java is triggered. And afterwards the whole workspace is
> rebuilt again because of the new classes.
>
> Each time I save my file the whole Eclipse instance gets unusable
> (sometimes even unresponsive) till this build process is finished. I
> tried to disable the automatic build but even then xtend triggers the
> code generation and therefore the workspace rebuild.
> It takes me hours to write templates that really frustrates. I have
> two template files in my project. One is 1400 lines long and the other
> 400. Of course xtend needs some heavy operations for validation but on
> bigger files you get really stuck using xtend.
> But on each save new progress tasks get enqueued. If I make changes
> and hit save a "workspace building" and an "xtext validation" task is
> enqueued. Sometimes the elements are enqueued twice. I make some
> additional changes till Eclipse is responsive and hit save again. Then
> I have 4-6 tasks in my progress queue and can get a cup of coffee till
> those tasks are complete.
> The parts: "Updating resource description x of y" and "Invoking build
> participants" take the most of the time which is up to 2 minutes.
> Is this simply my fault or is it really xtend that becomes quite
> unusable on huge template files?
>
> Cheers
> Daniel
Re: Xtend nearly unusable in big files [message #720777 is a reply to message #720755] Wed, 31 August 2011 08:21 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Christian

353321 is RESOLVED WONTFIX.

Regards

Ed Willink

On 31/08/2011 09:11, Christian Dietrich wrote:
> Hi,
>
> we are facing the same problems. The Xtext Guys work on that. There
> are some bugs in bugzilla on that. e.g.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=353321
> Feel free to file a new performance bug and attach reproducable samples.
>
> ~Christian
Re: Xtend nearly unusable in big files [message #720779 is a reply to message #720773] Wed, 31 August 2011 08:39 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14661
Registered: July 2009
Senior Member
Yes i know,

this is why i ask for a extra bug with an reproducable example.

~Christian


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Xtend nearly unusable in big files [message #720788 is a reply to message #720750] Wed, 31 August 2011 08:48 Go to previous messageGo to next message
Florian Quadt is currently offline Florian QuadtFriend
Messages: 6
Registered: July 2009
Junior Member
I have the same issue too.

It gets even worse if you have two or more dependent xtext projects, both with xtend files.
There you sometimes get two to three builds in a row and then sometimes, some xtend files won't be generated at all and I have to trigger a clean on this project to build it again. This also occurs for my dsl-Project itself (runtime of my xtext-plugin).
I tried to fix the issue and introduced some Interfaces (plain java) and closed the xtext projects I actually don't need. This helps a bit, but every manifest-change (logically) introduces lunch-time.

I've dived into your builder quite a bit and tried to identify the cause, but I must say this is really hard stuff.

First of all it is quite unclear why in my runtime project classes like ...JvmModelInferrer are in the list of resources to be build. The number of resources to be build is nearly always around 22 resources but only with one xtend file.
Second the BuilderParticipant sometimes triggers for the target files and emf files generated to a src-gen folder.

Actually you are investing some time on this issues (2.0.1 and a nightly need lesser build time and do not build every closing project), but surely there is a lot to do. Since this is quite annoying, I want to participate on this topic.
What is the appropriate way to do so? Are there specific tasks / topics / issues to focus on?

Best regards

Florian
Re: Xtend nearly unusable in big files [message #720789 is a reply to message #720779] Wed, 31 August 2011 08:50 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
A reopening would be great because such a turn-off auto-generation switch would solve the problem. I'll try to setup a sample project which reproduces the problem but since my templates are quite huge it will take some time to create a sample.
Re: Xtend nearly unusable in big files [message #720791 is a reply to message #720776] Wed, 31 August 2011 08:44 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 760
Registered: July 2009
Location: Hamburg
Senior Member
Sounds like a bug in eGit. Did you report it?

We are working hard to improve performance. If you switch to the HEAD
revision of Xtext, you will already experience a serious speed-up.

Am 31.08.11 10:19, schrieb Ed Willink:
> Hi Daniel
>
> Thanks for some extra insight. I thought it was just me with problems.
>
> I see exactly the same issues and I don't use Xtend at all (except in so
> far as Xtext does on my behalf). I use MWE2 and Acceleo and Xtext.
>
> I stepped a bit of MWE when I had some URI resolution bug and saw some
> double work going on, though I think it was plugin scanning, but perhaps
> that triggers builds.
>
> Anyway, perhaps MWE rather than Xtend or Acceleo is at fault.
>
> I find the situation gets particularly bad after a GIT switch-to-branch,
> since rebuilds start long before GIT has finished and so a sequence of
> partial builds block GIT progress and fight to complete before GIT and a
> clean build can complete. Disabling auto-build till GIT completes is
> almost mandatory.
>
> Regards
>
> Ed Willink
>
>
> On 31/08/2011 08:56, Daniel wrote:
>> Hi developers.
>> I'm currently writing some xtend code generation templates and it
>> really frustrates me.
>> Nearly time I save my xtend code files Eclipse needs to Build my
>> Workspace twice! It seems xtend build the workspace before the
>> validation starts (to check whether all referenced elements are
>> available). Then the validation starts and the code generation of
>> xtend to java is triggered. And afterwards the whole workspace is
>> rebuilt again because of the new classes.
>>
>> Each time I save my file the whole Eclipse instance gets unusable
>> (sometimes even unresponsive) till this build process is finished. I
>> tried to disable the automatic build but even then xtend triggers the
>> code generation and therefore the workspace rebuild.
>> It takes me hours to write templates that really frustrates. I have
>> two template files in my project. One is 1400 lines long and the other
>> 400. Of course xtend needs some heavy operations for validation but on
>> bigger files you get really stuck using xtend.
>> But on each save new progress tasks get enqueued. If I make changes
>> and hit save a "workspace building" and an "xtext validation" task is
>> enqueued. Sometimes the elements are enqueued twice. I make some
>> additional changes till Eclipse is responsive and hit save again. Then
>> I have 4-6 tasks in my progress queue and can get a cup of coffee till
>> those tasks are complete.
>> The parts: "Updating resource description x of y" and "Invoking build
>> participants" take the most of the time which is up to 2 minutes.
>> Is this simply my fault or is it really xtend that becomes quite
>> unusable on huge template files?
>>
>> Cheers
>> Daniel
>


--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com


---
Get professional support from the Xtext committers at www.typefox.io
Re: Xtend nearly unusable in big files [message #720856 is a reply to message #720789] Wed, 31 August 2011 11:30 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
I filed a new bug here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=356305
It also contains a sample project to test the annoying huge-template behavior. I hope the bug is okay this way.
Re: Xtend nearly unusable in big files [message #720880 is a reply to message #720856] Wed, 31 August 2011 12:31 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
Hi Daniel,

I tried to explain in the comment of the newly filed bug, why disabling the code generation is not an option and what we have done (and still do) about the bad performance of the builder instead.
Does that help?

Sven
Re: Xtend nearly unusable in big files [message #720892 is a reply to message #720880] Wed, 31 August 2011 12:48 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
Hi Sven.

Thanks for the tests in the new version. If the problem is really fixed within the new version, of course there's no need for such a feature. Is there a possibility that you will release a performance fix before 2.1? The release date of 2.1 is beyond my project timeline and it would be great if the fixes are released before that. I'll try out the xtext HEAD on a second eclipse and give you feedback if the build is as fast as on your machine.
Re: Xtend nearly unusable in big files [message #720899 is a reply to message #720892] Wed, 31 August 2011 13:03 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
I'm sorry, but releasing something before 2.1 is not possible, since the time involved in testing and ensuring overall quality of a release is a huge effort (although we have thousands of unit tests).
You could use the latest build and in case you face a show stopper we will be happy to fix it ASAP. I've just updated the links to the various update sites on our web site including a new one pointing to the latest stable build.

Sven
Re: Xtend nearly unusable in big files [message #720921 is a reply to message #720899] Wed, 31 August 2011 13:48 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
I just tested the the build using the latest nightly build and the build takes only 15 seconds on the 1800 lines. I will simply use the latest build and hope I do not encounter any bugs. The URL to the latest stable build you added is currently mispointing (http://download.eclipse.org/modeling/tmf/xtext/updates/composite/latest/ -> error 404).

An improvement from 2:10min to 0:15min is quite impressive, good job. Looking forward to more improvements Very Happy
Are you already using some kind of partial builds and validation? i.e. If I edit the method compileTest only this method gets revalidated recompiled? Or are there any plans to do that? That would simply boost the system up like hell Very Happy

[EDIT]
I just mentioned something: If I'm editing other Java files (not xtend classes) the xtend classes get recompiled as well. That's quite unnessacery. Of course a validation should get triggered (a referenced method could get changed) but is a recompilation really needed?

I'm currently writing some code documentation on my other java classes and each time I save the xtend files get recompiled. That's probably another reason why a automatic xtend build should have a disable feature. Currently the automatic build is bound to the general project build, but what if I want to recompile my java stuff but not my xtend stuff (because I know there are no changes).


[Updated on: Wed, 31 August 2011 13:54]

Report message to a moderator

Re: Xtend nearly unusable in big files [message #720939 is a reply to message #720921] Wed, 31 August 2011 14:07 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
That should only be the case if the edited Java file is referenced. Anyway that part can be further improved too.
15 seconds still is too slow. Is that the project build or what happens when you save a single file?

BTW: You should consider having more smaller files. That's not only a good idea for performance reasons.
Re: Xtend nearly unusable in big files [message #720981 is a reply to message #720921] Wed, 31 August 2011 15:52 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by:

Am 31.08.11 15:48, schrieb Daniel:
> I just tested the the build using the latest nightly build and the build
> takes only 15 seconds on the 1800 lines. I will simply use the latest
> build and hope I do not encounter any bugs. The URL to the latest stable
> build you added is currently mispointing
> (http://download.eclipse.org/modeling/tmf/xtext/updates/composite/latest/ ->
> error 404).
This is an Eclipse Update site/p2 repository; you must access it from
Eclipse.

Regards,
Dennis.

> An improvement from 2:10min to 0:15min is quite impressive, good job.
> Looking forward to more improvements :d Are you already using some kind
> of partial builds and validation? i.e. If I edit the method compileTest
> only this method gets revalidated recompiled? Or are there any plans to
> do that? That would simply boost the system up like hell :d
Re: Xtend nearly unusable in big files [message #721013 is a reply to message #720791] Wed, 31 August 2011 16:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Not reported against EGit yet. I'm waiting for SR1 before starting to
winge. I think that three or four projects have poor characteristics and
when these combine exponentially we get to the coffee break build
phenomenon.

I suspect that my problem may be different to other peoples because I
have split plugins.

I have an AST plugin in which a *.uml defines the auto-generated *.ecore
and *.java.

I have 5 CST + Editor plugins in which
- *.ecore defines the auto-generated *.java
- *.xtext defines more auto-generated *.java

To avoid polluting the CST plugins with build-only dependencies, I have
a Build 'plugin' that houses *.mwe2 and *.mtl (Acceleo templates) and
*.java.

One mwe2 script drives the *.uml to *.java in the AST plugin and via
Acceleo generates more *.java.
Another mwe2 script drives the 5 CST genmodels for *.ecore to *.Java and
via Acceleo generates more *.java.
Another mwe2 script drives the 5 *.xtext to *.java.

Because MWE2 re-uses the classpath as a modelpath and my models are
referenced as platform:/plugin... the necessary MWE2 modelpath creates a
cyclic Java dependency. Eclipse perceives the Build plugin as dependent
on the CST and AST plugins since they are on the classpath/modelpath,
but running an MWE2 script generates Java upstream in the plugins on
which the Build plugin depends.

I think MWE2 needs to use a modelpath that is analoguous to a classpath
but without making Eclipse think that there is a dependency. I would
gladly provide explicit 'import' statements in the Standalone bean setup
so long as there is a syntax that enables platform:/plugin to correctly
resolve to platform:/resource if present else platform:/plugin in the
normal EMF fashion.

Regards

Ed Willink

On 31/08/2011 09:44, Jan Koehnlein wrote:
> Sounds like a bug in eGit. Did you report it?
>
> We are working hard to improve performance. If you switch to the HEAD
> revision of Xtext, you will already experience a serious speed-up.
>
> Am 31.08.11 10:19, schrieb Ed Willink:
>> Hi Daniel
>>
>> Thanks for some extra insight. I thought it was just me with problems.
>>
>> I see exactly the same issues and I don't use Xtend at all (except in so
>> far as Xtext does on my behalf). I use MWE2 and Acceleo and Xtext.
>>
>> I stepped a bit of MWE when I had some URI resolution bug and saw some
>> double work going on, though I think it was plugin scanning, but perhaps
>> that triggers builds.
>>
>> Anyway, perhaps MWE rather than Xtend or Acceleo is at fault.
>>
>> I find the situation gets particularly bad after a GIT switch-to-branch,
>> since rebuilds start long before GIT has finished and so a sequence of
>> partial builds block GIT progress and fight to complete before GIT and a
>> clean build can complete. Disabling auto-build till GIT completes is
>> almost mandatory.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 31/08/2011 08:56, Daniel wrote:
>>> Hi developers.
>>> I'm currently writing some xtend code generation templates and it
>>> really frustrates me.
>>> Nearly time I save my xtend code files Eclipse needs to Build my
>>> Workspace twice! It seems xtend build the workspace before the
>>> validation starts (to check whether all referenced elements are
>>> available). Then the validation starts and the code generation of
>>> xtend to java is triggered. And afterwards the whole workspace is
>>> rebuilt again because of the new classes.
>>>
>>> Each time I save my file the whole Eclipse instance gets unusable
>>> (sometimes even unresponsive) till this build process is finished. I
>>> tried to disable the automatic build but even then xtend triggers the
>>> code generation and therefore the workspace rebuild.
>>> It takes me hours to write templates that really frustrates. I have
>>> two template files in my project. One is 1400 lines long and the other
>>> 400. Of course xtend needs some heavy operations for validation but on
>>> bigger files you get really stuck using xtend.
>>> But on each save new progress tasks get enqueued. If I make changes
>>> and hit save a "workspace building" and an "xtext validation" task is
>>> enqueued. Sometimes the elements are enqueued twice. I make some
>>> additional changes till Eclipse is responsive and hit save again. Then
>>> I have 4-6 tasks in my progress queue and can get a cup of coffee till
>>> those tasks are complete.
>>> The parts: "Updating resource description x of y" and "Invoking build
>>> participants" take the most of the time which is up to 2 minutes.
>>> Is this simply my fault or is it really xtend that becomes quite
>>> unusable on huge template files?
>>>
>>> Cheers
>>> Daniel
>>
>
>
Re: Xtend nearly unusable in big files [message #721075 is a reply to message #721013] Wed, 31 August 2011 20:21 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
Edward Willink wrote on Wed, 31 August 2011 18:54
Hi
I think MWE2 needs to use a modelpath that is analoguous to a classpath
but without making Eclipse think that there is a dependency. I would
gladly provide explicit 'import' statements in the Standalone bean setup
so long as there is a syntax that enables platform:/plugin to correctly
resolve to platform:/resource if present else platform:/plugin in the
normal EMF fashion.


Not sure I completely understood, but MWE2 is not resolving a single URI.
If you want to use platform:resource you need to use the StandaloneSetup class (I think you already do)
and provide one or more folders which should be scanned for eclipse projects or jared bundles.
This has nothing to do with the project's classpath where the MWE2 file resides.

Sven
Re: Xtend nearly unusable in big files [message #721169 is a reply to message #721075] Thu, 01 September 2011 05:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Sven

Maybe I'm confusing two problems:

a) spurious classpath entries/scanning

My StandaloneSetup config is

bean = StandaloneSetup { resourceSet = resourceSet
platformUri = "./META-INF" // A local folder to
minimize workspace searching
scanClassPath = true // But we do need to search
the plugin-space
uriMap = Mapping {
from = "platform:/plugin/org.eclipse.uml2.uml.resources/"
to = "platform:/resource/org.eclipse.uml2.uml.resources/"
}
uriMap = Mapping {
from = "platform:/plugin/org.eclipse.uml2.uml/"
to = "platform:/resource/org.eclipse.uml2.uml/"
}
}

which scans (everything on) the classPath to enable a standalone usage
to find the two UML plugins that I'm interested in as platform:/resource
names that I can then map to the platform:/plugin names that need
resolving. A more direct

modelPlugin = "org.eclipse.uml2.uml",
"org.eclipse.uml2.uml.resources", "org.eclipse.xtext.common.types"

could support the accesses that I really wanted without needing a
spurious Java classPath entry or scanning every possible plugin.

[I find that MWE's brute force attempts to find everything as well
intentioned but actually unhelpful through depriving users of the
required declarative control and they are very very costly; an MWE
script can easily take 10 seconds before its 'time 0' diagnostic.]

b) cyclic Java class paths

In order for the MWE script to access the *.xtext file, the editor
plugin must be on the class path of the build plugin containing the MWE
script. If the MWE script generates Java into the editor plugin then the
MWE script modifies something on the build plugin classpath, potentially
triggering a rebuild 'cycle' that does not actually rerun the MWE script
but does re-re-build all the transformation templates in the same build
plugin as the MWE script.

If instead an Xtext file was located via a StandaloneSetup import
declaration such as

modelPlugin = "org.eclipse.ocl.examples.xtext.oclinecore" // etc

the Java classpath would not serve a double purpose, the editor plugins
could be omitted from the classpath and the rebuild 'loop' is not created.

Regards

Ed Willink


On 31/08/2011 21:21, Sven Efftinge wrote:
> Edward Willink wrote on Wed, 31 August 2011 18:54
>> Hi
>> I think MWE2 needs to use a modelpath that is analoguous to a
>> classpath but without making Eclipse think that there is a
>> dependency. I would gladly provide explicit 'import' statements in
>> the Standalone bean setup so long as there is a syntax that enables
>> platform:/plugin to correctly resolve to platform:/resource if
>> present else platform:/plugin in the normal EMF fashion.
>
>
> Not sure I completely understood, but MWE2 is not resolving a single URI.
> If you want to use platform:resource you need to use the
> StandaloneSetup class (I think you already do)
> and provide one or more folders which should be scanned for eclipse
> projects or jared bundles.
> This has nothing to do with the project's classpath where the MWE2
> file resides.
>
> Sven
>
Re: Xtend nearly unusable in big files [message #721189 is a reply to message #721169] Thu, 01 September 2011 07:03 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
Quote:

Maybe I'm confusing two problems:

a) spurious classpath entries/scanning

My StandaloneSetup config is

bean = StandaloneSetup { resourceSet = resourceSet
platformUri = "./META-INF" // A local folder to
minimize workspace searching
scanClassPath = true // But we do need to search
the plugin-space
uriMap = Mapping {
from = "platform:/plugin/org.eclipse.uml2.uml.resources/"
to = "platform:/resource/org.eclipse.uml2.uml.resources/"
}
uriMap = Mapping {
from = "platform:/plugin/org.eclipse.uml2.uml/"
to = "platform:/resource/org.eclipse.uml2.uml/"
}
}

which scans (everything on) the classPath to enable a standalone usage
to find the two UML plugins that I'm interested in as platform:/resource
names that I can then map to the platform:/plugin names that need
resolving. A more direct

modelPlugin = "org.eclipse.uml2.uml",
"org.eclipse.uml2.uml.resources", "org.eclipse.xtext.common.types"

could support the accesses that I really wanted without needing a
spurious Java classPath entry or scanning every possible plugin.

[I find that MWE's brute force attempts to find everything as well
intentioned but actually unhelpful through depriving users of the
required declarative control and they are very very costly; an MWE
script can easily take 10 seconds before its 'time 0' diagnostic.]


Firstly the class path scanning is only done when executing the Standalonesetup not while checking the MWE2 file within Eclipse. Also the scanClasspath property is just a convenient functionality, for those where this fit nicely. You can instead have multiple settings for platformUri = "file/path/to/plugin".

Quote:

b) cyclic Java class paths

In order for the MWE script to access the *.xtext file, the editor
plugin must be on the class path of the build plugin containing the MWE
script. If the MWE script generates Java into the editor plugin then the
MWE script modifies something on the build plugin classpath, potentially
triggering a rebuild 'cycle' that does not actually rerun the MWE script
but does re-re-build all the transformation templates in the same build
plugin as the MWE script.

If instead an Xtext file was located via a StandaloneSetup import
declaration such as

modelPlugin = "org.eclipse.ocl.examples.xtext.oclinecore" // etc

the Java classpath would not serve a double purpose, the editor plugins
could be omitted from the classpath and the rebuild 'loop' is not created.


Yes, we usually reuse the runtime class path for code generation. This is also mostly because it is so convenient.
But of course not always ideal. Couldn't you just have a dedicated project for your code generation process, where you set up the class path only for that purpose?

Sven
Re: Xtend nearly unusable in big files [message #721198 is a reply to message #720939] Thu, 01 September 2011 07:23 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
Sven Efftinge wrote on Wed, 31 August 2011 16:07
That should only be the case if the edited Java file is referenced.

Today I don't encounter that problem anymore. Laughing

Sven Efftinge wrote on Wed, 31 August 2011 16:07
15 seconds still is too slow. Is that the project build or what happens when you save a single file?


It happens each time I save the file. And as the new builder shows the currently compiled file I see that the builder stops exactly on my huge files.
The builder always performs:
1. Xtext Validation (on edit)
1. Generating resource description for xxx.xtend (on save)
2. Validating resources
2. Compiling xxx.xtend



Sven Efftinge wrote on Wed, 31 August 2011 16:07
BTW: You should consider having more smaller files. That's not only a good idea for performance reasons.


I'll give it a try but it will require a lot of refactoring since there are quite a lot methods which depend on each other and often use dispatching.
Re: Xtend nearly unusable in big files [message #721206 is a reply to message #721198] Thu, 01 September 2011 07:32 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
[quote title=Daniel wrote on Thu, 01 September 2011 09:23]Sven Efftinge wrote on Wed, 31 August 2011 16:07

Sven Efftinge wrote on Wed, 31 August 2011 16:07
BTW: You should consider having more smaller files. That's not only a good idea for performance reasons.

I'll give it a try but it will require a lot of refactoring since there are quite a lot methods which depend on each other and often use dispatching.


Injected extension can significantly reduce the need for changing clients I guess.

Sven
Re: Xtend nearly unusable in big files [message #721252 is a reply to message #721189] Thu, 01 September 2011 08:59 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
On 01/09/2011 08:03, Sven Efftinge wrote:
> Firstly the class path scanning is only done when executing the
> Standalonesetup not while checking the MWE2 file within Eclipse. Also
> the scanClasspath property is just a convenient functionality, for
> those where this fit nicely. You can instead have multiple settings
> for platformUri = "file/path/to/plugin".
That was sort of what I was doing, but the standalone behaviour doesn't
know where ECLIPSE_HOME is, so I would have to hardcode as
"C:/Development/..." which won't work for anyone else. In an earlier
thread I 'announced' a solution passing ECLIPSE_HOME through the
launcher as an MWE parameter and suggested that this could be a built-in
facility. Sebastian highlighted that scanClasspath was a better solution.
> Yes, we usually reuse the runtime class path for code generation. This
> is also mostly because it is so convenient.
> But of course not always ideal. Couldn't you just have a dedicated
> project for your code generation process, where you set up the class
> path only for that purpose?
Only if I put my XXX.ecore in a different plugin to XXX*.java.

Build plugin needs XXX on the classpath for XXX.mwe2 to see XXX.ecore.

Running XXX.mwe2 updates XXX*.java.

I need to eliminate the spurious dependency of the Build plugin on the
XXX plugin via the classpath (or put the XXX.mwe2 script in the XXX
plugin which then puts unnecessary MWE run-time and other build-time
dependencies into the XXX plugin.)

Regards

Ed Willink
Re: Xtend nearly unusable in big files [message #721263 is a reply to message #721252] Thu, 01 September 2011 09:41 Go to previous messageGo to next message
Sven Efftinge is currently offline Sven EfftingeFriend
Messages: 1823
Registered: July 2009
Senior Member
You could also use a dedicated target platform which is reachable by a stable relative path from the project you are in.

I didn't get the XXX stuff. It sounded like you need to load classes you are generating in the same process which doesn't sound good, but I'm really not sure I got it.
Re: Xtend nearly unusable in big files [message #721310 is a reply to message #720981] Thu, 01 September 2011 12:27 Go to previous messageGo to next message
Daniel Missing name is currently offline Daniel Missing nameFriend
Messages: 101
Registered: July 2011
Senior Member
Eclipse User wrote on Wed, 31 August 2011 17:52

This is an Eclipse Update site/p2 repository; you must access it from
Eclipse.

Regards,
Dennis.


It seems the update site of the "lastest stable" build is empty. If I want to install the packages from it I only get a message "there are no items available". Can you please upload the latest stable build to the update site?
Re: Xtend nearly unusable in big files [message #721424 is a reply to message #721263] Thu, 01 September 2011 17:57 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Sven

> You could also use a dedicated target platform which is reachable by a
> stable relative path from the project you are in.
>
That was possible till we moved to GIT. Anything outside GIT has an
uncertain relative path.
> I didn't get the XXX stuff. It sounded like you need to load classes
> you are generating in the same process which doesn't sound good, but
> I'm really not sure I got it.
In the XXX (and XXX.ui) plugin:

I have XXX.xtext editor which imports the CS model is defined by
XXX.ecore, XXX.genmodel.
'Running' XXX.genmodel produces XXXPackage.java etc etc.
'Running' XXX.mtl produces XXXVisitor.java etc.

In the Build plugin:

I have XXXeditors.mwe2
I have XXXmodels.mwe2 and its support Java code
I have XXX.mtl and its support Java code
I invoke XXXmodels.mwe2
- invokes XXX.genmodel and XXX.mtl
I invoke XXXeditors.mwe2
- transforms XXX.xtext into ....

The Build plugin has the XXX plugin on its class path.
The Build plugin generates Java in the XXX plugin, which is on its
classpath; hence the partial loop.

Regards

Ed Willink
Previous Topic:Xtext editor working with custom resource
Next Topic:[Serializer 2.0] Hidden Tokens?
Goto Forum:
  


Current Time: Fri Mar 29 00:25:35 GMT 2024

Powered by FUDForum. Page generated in 0.04549 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top