Doxywizard Doxygen not scanning the packages for java files
Need help on Doxygen/Doxywizard
These are my Doxywizard settings:
Working directory from where doxygen will run:
C:/Program Files/doxygen
In 'Wizard' tab, the below values are set.
Source code directory:
C:/workspace/git/employeeapp/src/main/java
Destination directory:
C:/Doxy-docs/1
In 'Expert' tab, under Topics-'Build' , selected the 'EXTRACT_ALL'
I installed Doxywizard, open the wizard, set the above values, went to 'Run' tab
and clicked 'Run doxygen', I expected that all the folders/packages inside the 'src/main/java'
will be scanned and a project default documentation would be created.
Problem: However I see that 'C:/Doxy-docs/1/html/index.html' is blank and no other pages were created.
If I just navigate to a folder where there is a '.java' file [say src/main/java/com/app/], documentation is created for
the '.java' files inside that folder. But as in the above scenario where 'src/main/java' is mentioned,
the tool is not scanning for packages/folders inside for the '*.java' files.
Question: Am I missing some configuration? or is this the expected functionality of doxygen that it cannot scan inside
folder-folder etc?
Note: This link shows the features of doxygen and from that I think it support the feature that I am expecting.
http://www.doxygen.nl/features.html
Note: I added java tag only because I am using the wizard to scan java files
I continued my effort in finding the option to set it,
and came across this link,
http://www.ibm.com/developerworks/aix/library/au-learningdoxygen/
which mention about 'RECURSIVE'
: Set this tag to Yes if the source hierarchy is nested and you need to generate documentation for C/C++
files at all hierarchy levels. For example, consider the root-level source hierarchy /home/user1/project/kernel,
which has multiple sub-directories such as /home/user1/project/kernel/vmm and /home/user1/project/kernel/asm.
If this tag is set to Yes, doxygen recursively traverses the hierarchy, extracting information.
Got my boy - its 'RECURSIVE'
In Doxywizard, found it under 'Expert' tab and then Topics - 'Input'
checked the checkbox against 'RECURSIVE', and selected '*.java' in FILE_PATTERNS.
Executed again, and the whole documentation is on the table!!! [destination dir what i mentioned]
or,
In the 'Expert' tab itself, when we specify the 'Source code directory',
there is a checkbox for 'Scan recursively'. Just check it.
Related
I have some tool creating an options file for Javadoc containing lots of individual Java source files to process. That tool simply adds all Java files automatically and allows me to add additional options files to the process created manually. The goal is to use such an additional options file to make Javadoc ignore some of the explicitly defined source files.
The first automatically generated options file looks like the following:
-classpath '[...]'
-d '[...]'
-doctitle '[...]'
'C:\\Users\\[...]\\package-info.java'
'C:\\Users\\[...]\\[...].java'
[...]
It contains a lot more paths for each individual Java-file in my project of course. The tools then invokes Javadoc the following way, where all but the first options file is the one I have control over:
javadoc #optsFile1 #optsFile2 #optsFile3
So, is it possible at all to somehow override the explicit paths of the first file using some options in the later files only?
I already tried various combinations of -exclude and -subpackages, but none of them worked. Javadoc always seems to process the explicitly defined files of the first and as well outputs their HTML. I don't care about unnecessary processing those files as well, I only don't want all of their HTML in the output folder. Would be great to have some option to post-filter things based on package names, because I would like to avoid to deal with paths.
Thanks!
I wanted to add a java class to a project, but I did a mistake and added it as a text file. Then, I removed it and tried to add it again as a java class, but unfortunately it doesn't work anymore. And I get the following error:
Unable to parse template "Class" Error message: ABC.java mapped to not java file type text
As I searched, I faced some solutions like
this one but I can't find File Type under Editor or anything similar that I can change as suggested in the solution.
Any help would be appreciated.
PS: I am using IntelliJ 2018.3.4.
Thanks in advance,
Go on File->Settings and a dialog will open. In that dialog navigate on the left part to Editor/File Types and then you need to choose from the section Recognized File Types Java Class and remove from bottom section the problematic extension (note you have a small minus button on the right)
https://www.jetbrains.com/help/idea/creating-and-registering-file-types.html
This is a variant of Markov's answer that worked in my scenario.
Try going to File->Settings->Editor->File Types and to the Recognized File Types tab. Click the "Auto-detect file type by content" choice, and delete the name of the file you are trying to create from the "File Name Patterns" section by using the minus button.
Select required file type in top list (Recognized File Types) -- do it for "Text files"
In bottom list (Registered Patterns) select undesired pattern -- "SomeFileName.java"
Click on "-" (Minus) button to remove pattern from the list
Repeat 1-2-3 for other undesired patterns
If desired, you can also do this manually by editing config file while IDE is closed. Because it's IDE-wide setting, it is not stored in .idea folder (which has project settinsg only) -- the file to look for is called filetypes.xml and shoudl be located in ~/Library/Preferences/IntelliJIdeaXX/options ( see http://devnet.jetbrains.net/docs/DOC-181 for other OS etc )
Certainly inelegant, but you can simply copy the contents of the file to the clipboard (ctrl-c or similar), delete the file (maybe make a temporary backup somewhere outside the project), then in IntelliJ go to the desired package, right click, select new, select Java Class, name it correctly, and then you can paste in the contents of your file (ctrl-v or similar).
I am new to java,i have setup eclipse java project.I have a set of classes in jars in a folder.I have also got the java files associated to those classes downloaded (i cant compile those java files,its just to read and debug at runtime).My issue is class files are packaged in a different way than the those what appears in java file.
eg:- ABC.java is structured as platform\src\main\java\com\subplatform\sql\ABC.java
But package declared in java file if i open is
com.subplatform.sql;
I think this is the reason the debug point is not getting honored.In the previous version's of this product
java files used to be structured as
src\com\subplatform\sql\ABC.java
Thus it used to stop at the debug point.
Thanks
Rename all the package information that contains package com.[restOfPackageInfo] to be package java.com.[restOfPackageInfo] and you should be all set. (Also, if there are any import statements, you'll need to add java in front of com there too.)
There's your problem:
Originally the file structure was "src\com\subplatform\sql\ABC.java"
But by creating a folder called java and placing the com folder inside, you're changing the path to be: "src\main\java\com\subplatform\sql\ABC.java"
So, essentially in the ABC file you see package com.subplatform.sql;. This is information that the compiler uses to compile the class. So you're compiler looks for a ABC.java in src with path com.subplatform.sql but there is no such folder.
Also, read up on packaging.
It sounds like your source attachment path is wrong and should point to platform\src\main\java\ instead of the project itself.
A debug point not being honored can mean two different things.
1) The debugger isn't stopping on line breakpoints. If the compiled class files don't have line and debug information, the JVM doesn't know when it's executing those lines and will not stop there. You should still be able to stop at method entries and when exceptions are thrown. Either way, your are always required to launch your application using Debug instead of Run.
2) The debugger is stopping, but the source is not found. For a JAR file, you should have the properties of the JAR's entry on the Java Build Path point to a location where the source files exactly match the layout of the jar so that com/novice/to/sql/MyClass.class has a com/novice/to/sql/MyClass.java relative to where ever the source attachment points. If the top level contents of the JAR file contains entries like "com", "org", and "net", that's what should be in the top level of the source directory or archive you're pointing to.
We're creating a new project in IntelliJ and must have something wrong because when we right click on a directory, select New and then get the context menu, Java based options are not shown. Currently get things like File, some HTML options, XML options.
We have assumed so far it's something we haven't configured correctly in the Project/Module configuration. The new module we are talking about is part of a multi module project. We created it using a Maven web archetype.
Any help configuring the project nature?
Edit: The answer is basic: 'That moment when you realise somethings not working because you haven't been clicking 'Apply'... :) We had a good laugh at ourselves when we discovered this'
The directory or one of the parent directories must be marked as Source Root (In this case, it appears in blue).
If this is not the case, right click your root source directory -> Mark As -> Source Root.
This can also happen if your package name is invalid.
For example, if your "package" is com.my-company (which is not a valid Java package name due to the dash), IntelliJ will prevent you from creating a Java Class in that package.
you need to mark your directory as source root (right click on the parent directory)
and then compile the plugin (it is important )
as result you will be able to add classes and more
If you open your module settings (F4) you can nominate which paths contain 'source'. Intellij will then mark these directories in blue and allow you to add classes etc.
In a similar fashion you can highlight test directories for unit tests.
Project Structure->Modules->{Your Module}->Sources->{Click the folder named java in src/main}->click the blue button which img is a blue folder,then you should see the right box contains new item(Source Folders).All be done;
I will share another interesting point. If you try to create a package with the reserved keyword then it will be treated as a normal directory and not a package. I was having this issue where I was creating a package named import and it was converting that to a directory.
Another possible solution is that the project name is not acceptable. For example, creating a project with spaces in the name does not block the project creation but the proper sources are not marked and when those are marked manually, I still was unable to create classes. Recreating the project with hyphens (-) instead of spaces corrected the problem for me.
Make sure you are not creating a package name which is same as predefined keywords in java like enum, int, long etc.
In my case I was trying to create a class under "enum" package. As soon as I changed package name to "enums" I was able to create class in it.
Had this issue too. Invalidating Caches/Restart did the trick for me. Please upvote so the the IntelliJ folks take this more seriously. This gives the IDE a terrible UI/UX experience.
https://youtrack.jetbrains.com/issue/IDEA-203100
There is another case where 'Java Class' don't show, maybe some reserved words exist in the package name, for example:
com.liuyong.package.case
com.liuyong.import.package
It's the same reason as #kuporific 's answer: the package name is invalid.
If you just created your project, let IntelliJ finish indexing your project.
You need to mark your java directory as Source Root ,
Right Click on Java directory
Select Mark Directory as option and click on the sub menu option Source Root
Most of the people already gave the answer but this one is just for making someone's life easier.
TL;DR
You must add the test folder as source.
Right click on java directory under test
Mark it as Tests
Add src/test/java in Test Source Folders
Thats it, IntelliJ will consider them as test source.
My Eclipse plugin project which holds libraries used by other OSGi plugins gives me the following warning:
The class folder 'lib/' is not associated to any output library entry.
What does it mean? Can I safely ignore it?
The whole feature consisting from 20 plugins works well, but I do not like to have any warnings in my code.
My build.properties file is:
source.. = src/
output.. = bin/
bin.includes = META-INF/,\
bin/,\
lib/,\
.
The search on google gave me this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=297483, but I'm still not sure how to fix this warning.
I found this hint to be helpfull (first google hit, as of 03-SEP-2013)
http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01822.html
I removed META-INF from my bundle build path, cleaned (rebuilt) the project and the warning disappeared.
About the build.properties:
META-INF/ should be included in the bin.includes because actually this folder includes all the information associated to the classpath and runtime information. If not, another warning appears.
Icons must be added as well in the bin.includes.
Actually, we should try to avoid the addition of icons in the runtime information:
Statically declared plug-in icons are not meant to be in the runtime JAR >because Eclipse wants to load plug-ins lazily. In other words, during >loading of the platform, the platform loader reads only the plugin.xml >file and will use the icons that are declared there.
Taken from: https://wiki.eclipse.org/FAQ_Can_I_add_icons_declared_by_my_plugin.xml_in_the_runtime_JAR%3F
Example of one of my plugins:
Figure 1. Adding information in the bin.includes property
The reason is simple. Think about we want to deploy our plugin somewhere else. Then, we need to maintain a track about all the information that needs our plugin to be executed.
About the MANIFEST.MF:
There is another trick to organize the information that appears in the MANIFEST.MF besides the information that appears in the build.properties:
PDE provides an Organize Manifests wizard to help ensure that the >information in your Manifest is up to date. The wizard is available >through the Plug-in Tools menu after right clicking on a plug-in project's MANIFEST.MF or plugin.xml files.
Taken from: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fpde_actions%2Forganize_manifests.htm
Example of one of my plugins:
Figure 2. Organizing MANIFEST.MF
I think your issue is that in your MANIFEST.MF the section Bundle-ClassPath does not include a listing of the libraries. This means OSGi will not know if these classes are meant to be on the internal classpath. You will have to provide that information.
If you export everything in lib, every single one has to be listed in the MANIFEST.MF and the wildcard lib/ is fine for the PDE builder.
If you only want some in lib/ then you need to list those only, and the builder will either need an explicit list, or an exclude clause for the ones that you do not want.
If you are just using the libraries internally, but do not want to export them, then the settings for the exported packages are used.
I am unsure what to do in the case where you are packing up a jar file but actually do not want it on the classpath. I am guessing that a source.exclude with the name of the library might help. This is a really unusual corner case.
Bundle-ClassPath: lib/amf-aml_2.12-4.1.19.jar,
lib/amf-core_2.12-4.1.20.jar,
lib/amf-validation_2.12-4.0.3.jar,
lib/amf-webapi_2.12-4.0.3.jar,
lib/antlr4-runtime-4.5.3.jar,
lib/collection-0.7.jar,
lib/commons-beanutils-1.9.3.jar,
lib/commons-cli-1.4.jar,
lib/commons-codec-1.11.jar,
lib/commons-collections-3.2.2.jar,
lib/commons-compress-1.19.jar,
lib/commons-csv-1.5.jar,
lib/commons-digester-1.8.1.jar,
lib/commons-io-2.6.jar,
lib/commons-lang3-3.4.jar,
lib/commons-logging-1.2.jar,
lib/commons-validator-1.6.jar,
lib/handy-uri-templates-2.1.6.jar,
lib/httpclient-4.5.5.jar,
lib/httpclient-cache-4.5.5.jar,
lib/httpcore-4.4.9.jar,
lib/jackson-annotations-2.9.0.jar,
lib/jackson-core-2.9.8.jar,
lib/jackson-databind-2.9.8.jar,
lib/jcl-over-slf4j-1.7.26.jar,
lib/jena-arq-3.11.0.jar,
lib/jena-base-3.11.0.jar,
lib/jena-core-3.11.0.jar,
lib/jena-iri-3.11.0.jar,
lib/jena-shaded-guava-3.11.0.jar,
lib/joda-time-2.9.4.jar,
lib/json-20180130.jar,
lib/json4s-ast_2.12-3.5.4.jar,
lib/json4s-core_2.12-3.5.4.jar,
lib/json4s-native_2.12-3.5.4.jar,
lib/json4s-scalap_2.12-3.5.4.jar,
lib/jsonld-java-0.12.3.jar,
lib/libthrift-0.12.0.jar,
lib/org.everit.json.schema-1.9.2.jar,
lib/paranamer-2.8.jar,
lib/re2j-1.1.jar,
lib/scala-common_2.12-0.5.64.jar,
lib/scalactic_2.12-3.0.5.jar,
lib/scala-java8-compat_2.12-0.8.0.jar,
lib/scalajs-stubs_2.12-0.6.29.jar,
lib/scala-library-2.12.6.jar,
lib/scala-reflect-2.12.8.jar,
lib/scalatest_2.12-3.0.5.jar,
lib/scala-xml_2.12-1.0.6.jar,
lib/scopt_2.12-3.7.0.jar,
lib/shacl-1.3.0.jar,
lib/slf4j-api-1.7.26.jar,
lib/slf4j-simple-1.7.12.jar,
lib/syaml_2.12-0.7.270.jar,
lib/webapi-parser-0.5.0.jar,
lib/webapi-parser-0.5.0-javadoc.jar,
lib/webapi-parser-0.5.0-sources.jar,
.