Max Rydahl Andersen wrote:
"Adding everything by default" is what I mean and I also mean that we can't have a optional runtime that includes everything.
Simply because "include everything" => broken classpath.
Hmmm, okay. I think I'm slowly starting to understand the issue (I'm a somewhat older guy, so those things take some time with me :p ). The point is thus that in reality there is a class loader hierarchy in place, where classes are shielded from each other. But Eclipse has no such notion, and will simply put everything on a flat classpath when "everything is included", right?
I agree - but adding jars onto the classpath is unfortunately not just about Ctrl+T working but it also affect junit launches and other things.
I understand this now. Thanks for pointing it out, Max!
What we maybe need is a system for decoupling class discovery (Ctrl+T) and introspection (type hierarchy, references, etc) from presence on the classpath. This is never going to be an easy thing of course and should maybe be solved at the Eclipse/JDT core. I'm imagining a system where a library container/server runtime has a large collection of classes in jars that it manages, with only a subset of those being put on the classpath by default and where the user can pick and choose additional jars.
In the case of Jboss, the server runtime would indeed only put the API classes on the classpath, but it would participate in Ctrl-T searches and respond to a query for say "FacesContextImpl" (even though that particular class isn't on the classpath). Double clicking on the search result would open the file with source visible, and if "link with editor" is enabled I would see the containing jar in the project explorer. Right clicking on said jar would enable me to directly add the jar to the classpath.
Could that theoretically work?