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.

Max Rydahl Andersen wrote:

 

More suggestions and reason/arguments for both sides are very much welcome.

M5 has been released now, but it seems there has been no progress on this issue, has there?

Any chance you guys can still do something here before the GA?

It would really be a shame of the entire discussion we had over the past years to make source attachments easier, and now this finally seems to happen there is almost nothing left to attach the source to.

Snjezana Peco wrote:

 

Henk,

 

You may want to take a look at https://community.jboss.org/community/tools/blog/2012/01/24/jboss-source-lookup

Sorry for the late reply, I totally missed the previous post. Some of the things sound very good Especially the ability to see sources for those classes/jars that the server runtime providers can't/won't/didn't include.

If you forgive me for being too critical, there are maybe two things that might be slightly improved. The first one is about this point: "set up the central JBoss Maven repository as explained in"

Personally I like to avoid Maven as much as possible. None of my projects use Maven. I either just use the Eclipse builders and/or Ant. If a tool uses Maven under the cover, then that's an implementation detail I don't mind, but if I have to explicitly install and configure Maven then that's quite another thing. Maybe it's a personal awkward thing of me, but there might be more users who don't want to be explicitly confronted with Maven (I think surveys from Eclipse and Zeroturnaround revealed only ~50 of Java developers use Maven).

Another things concerns this point "you can add a Server Runtime container to the project's classpath (optional)". To me it was not 100% clear what this meant. Isn't this already possible without JBoss Tools, or does it mean that a source container can be added to the project's classpath?

The final piece of the puzzle is opening implementation classes that aren't included by default in the server runtime using ctrl-t and actually compiling your own code against those. I know that "normally" you shouldn't do this (for portable Java EE apps), but it can be very important for bug hunting and temporary workarounds.

Anyway, I'll try the feature tomorrow. Thanks again!

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?

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?

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.

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:

 

"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 ). 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?

Just wondering, is there already some progress here?

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.

Indeed, so what I meant that this should be addresssed with the core Eclipse JDT guys. Of course that won't be trivial, but if more people think that this is at least a good idea it might be worth a shot.

I'll try your workaround, thanks again!