I have two Java projects, built with ANT, named Project A and B which I created in Luna Eclipse (the Java EE version). The package structure is as follows:
Project A
|
src
|
SomePackage
|
A.java
Project B
|
src
|
AnotherPackage
| |
| B.java
|
SomeOtherPackageInSrc
|
C.java
where A, B, and C are non-abstract POJOs. I also have the following inheritence structure:
C extends B, B extends A.
I added a public method to A, so that its children could have it. I then built project A, and added the resulting JAR to the project B's Build Path. I noticed that C could not access the new method. I then attached the source JAR to the build path, viewed the the source for A.java, and the newly added method was present. I tried a number of things, and adding project A to the Deployment Assembly of project B allowed C to see the new method from A. Why does simply extending the class and adding the jar in which the extended class lives not provide visibility to public methods in this case?
I suppose, only extending and adding the project to your classpath will make it compile, but it is not automatically in the resulting deployment unit (EAR/WAR). ANd this makes the classes unavailable at runtime.
I found the problem. I had multiple versions of the Project A JAR on my classpath, and the compiler picked up the old JAR instead of the new one. Rookie mistake.
Related
root project (settings.gradle)
|
|---- projectA (Pojo Class A.java)
|
|---- projectB (Libraries B.java)
|. implementation project(':projectA')
|
|---- projectC (Requires A.java and B.java)
compileOnly(project (':projectB'))
Hello Guys, this is the multiproject structure that I have
Project A (lambda layer) - Has few POJO class for ex. Has A.java
Project B (lambda layer) - Has Libraries and Also has B.java
build.gradle (plugin:java and dependencies has implementation project(':projectA'))
--In project B I am able to access the class of project A, A.java. this is as expected.
Project C (AWS Lambda Function) -- Project C requires the class from Project A and also from project B only for the compiletime.
Since project B runtime already has A.java and B.java, and also as Project A and Project B will be lambda layers and not to be included in the lambda runtime.
I have done
build.gradle (plugin ('java') and compileOnly( project (':projectB'))
Now in project C : I am only able to access B.java but not A.java. Why is it omitted as it was in the runtime classpath of project B??
How should i keep the structure of overall projetcs / project C to access A.java ??
I am trying to use JNA, because I want to work with a .dll that was written in c++ and the rest of my code is in Java. However, if I try to import the JNA classes Eclipse claims "The type com.sun.jna.Library is not accessible".
My IDE seems to see that JNA is somehow in my libraries because when I type "import com.sun.j" it proposes .jna and the other packages in the .jar files to me.
I have created a seperate Project to see if it works there, but it just doesnt work.
I have downloaded the latest .jar (jna-5.8.0.jar and jna-platform-5.8.0.jar) files from the jna Github (https://github.com/java-native-access/jna/blob/master/README.md ) and I have added them to the class path via project-> configure Buildpath -> add External JARs
I am using Eclipse with javaSE-13.
package Testtest;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.Platform;
public class Main {
public static void main(String[] args) {
// TODO Auto-generated method stub
}
}
Package strcuture:
Test
|-- src
| |-- TestTest
| | |-- Main.java
| |-- module-info.java
|-- JRE System Library [JavaSE-13]
|-- Referenced Libraries
|-- jna-5.8.0.jar
|-- jna-platform-5.8.0.jar
As #greg-449 mentioned in the comments, you have a modular project, indicated by the presence of the module-info.java file in your src directory (package root).
You have three options here:
run on (or change your project compatibility level to) JRE 8 or earlier which ignores module-info.java
delete the module-info.java module descriptor in order to run your program without modules
edit your module descriptor (module-info.java) to add the directive requires com.sun.jna. If you're using jna-platform then also add requires com.sun.jna.platform.
In addition, if you extend any JNA classes like Structure or PointerType you will need to open any packages in your project containing those subclasses to com.sun.jna because they use reflection to access your subclasses. (There are multiple options here, but open TestTest to com.sun.jna is the closest to JDK8 behavior.). I am aware this is just a test setup, but consider a reverse-DNS-style package name and module descriptor.
If you are using JNA on the module path you may prefer to use the jna-jpms-5.8.0 and jna-platform-jpms-5.8.0 JARs as your dependencies, as they have their own module descriptors.
I'm been going through the Maven Framework. While going through multi-module projects, I read that cyclic dependency is not acceptable among the modules.
So I thought of a scenario, something like...
root ----------
- pom.xml |
|
|--- moduleA
| - pom.xml (moduleB has been added as a dependancy)
|
|--- moduleB
- pom.xml
Assume that moduleA has a property class AppProperty and a Main class which invokes another class B available in moduleB
Main class available in moduleA :-
someValue = AppProperty.get(propKey);
//some logic
B mb = new B();
B.process(...);
Class B of moduleB :-
process(...) {
someOtherValue = AppProperty.get(someKey)
// some other logic
}
Now Main will not throw any compile-time errors as its dependancies have been resolved because moduleB has been added as a dependancy in moduleA'a pom.xml. But for class B that is not the case as its invoking AppProperty class which is available in moduleA only. I cannot add moduleA's dependancy in moduleB's pom as that would lead to cyclic dependancy (if I understand it correctly).
I understand that ideally it is advised to maintain codes in an acyclic manner, but what if because of some reason removing cyclic dependancy is just not feasible? In such a scenario, is there any way to handle cyclic dependancies without actively changing the existing code logic?
You cannot build a project with cyclic dependencies. You need to build B before A before B, which is kind of a contradiction.
But problems like yours are easy to solve:
If the problem is just the class AppProperty or a few others, just move them from A to B.
If you have some common classes for A and B, create a helper module C and use it as dependency in A and B.
If A and B call each other all of the time, they should probably be just one module. So merge them to one module.
I have a problem moving packages in IntelliJ IDEA. I have created Maven project with multiple modules and each of those modules has a package with the same name. Now whole project becomes a mess if I try to rename some of the packages.
My current project structure is something like this:
--parent-module
|
|--module-one
| |--src
| |--main
| |--java
| |--somepackage
| |--someotherpackages
|--module-two
| |--src
| |--main
| |--java
| |--somepackage
| |--somemorepackages
|--module-three
|--src
|--main
|--java
|--somepackage
|--someevenmorepackages
Notice that somepackage is present in all maven modules.
After MANY created classes in all of those modules and packages I have finally realised what have I done. Now I need to put somepackage into another package under java so I can have something like com.example.moduleone.somepackage.
I have tried renaming package but it renames it in all modules and that creates hailstorm of errors in the code. Also, IntelliJ IDEA renames it to com.example.moduleone.somepackage in all of the modules.
Any help would be highly appreciated.
Might be easiest to create the new package first and then move the classes you want to move into it and then delete somepackage once everything have been moved around
So first add moduleone, then move all of the classes you want to move, then do the same for the other modules, then delete somepackage
Right click to Project name > New> Module..> chose java version and set name for new module.
Drag your packpage your want move to new-module/src > OK > Refactor.
Rebuild project. Find erro : java: packpage dose not exist. Fix it by: Go to erro code > Atl+Enter > Add depedency on module..
Very simple use case, I am using Eclipse Oxygen 4.7.3a that includes support from Java 9. I have two projects that are Java 9 projects:
- projectOne
| - src
| - module-info.java
| - com
| - package1
| - first
| Classificator.java
- projectTwo
| - src
| - module-info.java
| - com
| - package2
| - second
| Classifiable.java
I want to use the Classifiable class inside the Classificator, so I try to import the second module into the first project.
module-info.java Project 1:
module projectOne {
requires projectTwo;
}
module-info.java Project 2:
module projectTwo {
}
Eclipse is giving me the error:
projectTwo cannot be resolved to a module
Do I have to gather all my Java projects under one "main project" in order to let Eclipse know that all those modules are usable inside it? Or have I missed something else?
No, you don't need them to be in the same directory. Ideally, your project-one module defines some uses, which are implements by your project-two module (or vice-versa). Get the runtime implementation of your used interfaces. For this, both jars/classes must be on the module path.
For further information on module build, multi module builds,... you can refer to this link. Even if you do not use gradle, its tutorial on java 9 module build is quite interesting and gives some insight.
While wiring as a service is certainly a viable approach (as described in the other answer), let me add that requires can be made to work, too, of course.
The thing that was probably missing from the first approach is: Eclipse still needs to know where to look for modules. In real world projects this will typically be mediated by your build tool of choice plus a plug-in like m2e or buildship.
If no such plug-in is used, a normal project dependency should be added to the Build Path of project projectOne in order to make project projectTwo visible. Once the project is on the Build Path the module defined by the project can be resolved in references in module-info.java.