I am working on a class within a package within a source folder within a project with Eclipse Version: 2019-06 (4.12.0).
First I did not organize my files well, so I had to move them using Refactor --> Move. Now I created a class within a source folder. On that particular source folder I right clicked and choose Build Path --> Add External Archives, I then selected a UI library and all worked well.
Now I reorganized my classes and moved them to a different project, where I created source folders and packages for the classes. All the classes work well, expect for the one that uses the UI interface. But here is the part that puzzles me: I can not add an external archive anymore. When I right click on the project, I find Build Path --> Configure Build Path as the only option. Now I can select Libraries and choose Add extneral JARs, but this does not make the class work as it did before. In stead, I get errors on all the lines referencing the UI, saying: the type *** is not accessible or *** cannot be resolved to a type and even line where I do not use the interface but simply introduce a string give an error: The type java.lang.String is not accessible.
I am new to Java and completely puzzled. Any help would be much appreciated.
I found the bug. Apparently there was a package-info.java file created in another package which was in the same source project. This, for some reason, blocked the UI-interface. After deleting this file and removing the JRE System Library from Build Path --> Configure Build Path, then adding the exact same JRE System Library fixed the problem.
Related
Trying to create a new submodule(the second one in the picture)under the parent module(the first one in the picture), but when I right clicked the main file of it, it did not allow me to create class files. Created a submodule (the third one)before this, but did not encounter the same problem. Making it a source root resolved the problem, but I do not know what that really does to my project structure, so I am not willing to use that. You can also see that the second module does not come with a target file, and its resources folder looks different.
Target directory appears after you build the project. When a Java project is imported from pom.xml, default source and resource directories should be configured automatically for you. If you create a module manually without importing it from Maven, you have to set the source roots yourself. See the related answer for details.
I have a class BaseLoginDialog under a dependency which needs to be modified as it is not extendable out of the box. For this reason, I have created another file BaseLoginDialog under my project's module with the same package path as the original BaseLoginDialog. After adding some new methods in my own local BaseLoginDialog, I cannot use them anywhere in my project without IDEA complaining about the method not being declared. However, the project still compiles and the methods work fine on runtime. If I click the import to browse to the file, IntelliJ still links to the old file but it seems to correctly compile with the new one.
How can I go about fixing this issue? Always having error lines and red markers everywhere makes it confusing when coding.
Some background:
The project uses Gradle for the dependencies and compilation. Compiling and running works both with Gradle and with the IntelliJ run operation, it is only the errors being incorrectly displayed that is an issue.
The Grade file adds the required libraries as dependencies. Even though Gradle has both the source and class files, opening a file imported through Gradle still links to the class files. To get around this I also added the required files as sources under Libraries.
Any help would be appreciated, thanks!
EDIT:
Switched to use a Maven repo on the project, now I don't need to additionally add libraries anymore but this problem still persists.
If two classes of the same name and package exists in the classpath of an application, it's the one that is contained in the first dependency on the command line that gets used.
In IntelliJ, you can reorder dependencies, so you can put your local dependency before the other library. I'm not sure if that works with gradle projects, however.
But I don't think that's a good practice? Why can't you put the extra methods in a subclass, e.g. EnhancedLoginDialog, and use that one?
Or, if the original library is open source, fork it, make the changes and install it as a custom version, e.g. dialogs-1.0-CUSTOM-1.jar, and use this version in your project. And while you're at it, create a pull request for the library's maintainer to include your fixes in the next version :-)
I have resolved the issue.
The file I was copying into my local files was BaseLoginDialog. The file showing errors was my NewLoginDialog which extends LoginDialog which extends BaseLoginDialog. It seems that when IntelliJ goes to my NewLoginDialog, it sees that I have extended LoginDialog. Therefore it jumps into the library files and finds that LoginDialog extends BaseLoginDialog, now when it goes to find BaseLoginDialog, it uses the library files and ignores my local copy of BaseLoginDialog.
Essentially, once IntelliJ branches into a library, it does not move back out when looking for additional files if it can already find it inside the library.
To solve this issue, I simply also copied LoginDialog locally, even though it is identical (simply branched it and did not change anything). Now IntelliJ finds LoginDialog in my local files and as a result also finds BaseLoginDialog locally.
Hope this helps anyone having the same problem in the future.
I am Java developer, recently working on Xpages project. we are using Notes 9.0.1. I created Java agent to send email and I want to use some third party jar, something like org.apache.commons.lang3 , end up this issue. how to add third party jar, like commons-lang3-3.4.jar, in my Xpages project?
I tried different ways
add jar under /jvm/lib/ext folder, restart DDE.the I can see it in
my project JRE system libray, but could not import in my Java code.
Maybe this is the way for server deployment.
add jar under /Code/Jars and then DDE generated with new name added in /Webcontent/WEB-INF/lib, but...
Add jar directly under /Webcontent/WEB-INF/lib, but not appeared /Code/Jars in Application view
add jar under the Java agent Archive folder, but...
None of them allows me import the package in my Java code.
Anything I did wrong, or is there any good way to add third party jar in XPages project.
Thanks
If you add a JAR to your project by importing it into /Code/JARs, it should be added so as to be accessible by your build path(2,3). The same is true of your /WebContent/WEB-INF/lib, but that may not be automatically defined in your version of DDE; for example, Domino Designer 9 has the design elements of /Code/Java and /Code/JARs, which didn't previously exist (these are separate folders/paths from /WebContent/WEB-INF/src or /WebContent/WEB-INF/lib, either can be in the build path). In either case, if your approach is to have the JAR in your NSF, make sure your build path has the path with your JARs. Separately you could add each JAR individually.
You can get to the Build Path via Project > Properties, then for the part of your build path concerning JARs, go to "libraries":
individual JARs in Project Build Path
JAR class path in Build Path (ex- /WebContent/WEB-INF/lib)
As for the path of using the /jvm/lib/ext folder approach, I've covered that in a blog post and it's important to remember to have the JARs in the appropriate relative path both on the server and in your Designer/local path (otherwise your local, DDE, may not pick up the change).(1)
For both, if you keep build automatically turned off, you'll want to make sure you perform another build to see the changes.
As for a Java Agent archive, this should just work and again I'm wondering whether your build automatically setting is enabled/disabled. The /jvm/ext/lib path ought to work for this as well (shown in my linked blog post).(4) *Note: as Paul Withers points out in the comments, importing a JAR to a Java Agent can introduce memory leak issues, making the /jvm/ext/lib/ path preferable.
I'm posting this query after doing lots of googling and trying out different options for last few days. Is there an easy way to attach source in Eclipse? is the closest answer I found to my question.
From above post, I tried all solutions but each time Eclipse is opening .class file instead of .java file.
Eclipse Details:
Kepler Service Release 2
Build id:20140224-0627
Please let me know if this is a bug with Eclipse or if I am missing something.
If you are using Maven, try this:
Double click on your project in eclipse -> Maven -> Enable Workspace Resolution
This is most likely because Eclipse actually use the class file for declaring the item you have requested the declaration for, and not the source file you think it should be using.
The typical reason for this is if you have a jar file containing previously compiled classes on your build path before (or instead) of the project containing the source you want. This is very rarely desirable as it can take quite a while to discover that your edits do not take effect.
Examine your build path carefully and ensure it is as you want it to be.
Maven is likely supplying a Classpath Container to your project, and generating entries for the Java Build Path based on the pom.xml contents (the JRE System Library is another example of this). Its entries will not have source attachment unless the container decides it will, which is why the Installed JREs preference page offers to let you set Source Attachments. If the pom.xml has something like that, see if you can use it. If not, see if you can configure the Maven container from its context menu. Otherwise, you may simply be stuck.
I had this same problem: when I pressed F3 or tried to open Declaration (after right click) for any element, it took me to the bytecode .class file.
My solution:
I went to the project in Project Explorer:
right click on project name->Properties
Then in Porject Properties window,
Java Build Path->"Order and Export" tab
There I selected the folder with the .java files (source code), which was below the folder having the .class files -in my case "JRE System Library [java-11-openjdk-amd64]", and pressed 'Top' button on the right frame. Then the folder with source files moved to the top.
Finally, pressed "Apply and Close" button.
That solved my problem forever and ever.
The folder
I installed a plug-in which allows me to download the sources for a maven project.
I'm not by my develop machine right now, but I think it was this:
http://marketplace.eclipse.org/content/m2e-dynamic-sources-lookup#.U8gjGWIaySM
With this, you can select a project an have maven download the sources and make then available when you navigate the code in Eclipse. All without "leaving" Eclipse.
Check into your project modules the Java Build Path, look inside the Source tab and verify if you have "Allow output folders for source folders" checkbox flagged; in this case you just need to uncheck it and you will be able to see again the right source from java files.
This is related to the Call Hierarchy in Eclipse IDE.
If you are in a situation, where you're seeing duplicate methods inside the call hierarchy showing Members calling 'myMethod(...)', double-clicking on one of the listed methods may open the .class file instead of the .java file.
When this happens, the solution is to set the search scope in the call hierarchy to Project instead of Workspace.
After setting the search scope, you won't be seeing duplicate methods listed in the call hierarchy, and double-clicking on the listed methods will only open the .java files.
(Using Eclipse DevStyle Dark Theme)
I'm trying to upload a file via FTP client using Java, but when trying the:
import org.apache.commons.net.PrintCommandListener;
the PrintCommandListener is show in red. I verified my library and it does include commons.net. What should I do?
PrintCommandListener is in fact in Apache Commons Net. For example, if you download the current version, the jar you need to include in your build path is commons-net-3.3.jar. If this single jar is seen by your compiler, then the class should be recognized. Make sure there are no other classes called PrintCommandListener (for example custom ones that you might have written) in your build path.
If using an IDE (such as eclipse) make sure the jar is on your build path. For example, with Eclipse right click project, go to Java Build Path and click Add JARs. Navigate to the location of your jar file and add it.