Unable to generate javadoc in Eclipse for linked source files - eclipse

I am unable to generate javadoc for linked .java files using Eclipse Mars.
This shows how my project is set up:
I am able to run the program.
The source file is in a folder named foo, to match the package declaration:
I select Project > Generate Javadoc... and check the package:
I agree to all of the default options.
I get this output in the console:
Loading source files for package foo...
Constructing Javadoc information...
javadoc: warning - No source files for package foo
javadoc: warning - No source files for package foo
javadoc: error - No public or protected classes found to document.
1 error
2 warnings
Adding javadoc comments to the source code makes no difference.
I have no trouble generating javadoc when I do not have linked source files.
How do I set up links to source files so I can generate javadoc?

When you do Project > Generate Javadoc... it launches the external program javadoc part of the JDK typically. The javadoc program does not understand/know about Eclipse linked resources, so it sees the empty folder.
How do I set up links to source files so I can generate javadoc?
Short answer is you cannot with links at the file level.
Use Links to src folder
Rather than doing a link to files within a package, make the link to the containing source folder. In your screenshot you don't have a src folder, but you could create one that is linked.
For example, I have a project called demoforso, in it I create a folder called src that is linked to D:\tmp\src and add src to classpath. When the javadoc is run on this project, it passes D:\tmp\src as the sourcepath.
Use Javadoc views in Eclipse
(i.e. Don't generate Javadoc at all, granted possibly not useful in your case, but included for completeness.)
The hovers and Javadoc view in Eclipse means that you never need to generated Javadoc for your own use.

Related

When debugging my Eclipse plugin, the repository version of the Java file is chosen over my local version

I'm in the early stages of creating a new Eclipse plug-in in Eclipse 2019-06. I created the plug-in using the "Hello World" wizard option and created a debug configuration that successfully launches a secondary workbench for testing. I can click on my new menu option and step into my new code.
I want to use a modified version of org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne, so I added the package to my project and edited NewTestCaseWizardPageOne. However, when I try to debug, the debugger asks for a source location. It seems to want to load the file from the local repository (.p2/pool/plugins/org.eclipse.jdt.junit_3.11.400.v20190510-0840.jar), rather than my edited version. Why is that?
There must be some kind of classpath problem, but don't versions of files in the project have precedence over those in the dependent plugins? I've looked at a number of similar questions (1, 2) and other sources, but I haven't yet found the answer. Please help.
Following Alexander Federov's suggestion, I converted my plugin into a fragment. This was fairly easy to do following the advice from this StackOverflow page. The main changes were:
Renamed plugin.xml to fragment.xml and changed the top level xml
element from plugin to fragment.
Added a Fragment-Host entry to MANIFEST.MF
The key advantage that this provided is discussed in an Eclipse Wiki
page:
... a fragment appears much the
same as a normal plug-in. A fragment can specify libraries,
extensions, and other files. When it is loaded by the platform loader,
a fragment is logically, but not physically, merged into the host
plug-in. The end result is exactly the same as if the fragment's
manifest were copied into the plug-in manifest, and all the files in
the fragment directory appear as if they were located in the plug-in's
install directory. Thus, a runtime library supplied by a fragment
appears on the classpath of its host plug-in. In fact, a Java class in
a fragment can be in the same package as a class in the host and will
even have access to package-visible methods on the host's classes.
The last part having to do with access to package-visible methods was what I needed. Thanks, Alexander!

The JAR file C:\...Tomcat-8.0\lib\servlet-api.jar has no source attachment

I did Ctrl+Click on HttpServlet to see source code of HttpServlet, but it gave me this error:
How to fix this? It says, I should download "servlet-api.jar", but when I try to download, I can not understand which one should I download? There are lot of servlet-api.jar files.
The source code is not necessarily specific to the Servlet API, but to the Servlet Implementation itself. In your particular case, Tomcat is the Servlet Implementation. So, you need to head to its homepage to find download links to the source code. Usually it's at the same place as where you downloaded the binaries.
Tomcat 8.0 download page is here, if you scroll to bottom, then you should see those links:
Binary Distributions
Core:
zip <-- this is Tomcat server itself.
...
Source Code Distributions
...
zip <-- this contains the source code.
Download the source code zip, put it somewhere in your file system (I usually put it in Tomcat installation folder; do note that you do not need to extract it!). Finally, press Attach Source button in Eclipse and point to that source code zip file.
If this maven based project , you just select the dependency in the Package Explorer, right click and then select "Attach resource"

Errors in exporting eclipse deployable plug-ins and fragments

I have an eclipse plug-in working fine within eclipse environment.
I wanted to export it into a jar file, so I chose Export > Deployable plug-ins and fragments.
I could get a jar file, but an error was reported.
Opening the log file, it reports that I have 1242 problems (191 errors, 1051 warnings). This is some copy from the error log.
2. ERROR in /Users/LSclipse/src/lsclipse/LSDiffRunner.java (at line 61)
import edu.washington.cs.induction.OnePipeLineScript;
^^^
The import edu cannot be resolved
----------
3. ERROR in /Users/LSclipse/src/lsclipse/LSDiffRunner.java (at line 261)
OnePipeLineScript.getMatchingForRefFinder(projName, proj1, proj1Loc
^^^^^^^^^^^^^^^^^
OnePipeLineScript cannot be resolved
Why I got errors? I had 2049 warnings, but no error when I compile the plugin in eclipse IDE.
ADDED
The main project references two other projects, and references many external libraries. I attach the package view and Java build path.
There were multiple issues involved for this problem. However, the core issue was that the project apimatching and originanalysis were not eclipse plugins but just java projects. As a result, those two projects were not included in the final jar file to break the build.
Symbolic linking the two projects into the main project
I solved this issue by symbolic link the src directory into the main eclipse plugin project.
ln -s /workspace/seal/edu.ucsc.originanalysis/src /LSclipse/originanalysis
ln -s /workspace/seal/edu.ucsc.apimatching/src /LSclipse/apimatching
From the Java Build Path/Source tab, I added those two included projects as source. Eclipse Java Missing required source folder: 'src'
Now I have eclipse plugin jar file without error.
Then click F-5 to refresh the project explorer and check they are java src directory.
Select the included projects in Build tab.
Updating bin.include and source.. in build.properties tab is important. One should understand that in bin.include the ordering is also critical. lib/cdtparser.jar and lib/cdtcore.jar should be placed prior to the user of them - origin analysis/.
Copying jar files for included project into main project
I also had to copy some jar files in those projects file into the main project, and select them in Binary Build tab.
And add tim in Runtime/Classpath tab.
Select the JavaSE-1.6 in Execution Environments.
I have lots of "Must Override a Superclass Method" errors. With the hint from this post - 'Must Override a Superclass Method' Errors after importing a project into Eclipse , I removed the J2SE-1.5 to resolve this issue.
You can not add third party libraries into class path of Java when developing a plug-in. It is the way to build standard Java application, but plug-in is a kind of OSGi bundle that has itself rule for class loading.
The correct way is adding third party libraries into the class path of your plug-in.
Add below declaration into MANIFEST.MF of your plug-in,
Bundle-ClassPath: lib/log4j-1.2.7.jar,
xml-apis.jar,
...
Check those links [1], [2] for understanding it.
This is what have a question on and see as potential solutions to potential problems.
Is this class comfing from a referenced jar or is it in the actual plugin edu.washington.cs.induction.OnePipeLineScript;
You seem to have a lot of soure folders and wondering if your build.properties file is showing any warnings and that you also have this defined for each of the source folders in your build.properties source.. = src/
Your external jar libraries appear to be in a folder that is of type source which is not correct. It should be a non-source folder (which you can tell a source folder by the package icon decorator) and you should make sure in your manifest editor that for runtime you have the lib checked so that it includes the jars in the build. To unmark it as a source folder select the drop down menu in your navigator view go to filters and uncheck .resources which will then show the .classpath file in that file you will see the folder to be kind="src" (i believe) remove that.
Somehow it also looks like you have linked source folders which is a practice I would not suggest and am not sure if that will cause problems when exporting the plugin. If you can avoid linked source folders that would be better.
Also it seems like you are confusing java build path configuration for plain java applications with plugins running in OSGI which is not configured through java build path but your manifest.editor So as a rule of thumb if its a plugin don't even bother trying to configure the java build path because OSGI is different, that could be causing issues as well
Select "Use class files complied in the workspace" in Options works for me.

Eclipse ctrl+Shift+G not working as expected

Ctrl+Shift+G used to find references to the current selection within ALL projects in my Workspace.
Now is seems to only return references within the current Project.
Details:
I have 3 projects in the same database. 1 project is common code. The other 2 projects include the source folder of the common code on the build path. I prefer to link to common source instead of including the common code as a Project on the build path because then when I deploy by exporting WAR each project has its own self-contained version of the common code.
However Ctrl+Shift+G seems to work when I include the common code as a Project. So it looks like I need to do both. I just don't know why the searching results have changed. I did install JBoss Tools and as a result of Jboss needed to install a newer version of Indigo.
Similar issue, but no good answer.
EDIT:
Open two editors with a common class file, one from the linked source folder and one for the actual project folder. When the Ctrl+Shift+G is performed on the linked source, only references with in the project containing the linked folder are found. Ctrl+Shift+G from the actual common project finds references to all projects in the workspace, when those projects have the common project referenced on the build path.
The problem is when I am in a project and I control click a common code method I am taken to the linked source class file. So then when I do a Ctrl+Shift+G on that method, I miss all the other projects that reference this common method, because the editor contains the file from the linked source. This never used behaved this way and used to find all projects that referenced this method regardless of which file (linked or actual) was used.
I find the command..It is
Ctrl+ALT +G // search through out workspace
not
Ctrl +shift +G // searching within class/project
And one tip
Ctrl+shift+L to see all commands in Eclipse
This can occur if you are using Maven and your version numbers do not match. I had a dependent project with <version>1.0.0.RELEASE</version> that was being referenced in another project as <version>1.0.0-SNAPSHOT</version>. Fixing the mismatch so that versions were correct allowed CTRL-SHIFT-G to find the references in the workspace that it could not find before.

Useing Ant to build a Jar file WITH COMMENT

I have a Jar build from my own project(using ANT),
my project have comments in java files,but when i use this Jar in new project,I can't see the comments(by press F2 in eclipse),Some one said that I can't see comment unless i have the source file of the Jar.
The question is,is that true?or there's some other way to have comments with my Jar(without Source files)?
The comments from your source code are not part of the compiled class files, so they will not be visible unless you provide the source java files
You can generate javadocs and include them with your jar library. There is a javadoc ant taks to generate the javadoc. You can then either include it in your jar file, or provide it separately. If you include the javadoc inside the distributable jar, whoever is using your jar will have to either extract the javadoc out to view them, or specify that the jar file also contains the javadoc inside the IDE