Expand my Community achievements bar.

Why the "uber-jar-6.5.5-sources.jar" does not contain the source code of all open source libraries and why the file "uber-jar-6.5.5-javadoc.jar" does not contain Javadoc for some proprietary code?

Avatar

Level 3

Hi, 

I have two questions which are related to the usage of the "uber-jar" in an IDE like Eclipse: 

 

Question 1) Why the file "uber-jar-6.5.5-sources.jar" does not contain at least the source code of the open source libraries which are included in the uber-jar? Why it is either empty or not provided by Adobe at all? 

For example, why it does not contain the source code of "org.apache.jackrabbit.api.security.user.UserManager"? 

At least the file "uber-jar-6.5.5-javadoc.jar" contains the Javadoc of the above-mentioned class, but why the file "uber-jar-6.5.5-sources.jar" does not contain its source code? It is an open source project and you can see links to its source repository here: https://jackrabbit.apache.org/jcr/source-repository.html

Therefore I do not understand why Adobe did not include it (and the source code of other open source libraries) in the file "uber-jar-6.5.5-sources.jar". 

In case if Adobe does not provide the "sources" file for its uber-jar at all (it is currently unavailable under the Adobe's public repo, as of 4th March 2021), then why Adobe does not provide it? 

 

Question 2) Why the file "uber-jar-6.5.5-javadoc.jar" does not contain at least the Javadoc of some proprietary classes which are not open source? (I don't mean their source code here as these seem to be some proprietary "closed" code of Adobe, but at least their Javadoc should be available.)

For example, why it does not contain at least the Javadoc of all classes which are located in the package "javax.jcr" and its sub-packages, like for example the class "javax.jcr.security.AccessControlManager"? 

 

It makes the life of an AEM developer who uses Eclipse more difficult. 

The problem with the file uber-jar-6.5.5-apis.jar is that in Eclipse you can only attach one jar file as a source of the Javadocs for it and also you can attach only one jar file as a source of the source code for it. 

For example, I can't specify for the file uber-jar-6.5.5-apis.jar in Eclipse multiple jar files with the source code of the Apache Jackrabbit library and multiple other open source libraries which are included in the uber-jar, if I already use the file "uber-jar-6.5.5-sources.jar" (or any other single jar file) as the source of the source code for it. 

I am used to being able to display all possible Javadocs and source codes of all libraries using the keys F2 and F3 in Eclipse. It disturbs my workflow and costs me additional time when I have to search for the Javadoc or source code of a given method/class in other places (e.g. on the Internet for each single open source library which is included in the Adobe's uber-jar). 

 

Does anyone know a solution to the above-mentioned problems? Or even better, will you Adobe fix these issues and make the life of the developers using your product easier? 

 

Thank you in advance for your answers. 

23 Replies

Avatar

Employee Advisor

Bugs typically go via Support tickets. If this was working once but not anymore (thus rather a regression) it might be possible that it gets a higher priority, but I am not an expert in the details of our support processes.

 

Avatar

Level 3

Hi @Jörg_Hoh, thank you for the answer, I will create a new support ticket for the bug regarding the Javadoc jar. 

 

Regarding the other problem, i.e. the source code of open source projects for the uber-jar (vs. "aem-sdk-api")

I have now checked that only an empty sources jar "aem-sdk-api-2021.4.5181.20210416T172032Z-210325-sources.jar" (without any source code included) can be downloaded for the "aem-sdk-api" artifact (https://mvnrepository.com/artifact/com.adobe.aem/aem-sdk-api/2021.4.5181.20210416T172032Z-210325) using Maven. - This is the same situation as for the "uber-jar", for which either no or only an empty sources jar can be downloaded. - I tested it by creating a new, dummy Maven project with a dependency to the above version of the artifact "aem-sdk-api" and by downloading sources for this Maven Dependency. 

So, it seems that most probably I will have to post an idea in the ideas section for including the source code of the open source projects in the sources jar for the uber-jar. 

When I opened various classes from the "aem-sdk-api" jar, then only a decompiled source code of these classes has been shown (I have currently the CFR configured as my Decompiler in Eclipse), without any comments in that source code. A correct Javadoc jar has been downloaded for the "aem-sdk-api" artifact and I can see the Javadoc of a class from this artifact - but only until I open its decompiled source code. As soon as I decompile its source code on the fly by opening it, I can't see the Javadoc of the given class anymore. - The decompiled source code overrides the attached Javadoc. - This is the same problem with the Decompiler as described earlier by me in case of the uber-jar (see also a copy of that description below). 

Could you please share your knowledge how you managed to configure Eclipse so that it integrates the attached Javadoc into the decompiled source code in your case? 

You mentioned earlier that you have Procyon configured as the Decompiler. Are you using the "Enhanced Class Decompiler" plugin for Eclipse (https://marketplace.eclipse.org/content/enhanced-class-decompiler)? If not, which other decompiler plugin are you using?

 

I copy here also a part of my earlier description of my experience with the decompiler, just in case you maybe missed it: 


I ask, because I wonder if you use some other decompiler plugin which works better than the one which I installed. When I select Procyon as the decompiler (under Preferences > Java > Decompiler) and afterwards press F3 on the class "org.apache.jackrabbit.api.security.user.UserManager", then an error is being shown "Editor could not be initialized." Only when I select another decompiler (under Preferences > Java > Decompiler), e.g. "CFR", then I can see the decompiled source code of a class from the uber-jar (or from the "aem-sdk-api"), but without any Javadoc. And after decompiling a given class on the fly by opening its source code, I can't see its Javadoc anymore when pressing F2 on that class, until I restart Eclipse. I.e. in my case the decompiled source code overrides the attached Javadoc which is a big downside for me. I wonder if the decompiler plugin which you use or its specific configuration integrate the attached real Javadoc into the decompiled source code, so that afterwards you see the source code together with the Javadoc. - This could be one of the possible explanations why it works in your case and I would like to know how you configured it to work. Could you please share your knowledge on this subject? 

I have configured the above-mentioned decompiler according to the recommendations from its Github page (https://ecd-plugin.github.io/ecd/) under the heading "How to check the file associations", i.e. I configured the following file associations in my Eclipse: 

  • Click on “Window > Preferences > General > Editors > File Associations”
  • “*.class” : “Class Decompiler Viewer” is selected by default.
  • “*.class without source” : “Class Decompiler Viewer” is selected by default.

Avatar

Employee Advisor

I have setup Eclipse (version 2020-12) quite some time ago, I don't know all the settings I changed. 

 

But let me illustrate it with an example I have right in front of me.

 

NamespaceRegistry namespaceRegistry = session.getWorkspace().getNamespaceRegistry();

 

* I select "NamespaceRegistry" and then select "open implementation".

* In the "Type Hierachy" dialog I select "NamespaceRegistry - javax.jcr".

* Eclipse opens the file "NamespaceRegistry.class", which is part of the "jcr-2.0.jar" Maven dependency (according to the package explorer).

* In this file I see java comments as well as the javadoc.

 

For the settings:

* Right now I set FernFlower as standard (the way you described), but most likely I need to change it to something which can deal with newer versions of bytecode.

 

And that works for the majority (all?) of the opensource libraries I use. To be honest, I never thought that this is a problem at all.