Max Rydahl Andersen wrote:
I hear you :)
More suggestions and reason/arguments for both sides are very much welcome.
Thanks for your understanding response!
It's maybe interesting to notice that both the JRE classpath container in Eclipse and the Glassfish one do expose the implementation classes.
I would say a good compromise is to install the hiding classpath container by default, but give users the option to either install the full one separately, or (maybe even better) let the user switch between limited and full by means of a property on the container.
Not sure if the last thing is easy to implement in Eclipse though. Classpath containers do have property pages when right clicking on them in e.g. the project explorer view, but they typically cause an other container to be used in .classpath (e.g. system default JRE vs a specific one).
At any length, that location would be the first place where I think users would look to change the behavior of a given container.
One step further, if JBoss tools knows about a limiting (API only) and full classpath container, it could potentially validate the code to see if classes are used in the project that are only in the full container and not in the limiting one or otherwise on the classpath. A warning could be flagged for that situation.