Community
Participate
Working Groups
M7+: Acceleo 3.1.0.v20110505-1129 This is basically Bug 335761 with a different error message. [I do not understand why you CLOSE bugs immediately. Surely you RESOLVE when the fix is committed to CVS and then CLOSE once the fix has been verified in use.] Now, when I edit an MTL file, imported queries are marked as unresolved. The problem goes away if the imported module is null-edited and saved.
Stephane will answer about the bug itself, but as regard to process... (In reply to comment #0) > [I do not understand why you CLOSE bugs immediately. Surely you RESOLVE when > the fix is committed to CVS and then CLOSE once the fix has been verified in > use.] That's true ... but we have a habit of forgetting to close the bugs afterwards :). The actual process should be something like what's described on http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use ... but not all users come back on the bugs to mention they have verified the bugs (you're actually one of the rare ones). As such, we "close" the bugs ... and "reopen" them if a user comes back to us with a negative feedback. We (well, at least I) don't make use of the "assigned" and "resolved" status.
(In reply to comment #1) > > [I do not understand why you CLOSE bugs immediately. Surely you RESOLVE when > > the fix is committed to CVS and then CLOSE once the fix has been verified in > > use.] > > That's true ... but we have a habit of forgetting to close the bugs afterwards > :). The actual process should be something like what's described on > http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use ... but not > all users come back on the bugs to mention they have verified the bugs (you're > actually one of the rare ones). > > As such, we "close" the bugs ... and "reopen" them if a user comes back to us > with a negative feedback. I don't have a problem with you closing bugs; just wait at least a week after the fixing milestone, and quite possibly a couple of milestones, so that you can treat no-complaints as verified. Closing a bug before any user has seen a fix seems much too soon. There is perhaps a good case for having a close-the-bugs session two weeks after each release or service release using the list of fixed bugs in the release as the driver. > We (well, at least I) don't make use of the > "assigned" and "resolved" status. I also find assigned unhelpful; it accidentally shuts out the rest of the team.
Unfortunately, most of the people who are raising issues do not come back to confirm that the fix is working. We (logically) mostly hear about people who have a problem so we close bugs when they have a fix and if it's not working people will reopen them. But we can wait for a week after the milestone containing the fix before closing the bug. On the bug itself, I haven't been able to reproduce it. Do you have a small example illustrating the problem ?
(In reply to comment #3) > On the bug itself, I haven't been able to reproduce it. Do you have a small > example illustrating the problem ? The real code is not small, but not really very large. I suspect it's a referencing problem that will get lost when simplifying. The MTL files are all in org.eclipse.ocl.examples.build. The referenced meta-model is in org.eclipse.ocl.examples.pivot, if you haven't got the OCL Examples and Editiors installed. Check these two out from cvsroot/modeling and delete all MWE, Xtext stuff if it gives dependency errors. Edit src/org/eclipse/ocl/examples/build/acceleo/generateOCLstdlib.mtl within a [template] block. For instance, type a space after the [/file] near the end of the file. Errors appear. null-edit and save generateOclCommon.mtl to make errors go away again.
Another case of on the fly compilation with dynamic metamodels that manipulates two instances of the same metatype (one "created" by OCL during the parsing and one loaded from the serialized imported module) and of course the comparison "oclType1 == oclType2" fails in the TypeChecker. A fix has been contributed on HEAD, it will be available in Acceleo 3.1.0 RC1. It can be tested from this nightly build: https://hudson.eclipse.org/hudson/view/Modeling/job/m2t-acceleo-3.1/171/ It should fix the problem (for the third time) but I wouldn't be surprised if another use case could produce another variation of the same problem.
(In reply to comment #5) > A fix has been contributed on HEAD, it will be available in Acceleo 3.1.0 RC1. > It can be tested from this nightly build: > https://hudson.eclipse.org/hudson/view/Modeling/job/m2t-acceleo-3.1/171/ Looks promising. I think I can finally edit MTLs without a splurge of spurious squiggles. > Another case of on the fly compilation with dynamic metamodels that manipulates > two instances of the same metatype (one "created" by OCL during the parsing and > one loaded from the serialized imported module) and of course the comparison > "oclType1 == oclType2" fails in the TypeChecker. > I now call this meta-model schizophrenia, and since it is an advanced meta-modeling problem that occurs through careless use of EMF, rather than a limitation of EMF itself, I suspect that OCL may be where the problem should be fixed. See Bug 323878. For now you might want to add a relatively cheap diagnostic check that there are no duplicate EPackage nsURIs in a ResourceSet.
Since the move to the new builder I did not see this problem anymore, I'll consider this issue fixed for Acceleo 3.2.1 and 3.3.0.
Closing resolved bugs
