Community
Participate
Working Groups
I20050920 We should investigate whether it is possible to open classpath entries in a container to be classpath variables, or classpath containers.
Build path issue.
What is the motivation in 3.4 for doing this ?
I think the focus should be on containers in containers. This would allow PDE to rebuild the plugin dependency hierarchy on the classpath similar to the load time hierarchy in runtime. With this, it will be possible to correctly resolve types and build hierarchies of elements in the PDE container as now all their references can be resolved correctly. This is bug 73957 in PDE with lots of duplicates.
I think this would simplify PDE's life by letting JDT flatten the classpath on its own; but in theory PDE could do the flattening on its own, and have its container answer this flat list of entry. So technically speaking, I don't see containers-in-containers as solving new kind of problems, but rather as a helper so minimize code on the client side. Am I missing something ?
I believe a flattened list can not rebuild a hierarchical lookup path. Problems are: - visibility of types that aren't supposed to be visible - shadowing of types with same qualified name that didn't exist in the hierarchical lookup Assume this dependency tree: A requires B1 requires C1, D1 B2 requires C1new, E1 B3 C1new (A requires B1, B2, B3 and C1new. B1 requires C1, D1. ... C1new is a newer version of C1, think JUnit 3.8.1 and 4.0)) If you flatten the list to: (depth first) A requires B1 C1 D1 B2 C1new E1 B3 you have the following problems: - Suddenly C1, D1 or E1 are on the classpath of A. These types should not be visible to elements in A. - Types in C1, D1, and E1 can hide types of the same qualified name in B2, B3 and C1new - C1new was specified to be after B3. Now it is suddenly before. Again this can be a problem with type hiding If you flatten the list to: (breath first) A requires B1 B2 B3 C1new C1 D1 B2 E1 - Again the visibility problems. - resolving in B1 will not find C1, but the newer version C1new - resolving in B1 might find types in all other projects (B2, B3) although they are not on its class path. Maybe I'm missing something. I think what containers in containers allow is to rebuild the same dependencies tree and export features that you can express with Java projects. Besides correctness, it also allows us in the UI to present the plug-in dependencies tree in the form is has been defined. A flattened list is confusing for the user as well. Having the same plug-in twice with different version is not a corner case anymore. See the Orbit project that want to have org.junit in versions {3.8.1 and 4.3)
I see now what you meant. Indeed, issues arise in presence of multiple versions of a bundle. +1 for 3.4
To be investigated for 3.4
This is fantastic news (that you are investigating for 3.4)
After investigation, it appears that this item would involve a complete rewrite of a good part of the Java model. The Java model currently assumes that the classpath is flat. Optimizations are all over the place with this assumption. Introducing a recursive classpath is a major change that cannot be done for 3.4. Differing to early 3.5
After more investigation, it goes even further than rewriting the Java model. The compiler would also need to be rewritten to handle the fact that bindings with the same full qualified name are no longer identical. This is too big of a change given what we have on our plate (not speaking about the huge performance degradation that would result from this change). Another solution will need to be investigated for resolving bug 73957 and bug 148844. Maybe creating a hidden Java project for each plugin would work? Of course, one would have to consider the scalability of such solution.
