Add overview of group

[koppor]

There is an an arrow on the upper left corner. But it is unclear where the arrow comes from. Normally, there is an upper part.

In my concrete case, I wanted to have an entry point for all Apache Commons libraries.

Triggered by https://lists.apache.org/thread/3j25mmkks5clykqsbclcl5j6b5vtc9br

Broken Javadoc link for commons web site (commons-compress page)
[...]
The Maven site was having problems yesterday as well. It might have been a
site wide issue, I'm not sure.

[Stewori]

The arrow symbol left of each breadcrumb just means that the item is opened in the bottom-left frame (the "package"-frame rather than on the right (the main/content or "class" frame). It's not straight forward to establish a group organization level consistently. What I usually do is represent artifacts in a group as modules (automatic modules for artifacts that do not define a module-info.java file). E.g. for netty or jackson, this integrates all modules/artifacts into a nicely browsable consistent profile. The tricky part is how to decide what goes into one profile and I did not find a good general soltuion yet. A big indicator that certain modules/artifacts should go together into a profile is common versioning. Jakarta and OSGI are the main examples where this fails (for JUnit 5 two versions are combined jupiter 5.13 and platform 1.13; for JUnit 6 they unified these). For Jakarta, I combine versions according to the bom file, but OSGI does not even provide this. The only way I found was to take the consistent full release from github and check @version tags in individual module-info files. No info on maven central seems to tell what individual artifact versions constitute e.g. OSGI 8.1.0.
I once did consider to combine Apache commons into one profile and decided it's better to keep them separate (same for dlsc components btw), because there does not seem to be a thing like a general Apache commons release. I even looked at the versions of commons-parent artifact but there is no consistent correspondence between commons-parent version and indiviual commons artifact versions. E.g. latest commons-csv is under commons-parent 85, latest commons-collections4 is under 81, and btw latest commons-parent is 93. What I make of this is that commons-parent is purely a config mechanism, no overall version provider. An idea similar to JabRef snapshots is to take all latest releases at a particular date and use that date as an overall profile version. I did this experimentally for JNR https://apidia.net/mvn/com.github.jnr/jnr but somehow it feels wrong and unofficial.
Maybe one could take the dates of the commons-parent releases, e.g. of 93, and combine all latest individual commons releases of that date into a fictional overall commons release called e.g. 93. That would look more professional than using a date as a version. An issue with this is that also old obsolete commons-projects would participate. A logic would be needed to exclude discontinued projects. Some commons releases switched group in the past, e.g. collections <4 was under https://apidia.net/mvn/commons-collections/commons-collections, still it uses org.apache.commons/commons-parent. Namely, 39. So, e.g. commons-collections/commons-collections was discontinued and replaced by org.apache.commons/commons-collections4. I suppose a group change is no reliable indicator for obsolescence though. This also rises the issue: Are there more relevant commons members in groups other than org.apache.commons? Do we know that all of these are obsolete? I'm afraid one would have to check manually for each commons project on its website. Likely for every new release. Or is there a maintained canonical list somewhere?

[Stewori]

Looking at the org.apache.commons group I remember another reason why I decided to keep them separate. Some commons projects do already consist of several modules, e.g. https://apidia.net/mvn/org.apache.commons/commons-numbers. All artifacts commons-numbers-* are combined to one profile. Combining several different commons projects in this manner would flatten this organization level and result in a very large profile. OTOH the standard lib consists of roughly fifty modules and it's still somewhat okay. Introducing another hierarchy level, e.g. "Projects" above "Modules" would pay off only if there are various more use cases. Eclipse-platform and EE4J perhaps.

I also thought about having a maven browser in the existing APIdia l&f, i.e. with the three frames but with packages being maven groups and classes being artifacts. "Javadoc" would be generated from pom info. One might rather display groups as currently modules so that packages may represent a structure within a group. E.g. org.apache.commons would be presented like a current module and artifacts like commons-numbers-parent would be a package containing those artifacts that have commons-numbers-parent as parent. But this effort would be almost like adding a new programming language to APIdia.