Fully qualified classname definitions and references

[davecahill]

Background

Say we have classes a.b.c.MyClass and d.e.f.MyClass. The current refs and defs features don't differentiate between these two.

The proposal is to add fully qualified definitions and references so we can:

• Link from usages directly to the canonical definition (Not just "show all definitions of classes called MyClass")
• Link from class / method definitions to all usages of that class / method (instead of to all usages of classes / methods with the same name)

Open questions

• The definitions will cross project boundaries - how to set the projects list to search across? Maybe always use all projects search instead of same-project search?
• What exactly should the UI change look like?

I'm currently looking into how to achieve this, but filing the issue without info on how it will be developed in order to start the conversation.

[vladak]

Sounds good in general.

The cross-project part seems to be the most problematic. Current design treats projects as separate entities. Maybe something like "friend" projects can be introduced that would pave the way ? Or just stick with current design and organize the repositories in a single project.

[davecahill]

Current design treats projects as separate entities. Maybe something like "friend" projects can be introduced that would pave the way ?

Is there somewhere I can learn more about why projects are seen as so separate? In our usage, we mostly search across all projects (hence my comments in #1621 about a fake "!all!" project). One possible solution I thought of here is when we show refs / defs links, we set project in that link to be whatever the user is using in their cookie - that way if people are usually using "!all!" as their "project" it would just work. Currently I think project in the link just gets set to the project of the code you're currently looking at.

One other design point: do you think we should just add values into refs and defs so that these would contain unqualified and fully qualified refs / defs, or have separate fields (fqrefs / fqdefs)? At first glance, it seems reasonable to have them in refs / defs, since the fact that they are dot-separated means they shouldn't clash.

[davecahill]

@vladak One way I'm looking at doing this is to use a java parser library instead of ctags, overriding the ctags output at the Java Analyzer level. The java parser library itself would be reasonably big - does that seem like the kind of dependency we could consider adding? My assumption is that we would first open source and upload to maven the java parser lib, then depend on it from OpenGrok. I can add more details later, but wanted to get an initial reaction.