Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Compilation warnings
Thanks for the isUnusedCheck hint. It seems to be doing what I need, so I replaced the "<" check by a call to isUnusedCheck(genClass), re-generated and didn't get a diff. Good.
Next, I'll raise an EMF bug, suggesting the patch. Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=339035
In the meantime I'll add a comment to the Class.javajet telling the CVS revision of the original from where it was branched. This should enable later merging of changes to the original until we hopefully get the patch merged into EMF's original template. 

Best,
-- Axel

On 3/6/2011 4:48 AM, Ed Willink wrote:

Hi Axel

I checked in a templates/model/Class.javajet in the *.testmodel.ngpm
which generates additional @SuppressWarning("unchecked") annotations
to avoid the warnings where an unsafe cast in a delegating operation
is needed. I re-generated the model code and committed it. The
warnings seem gone project-wide.


Well done. A simple fix that works. Since the fix is simple, local and
for eInvoke() code that first appeared in Helios, there should not be a
problem with ten year old IBM compatibility; eInvoke code is still
settling down.

The test for "<" is indeed klunky, but a scan for similar suppress
uncheck annotations reveals a precedent elsewhere in the template. There
are also a number of uses of isUncheckedCast gen model queries. It would
be worth seeing if one of those fits the bill.

Definitely worth pushing to EMF.

----------------------------------------

Your use of a Class.javajet clone demonstrates precisely why I want to
avoid local templates if at all possible.

The template is there solely for cosmetic purposes. If you manually do
all the @suppress unchecked quick fixes method-wise, you can then
regenerate and organise imports on the src tree and all warnings are
gone again. It is perhaps a bug, though it would be a good design
intent, that the method @suppress annotations are preserved. Anyway we
don't actually need the template to have no warnings after regeneration.

The problem with the clone is that it has no indication of what version
it branched from so every future EMF fix risks breaking your models. As
a minimum put a comment in the header to show the branch point and
document the motivation (test scenarios) for all internal changes.

Please eliminate the clone from MDT/OCL and, if EMF rejects the fix,
then commit the manually applied quickfixes so that regeneration is easy.

Regards

Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

Back to the top