Bugzilla – Full Text Bug Listing
| Summary: | [tooling] Builder inhibits UI | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | stephane.begaudeau |
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Ed Willink
(In reply to comment #0) > a 5 to 10 second wait Perhaps I exaggerate 2-3 seconds, but even editing is locked out after a save. A fix has been contributed on R3_1_maintenance, it will be available in Acceleo 3.1.1. 3.1.1 I don't think this is fixed, but with so many ergonomic problems in the Acceleo editor/builder/URI resolution, it is difficult to know what causes what. But I think it's now major if not critical. Basically maintenance of GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.codegen\src\org\eclipse\ocl\examples\codegen\ecore\ocl2java4genmodel.mtl is extremely difficult. I'm resorting to using the naked text editor wherever possible so that I only twiddle my thumbs waiting for Acceleo when I need a syntax check/executable code. Amongst other problems my console log fills with org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.FileNotFoundException: ..\..\org.eclipse.emf.ecore\model\Ecore.ecore (The system cannot find the path specified) despite my opening org.eclipse.emf.ecore as a project to that org.eclipse.emf.codegen.ecore can see it as ../.. You might like to look at GIT\org.eclipse.ocl\examples\org.eclipse.ocl.examples.domain\src\org\eclipse\ocl\examples\domain\utilities\ProjectMap.java which supports initialization of a ResourceSet so that platform:/plugin and platform:/resource are universally mapped for plugin or standalone usage. This works well for my standalone launches. If you used it for the editor and the builder, URI resolution issues might go away. One particular bad scenario is that after a bit of editing... builder goes away then Control-C and/or Control-S is ignored so that if you just try to carry on editing you lose a copy or paste. Worse if the builder generates an error message, the copy may be from the error log. Sometimes paste is shut out until a File->Save is performed. There appears to be a major thread partitioning/synchronization and focus problem. (In reply to comment #4) > then Control-C and/or Control-S is ignored so that if you > just try to carry on editing you lose a copy or paste. Worse if the builder > generates an error message, the copy may be from the error log. Sometimes paste > is shut out until a File->Save is performed. After watching closer, it appears that hover generates an error due to inadequate URI resolution and this causes the error lo to take focus so that edit actions are stolen. [Of course the editor is too useful to get far with a naked text editor, in which the builder nonetheless maintains error markers.] I'm not sure if this is the right Bugzilla to comment on. In Acceleo 3.1.0 the builder was very over-enthusiastic seeming to build at every possible opportunity. This was irritating, requiring Build Automatically to be disabled while Acceleo/Xtext/GIT stbailized; at leasxt partially a GIT bug. In Acceleo 3.1.1 and 3.2 RC1, I am seeing the reverse; the EMTL files are often stale or missing; I've had an NPOE on the return from getClass()!. I am learning to clean the project by hand to force a build. I'm marking this issue as resolved once again since the missing emtl files problem has been fixed. Closing resolved bugs |