Bug 363651

Comment 1 Ed Willink 2011-11-17 04:51:24 EST

I have just seen this happen on Acceleo 3.1.2.

Perhaps it's not an Acceleo 3.2 problem at all.

In the same time frame I split off the Acceleo templates for the OCL2Java code generator into a separate plugin, and so I now have two plugins with Acceleo natures. Perhaps it's a multi-builder problem.

Comment 2 Laurent Goubet 2011-11-21 03:50:58 EST

I have also been bit by this, but cannot pinpoint the issue in a reproducible manner. This must be fixed for the release of 3.3.

Comment 3 Ed Willink 2011-11-21 04:20:06 EST

(In reply to comment #2)
> I have also been bit by this, but cannot pinpoint the issue in a reproducible
> manner. This must be fixed for the release of 3.3.

Having reverted to 3.1.2, my subjective observation is that 3.1.2 fails to build on perhaps 5% of occasions, whereas 3.2 fails to build on 33%. Of course 3.1.2 has significantly worse editor problem synchronization issues, but these are at least visible and can be fought by cleans/dummy edits.

I suspect that the double project is relevant. The 3.1.2 errors have perhaps been a clean of *.emtl in the dependent project after a separate project close or perhaps enable/disable automatic builds.

I strongly recommend solving this by analysis and design rather than debug. The maintenance of markers in the editor is so poor as to be close to unuseable after any edit has been performed, so it is not really surprising that the builders do funny things too; the whole scheduling of 'builds' is suspect. Probably associated with a concurrency issue between editor builds, nature builds and multiple dependencies. Why could my deadlock observations in bug 363855 show 13 threads updating markers?

I'm pretty sure that GIT also has bad builder interactions, forcing me variously to just quit Eclipse and restart without an active GIT synchronisation, and/or disable auto-build until the rebuild anarchy settles down. So GIT may be provoking the Acceleo synchronization bugs.

Acceleo needs to guarantee that concurrent nature builds are independent or sequenced and that editor builds are independent. When using IMP I found this quite hard, until I made sure that the current AST was not accessible by casual getters. Xtext seems to solve the problem by prohibiting casual access to its current CST, requiring CS URIs to be resolved by IUnitOfWork synchronization. Note that SWT has slightly different markers for editors (Annotations) and builders (Markers) and I'm not convinced that Accelo honours the distinction. Sometimes I find the editor insists on showing fictitious errors that persist after determined cleans. Just deleting the problem markers cures the 'problem'.

Comment 4 Ed Willink 2011-12-08 13:34:54 EST

With Acceleo 3.1.2, opening, or closing a project such as org.eclipse.emf.ecore seems to be a fairly predictable way of having an emtl-free bin tree.

Comment 5 Laurent Goubet 2012-01-06 05:03:17 EST

Just realized that we haven't really communicated on this, but we are currently in the process of a large overhaul for our builder infrastructure. We also consider this bug as a major hindrance and expect to fix this issue in the 3.3 release.

We doubt that this will be done for M5, but it should be ready soon after that.

Comment 6 Stephane Begaudeau 2012-01-10 08:22:27 EST

The Acceleo parser has now a brand new front end in order to:
1- ensure a better resolution of the links between modules
2- ensure that all the necessary modules are compiled
3- have a fully stand alone parser

This new front end comes with stand alone unit tests (the old front end was not easily testable even if the core of the parser is tested with > 92% code coverage). 

This new front end has been contributed only on 3_2_maintenance for now (since Laurent is mainly working on master, I didn't pushed it there yet).

It will be available for Acceleo 3.2.1 and for the Juno release. The improvements for Ant and Maven (for the Juno release) will use this new front end since it has been created with those stand alone use case in mind.

The days/weeks to come will be used to test this new front end before the 3.2.1 and juno release. This new front end does not change:
1- the algorithm used to parse the text of the mtl files
2- the algorithm used to create the syntax tree representing the file
3- the algorithm used to resolve the content of the modules (operation calls, etc.)
4- the algorithm used for the serialization of the modules (binary of xmi)

The Acceleo builder has been recreated from scratch in order to use the new front end of the Acceleo parser. This new front end for the parser and the new builder are accessible starting with the build #26 on the m2t-acceleo-3.2 job. Of course, since its the very first job involving this new builder, use with caution :)

https://hudson.eclipse.org/hudson/job/m2t-acceleo-3.2/26/

Comment 7 Ed Willink 2012-01-11 13:15:34 EST

I've filed a couple of bugs on #26. These were irritating but non-fatal.

Unfortunately the 'smart' update is very broken.

With no errors, after a rebuild.
Delete character in an operation so that ere are some errors.
Restore character. Not all errors go away.

Got to go back to 3.1.2.

Comment 8 Stephane Begaudeau 2012-04-24 09:47:59 EDT

(In reply to comment #0)
> I'm getting a lot of problems with the builder not building; the bin
> folder contains *.class, *.mtl but no *.emtl. And it is harder to force a
> rebuild. I'm forced to check the bin folder before executing my mwe scripts.

With all the persons that have tested it and with the unit tests available. The problem of missing emtl files seems to have been resolved. I'm closing this issue.

Comment 9 Ed Willink 2012-05-09 08:49:10 EDT

(In reply to comment #7)
> Got to go back to 3.1.2.

3.3M7 looks good for me.

Comment 10 Laurent Goubet 2015-05-27 08:56:21 EDT

Closing resolved bugs