Re: [EXTERNAL] Re: Converting Java 8 to 17+, conflicts with modules
All great advice. I was able to solve the compile issue using the following, but I'll need to refine my deps and module declarations. Each of these were added explicitly because they're used, include several classes/packages from org.eclipse.persistence.*. jakarta.inject jakarta.inject-api 2.0.1 provided jar jakarta.enterprise jakarta.enterprise.cdi-api 4.0.1 provided jar jakarta.json jakarta.json-api 2.1.3 provided jar jakarta.ws.rs jakarta.ws.rs-api 3.1.0 provided jar jakarta.json.bind jakarta.json.bind-api 3.0.0 provided jar jakarta.validation jakarta.validation-api 3.0.2 provided jar jakarta.ejb jakarta.ejb-api 4.0.1 provided jar jakarta.servlet jakarta.servlet-api 6.0.0 provided jar jakarta.persistence jakarta.persistence-api 3.1.0 provided jar jakarta.xml.bind jakarta.xml.bind-api 4.0.1 provided jar org.glassfish.jersey.media jersey-media-multipart 3.1.3 provided org.glassfish.jersey.core jersey-client ${project.dependency.jersey.version} provided org.eclipse.persistence org.eclipse.persistence.core 3.0.4 provided jar org.eclipse.persistence org.eclipse.persistence.jpa 4.0.2 provided jar requires jakarta.cdi; requires jakarta.ejb; requires jakarta.inject; requires jakarta.json; requires jakarta.json.bind; requires jakarta.servlet; requires jakarta.validation; requires jakarta.ws.rs; requires jakarta.xml.bind; requires jersey.client; requires jersey.media.multipart; requires org.eclipse.persistence.jpa; From: Stephen G. Parry Sent: Saturday, November 11, 2023 11:47 AM To: Bradley Willcott ; John Manko ; users@netbeans.apache.org Subject: [EXTERNAL] Re: Converting Java 8 to 17+, conflicts with modules CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >From my experience, minimize your direct Maven dependencies. Try to use >services as much as possible. For example. eclipselink should be a runtime, >not a compile time dependency and should be injected as service: module-info.java: requires jakarta.persistence; uses jakarta.persistence.spi.PersistenceProvider; pom.xml: org.eclipse.persistence eclipselink 4.0.1 runtime Basically, strip the dependencies back to nothing and only add the ones that stop the compilation from failing or the code from running, one mod at a time. Some of your dependencies may fail to load because they are not fully modular yet. Your options then are: a) make your application non-modular, for now. This still works for most things apart from Java FX. Doing non-modular FX is like urinating into a stiff breeze. b) use moditect to patch the non-modular dependencies, until modular ones are available. It's a hack, but it works surprisingly well. On 11/11/2023 15:42, Bradley Willcott wrote: Hi John. Check out this site: https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts<https://urldefense.com/v3/__https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts__;!!HzYX23eHnp2Wbe4!UJMA1Rmsp-1cH7vOEIOeagJSpQlcBx-0D0STmQ9DCsdCC3uI-7hcS--YJXfnhsVXFxbD1fEqbNnV3bw$>. It should give you what you need to know. Regards, Brad. On 11/11/23 06:20, John Manko wrote: This might not be a purely Netbeans issue, but maybe NB has some tooling to assist, or someone can answer a quick question. I'm in the middle of converting Java 8 project to Java 17/21 (A little late in the game, I know! I'm beholden to other forces beyond my control.), and I have a library module with a module-info like such: module com.my.lib { requires com.google.common; requires com.google.gson; requires eclipselink; requires jakarta.jakartaee.api;
Re: Converting Java 8 to 17+, conflicts with modules
From my experience, minimize your direct Maven dependencies. Try to use services as much as possible. For example. eclipselink should be a runtime, not a compile time dependency and should be injected as service: module-info.java: requires jakarta.persistence; uses jakarta.persistence.spi.PersistenceProvider; pom.xml: org.eclipse.persistence eclipselink 4.0.1 runtime Basically, strip the dependencies back to nothing and only add the ones that stop the compilation from failing or the code from running, one mod at a time. Some of your dependencies may fail to load because they are not fully modular yet. Your options then are: a) make your application non-modular, for now. This still works for most things apart from Java FX. Doing non-modular FX is like urinating into a stiff breeze. b) use moditect to patch the non-modular dependencies, until modular ones are available. It's a hack, but it works surprisingly well. On 11/11/2023 15:42, Bradley Willcott wrote: Hi John. Check out this site: https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts. It should give you what you need to know. Regards, Brad. On 11/11/23 06:20, John Manko wrote: This might not be a purely Netbeans issue, but maybe NB has some tooling to assist, or someone can answer a quick question. I'm in the middle of converting Java 8 project to Java 17/21 (A little late in the game, I know! I'm beholden to other forces beyond my control.), and I have a library module with a module-info like such: module com.my.lib { requires com.google.common; requires com.google.gson; requires eclipselink; requires jakarta.jakartaee.api; requires java.logging; requires java.sql; requires jersey.client; requires jersey.media.multipart; requires org.apache.pdfbox; requires org.apache.fontbox; exports com.my.package; } I get the following error message in Netbeans: module com.my.lib reads package jakarta.faces.context from both jakarta.faces.api and jakarta.jakartaee.web.api What am I'm doing wrong here? Is there any tooling in NB to help create the module-info based on declared maven dependencies? Below is are pom.xml deps (test deps removed): jakarta.platform jakarta.jakartaee-api 10.0.0 provided org.eclipse.persistence eclipselink 4.0.2 provided org.glassfish.jersey.core jersey-client 3.1.3 provided org.glassfish.jersey.media jersey-media-multipart 3.1.3 provided com.google.code.gson gson 2.9.1 com.google.guava guava 32.1.3-jre org.apache.pdfbox pdfbox 3.0.0
Re: Converting Java 8 to 17+, conflicts with modules
Hi John. Check out this site: https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts. It should give you what you need to know. Regards, Brad. On 11/11/23 06:20, John Manko wrote: This might not be a purely Netbeans issue, but maybe NB has some tooling to assist, or someone can answer a quick question. I'm in the middle of converting Java 8 project to Java 17/21 (A little late in the game, I know! I'm beholden to other forces beyond my control.), and I have a library module with a module-info like such: module com.my.lib { requires com.google.common; requires com.google.gson; requires eclipselink; requires jakarta.jakartaee.api; requires java.logging; requires java.sql; requires jersey.client; requires jersey.media.multipart; requires org.apache.pdfbox; requires org.apache.fontbox; exports com.my.package; } I get the following error message in Netbeans: module com.my.lib reads package jakarta.faces.context from both jakarta.faces.api and jakarta.jakartaee.web.api What am I'm doing wrong here? Is there any tooling in NB to help create the module-info based on declared maven dependencies? Below is are pom.xml deps (test deps removed): jakarta.platform jakarta.jakartaee-api 10.0.0 provided org.eclipse.persistence eclipselink 4.0.2 provided org.glassfish.jersey.core jersey-client 3.1.3 provided org.glassfish.jersey.media jersey-media-multipart 3.1.3 provided com.google.code.gson gson 2.9.1 com.google.guava guava 32.1.3-jre org.apache.pdfbox pdfbox 3.0.0
Converting Java 8 to 17+, conflicts with modules
This might not be a purely Netbeans issue, but maybe NB has some tooling to assist, or someone can answer a quick question. I'm in the middle of converting Java 8 project to Java 17/21 (A little late in the game, I know! I'm beholden to other forces beyond my control.), and I have a library module with a module-info like such: module com.my.lib { requires com.google.common; requires com.google.gson; requires eclipselink; requires jakarta.jakartaee.api; requires java.logging; requires java.sql; requires jersey.client; requires jersey.media.multipart; requires org.apache.pdfbox; requires org.apache.fontbox; exports com.my.package; } I get the following error message in Netbeans: module com.my.lib reads package jakarta.faces.context from both jakarta.faces.api and jakarta.jakartaee.web.api What am I'm doing wrong here? Is there any tooling in NB to help create the module-info based on declared maven dependencies? Below is are pom.xml deps (test deps removed): jakarta.platform jakarta.jakartaee-api 10.0.0 provided org.eclipse.persistence eclipselink 4.0.2 provided org.glassfish.jersey.core jersey-client 3.1.3 provided org.glassfish.jersey.media jersey-media-multipart 3.1.3 provided com.google.code.gson gson 2.9.1 com.google.guava guava 32.1.3-jre org.apache.pdfbox pdfbox 3.0.0