henk de boer wrote: > Max Rydahl Andersen wrote: > > Note, adding everything is not the solution. > Max, just wondering what you exactly mean by this. Do you mean adding everything by default to the standard JBoss server runtime, or providing an optional JBoss server runtime that includes everything? "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. > As mentioned, I agree that it might be a good idea to only provide API classes in the standard runtime (shield most developers from accidentally linking to implementation classes). > > But if you mean the second thing, I don't see how not adding everything would not be a solution for advanced developers who simply need everything? Which jar with duplicate classes do you want to have to win ? :) > Currently the AS 6 runtime includes almost everything, but you guys have forgotten a few jars here and there and indeed me and some of the other developers on my team have run into problems missing exactly those (if I remember correctly, it was e.g. the timerservice in common/deploy/ and some Tomcat related classes). The workaround is to add those jars to your project's classpath, but don't export them to the deployment. This allows you to do ctrl-t, call hierarchies, etc. It's a bit of a hassle, as basically you do want to keep those jars out of version control, so you have uncommitted changes in your project all the time and have to redo this at every location you work. Open jiras for jars we are missing and we'll add (especially for pre-AS7 ones where its almost "random" anyway ;) > The point is that there are always cases developers run into. I find it hard to think of any jar or class in JBoss that should always and permanently be 'hidden'.

Max Rydahl Andersen wrote: Classpath containers doesn't work like you suggest unfortunately - they can't "extend" Ctrl+T without adding stuff to the actual classpath.