Bugzilla – Full Text Bug Listing
| Summary: | Improve the generator to take existing imports into account | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Ed Willink <ed> |
| Component: | Tools | Assignee: | Dave Steinberg <davidms> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Ed.Merks, give.a.damus |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Ed, Could you try deleting all the imports and regenerating? I don't believe EMF will generate a duplicate import, but it will pick one of the two to import (the first one that it encounters while generating the code will be "demand imported") and if it picks one different from what's already in the file, you'll get the result you are seeing. So I definitely expect the first use to be imported and the second one to remain fully qualified as your are seeing, but I don't expect to see conflicting imports being generated directly (only as a result of merge). We already have https://bugs.eclipse.org/bugs/show_bug.cgi?id=167935 open to deal with all the issues associated with the need to replace type parameters with their substituted arguments in any context where such a substitution is needed. I imagine it would be nice to prime the import manager used to generate the new source based on the imports already in the existing source, so if your problem here is not one of directly generating conflicts but rather one that results from merging, I'll use this bugzilla as request for improved import manager support. Yes/No, the erroneous imports were 'self-inflicted', caused by a wrong attempt to fix the compilation errors. I actually had coded
if (baseClass == Variable.class) {
switch ...
}
if (baseClass == org.eclipse.ocl.ecore.Variable.class) {
switch ...
}
with org.eclipse.ocl.ecore.Variable imported!
If I start with
import org.eclipse.ocl.ecore.OCLExpression;
import org.eclipse.ocl.ecore.Variable;
genmodel adds
import org.eclipse.ocl.expressions.OCLExpression;
import org.eclipse.ocl.expressions.Variable;
If I delete the duff imports, genmodel is fine (import-wise).
I guess you are not allowed to remove 'user' imports, so must detect existing imports and explicitly qualify all conflicting class-names - mega-pain.
Since bad imports is one of the major problems I encounter after regenerating after a change perhaps you should just rewrite the imports, then use the left-overs as hints to resolve the rest. Maybe an @import for explicit stuff.
Currently renaming model element XXX to YYY causes a bad stuck import of XXX at
least and sometimes a bad stuck ordering of literals too.
Ed, Some of what you ask for (cleaning up imports) is also asked for in https://bugs.eclipse.org/bugs/show_bug.cgi?id=175282. I'll morph this bugzilla into a feature request with the idea being that the imports of a newly generated result could be guided by the imports already in the previously existing result. *** Bug 221748 has been marked as a duplicate of this bug. *** I'm modified the Java generation logic so that the import manager is primed with the imports of the existing target. The changes are committed to master for 2.9 http://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=8efdfc67c3ee20b03d28b05604eae2a9f34abbbe The changes are available in Kepler. |
I200704121441 The (E)QVTbase model (see org.eclipse.gmt/umlx/plugins/org.eclipse.gmt.umlx.eqvt/model/eqvtbase.ecore in /cvsroot/technology) defines FunctionParameter with EParameter and Variable as super-types. The M6 OCL defines Variable as a specialisation of Variable<EClassifier,EParameter> genmodel now (since M5, possibly since M6) generates conflicting imports for both OCLExpression and Variable. import org.eclipse.ocl.expressions.OCLExpression; import org.eclipse.ocl.expressions.Variable; import org.eclipse.ocl.ecore.OCLExpression; import org.eclipse.ocl.ecore.Variable; an inconvenience combined with many other problems with implementing this very provocative re-use of names to specialise generics. (Do you want bugzillas on the failure to specialize the generated function signatures?) More seriously in eDerivedStructuralFeatureID, only one of the two ambiguous names is fully qualified: if (baseClass == Variable.class) { switch ... } if (baseClass == org.eclipse.ocl.ecore.Variable.class) { switch ... } since the first (org.eclipse.ocl.expressions.Variable.class) is the less derived, a manual clean up of the numerous compilation problems does not highlight the problem and bad code results. [I think this is really a problem with the OCL renaming approach, but if OCL is to do renaming, EMF has to support it.]