I believe the compiler links somehow to a particular version of an interface... Even if the methods signatures are the same, if the interface is different, I'm not sure it links correctly.
That sounds rather bizarre to me ...I will investigate a bit
The error I had with JDT 3.1 was java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/e clipse/jdt/core/compiler/CategorizedProblem;
Thanks for the pointer
What I'm not sure is what would be the best way to solve it... Just add a different compiled version of the eclipse plug-in or create a different plug-in?
My initial idea was to have one codebase with a detached release cycle for the the compiler modules. So we would have a 3.1 and a 3.2 branch of the plugin.
The problem in making a different compiled version is that it won't be easy to run the test suites against both versions.
But you are right testing-wise it would be not that perfect . On the other hand ...if you consider them different artifacts ...don't know
It would be nice to create different classes and maybe have a way to select inside JCI the appropriate version.
Problem is that a 3.1 and a 3.2 compiler most likely won't work in the same classpath.
Btw, another change I would suggest in JCI is to remove all static caches.
Can you elaborate what you are referring to? Not aware of any statics ...execept the singleton instances. cheers -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
