Mike, this is 2.x and I'm 99% sure I recall that its happening after pre-resolve
Regards, Kelvin. 2009/6/3 Mike Edwards <[email protected]>: > kelvin goodson wrote: >> >> I'm seeing an NPE here >> >> // No definition found, delegate the resolution to the imports >> for (Import import_ : this.contribution.getImports()) { >> if (import_ instanceof NamespaceImport) { >> NamespaceImport namespaceImport = (NamespaceImport)import_; >> if >> (namespaceImport.getNamespace().equals(qname.getNamespaceURI())) { >> >> // Delegate the resolution to the import resolver >> ======> resolved = >> namespaceImport.getModelResolver().resolveModel(Composite.class, >> (Composite)unresolved); >> if (!resolved.isUnresolved()) { >> return modelClass.cast(resolved); >> } >> } >> } >> } >> >> because the result of getModelResolver() is null >> >> I'm digging into it, but I'm learning what the code does so it's >> taking me a little while. Has anyone else seen this and have an >> insight as to why its happening. It's probably a config thing in my >> eclipse env. >> >> cheers, Kelvin. >> > Kelvin, > > Is this on 1.x or on 2.x ?? > > I ask this question because I believe that I fixed the problem in 2.x by > introducing a pre-resolve phase into the processing of Contributions which > avoids the problems such that you are describing here. > > I have not attempted to port this 2.x fix back to 1.x. > > Basically, the problem is that it can be hard for the runtime to work out > what Contributions depend on which other Contributions, especially if there > are imports for different namespaces/packages from different Contributions. > In the old code, if the order was misguessed, you find the modelResolver > problem above. > > In my fix, pre-resolve ensures that every export & import combination are > given modelResolvers BEFORE any resolution of any Contribution takes place. > Then if resolving one contribution means following an import into a second > contribution, the export already has a resolver on hand even if its > containing contribution has not been resolved yet. > > I am sure that the same idea could be backported to 1.x if required. > > > Yours, Mike. >
