Community
Participate
Working Groups
Build Identifier: Eclipse 3.6.2 M20110210-1200, Xtext 2.0.0.v201105171404 Google Guice requires following a name convention when defining injects, e.g. @Inject extension Example example Using @Inject extension Example different would result in different = null despite of the injection of Example. It would be nice, if the Xtend2 editor validator would mark that. (Same to injection of normal Java class files). In a normal Java editor this is also not recognized for Google Guice injections but a normal Java editor has not capabilities Xtend2 potentially has ;) Reproducible: Always Steps to Reproduce: 1. Create Xtend2 file 2. type @Inject extension Example different 3. this should be marked as error but it isn't
when defining extension injections wrong all methods of this extension cannot be resolved. But as explained before the extension definition itself is not marked as error, so you may assume that the deletion of methods in a super class are the cause of the problem.
(In reply to comment #0) > Build Identifier: Eclipse 3.6.2 M20110210-1200, Xtext 2.0.0.v201105171404 > > Google Guice requires following a name convention when defining injects, e.g. > > @Inject extension Example example > > Using > > @Inject extension Example different > > would result in different = null despite of the injection of Example. I don't get this. Why would the latter be a problem? Could you point to some docs on the Guice web site or so, to make clear what you are referring to?
sorry, this comment #1 descibes the behavior of bug #346242, I mixed it up. (In reply to comment #1) > when defining extension injections wrong all methods of this extension cannot > be resolved. But as explained before the extension definition itself is not > marked as error, so you may assume that the deletion of methods in a super > class are the cause of the problem.
ok, this bug has been gone with the current Xtext version. When using the version of 2011-05-14 inside the implementation of IJvmModelInferrer the method cloneWithProxies could not be resolved when one of the injected extensions did not match in class name and field name (only starting with lower case). Now the field name has no influence anymore.
