0

I have 2 projects, say ProjectA and ProjectB, both containing package com.faizan.org. ProjectA is added in the modulepath of ProjectB.

<classpathentry combineaccessrules="false" kind="src" path="/ProjectA">
    <attributes>
        <attribute name="module" value="true"/>
    </attributes>
</classpathentry>

Now I am writing a new class in ProjectB that needs to import a class from com.faizan.org of ProjectA, but I get an error The package com.faizan.org is accessible from more than one module: ProjectA, ProjectB in eclipse 2019-12 using openJdk 12 and compiler compliance also set to 12.

How can I add external projects containing same package name to another project without classpath conflicts? Also, in some cases unable to access methods of super class.

1 Answers1

1

Simple answer: you cannot.

When you setup your Eclipse projects as Java modules, then the rules of the module system JPMS forbid that any module has access to the same package from two modules (each package must be "uniquely visible").

Next, you should revisit why you need to have the same package in both projects? If it is for whitebox testing, then please consider moving the tests to the same project, but in a separate source folder marked as containing tests. Then Eclipse will do all the necessary wiring behind the scenes, so that the tests are part of the module and not part of the module at the same time.

If it's not for the sake of whitebox testing, and you do want to adopt JPMS, then you are left with 2.5 options:

  1. Move all code that shares a package into the same project / module.
  2. Change the package structure to avoid the split package.
  3. (Use a tricky set of JPMS options including --patch-module and likely more to let JPMS view the separate projects as one module -- while possible I would consider this as "successful migration")
Stephan Herrmann
  • 7,963
  • 2
  • 27
  • 38
  • I am working on some legacy project with the mentioned structure and trying to migrate the stack to Java 12/13. Consequently, I need to make the application JDK 12 build complaint preserving the structure as much as possible. Moreover, its a large application which might require a lot of cost trying to restructure the entire dependencies. Is there a way to achieve the same? – Faizan Mirza Feb 21 '20 at 04:58
  • 1
    You didn't show if you have any module-info.java. If you don't then marking the project dependency as non-modular (move it to the classpath instead of module path) will let you work in "legacy" / non-modular mode, where only the JRE is seen as modular, not your application code. But that would be only a partial migration to Java 9+. – Stephan Herrmann Feb 21 '20 at 23:17
  • Hi, I don't have a module-info.java file in my modules. However, I was expecting the compiler to pick the first matching package from the modulepath in case of matching names. However, as suggested I tried moving my external JARs to classpath but still it didn't help. I have jbossallclient jar that contains javax.management package and jdk has it as well. This leads to error below: **The package javax.management is accessible from more than one module: , java.management** – Faizan Mirza Feb 24 '20 at 05:13
  • 1
    @FaizanMirza, the remaining error mentioning "" is the same as discussed in https://stackoverflow.com/questions/51094274/eclipse-cant-find-xml-related-classes-after-switching-build-path-to-jdk-10/53824670 In short: having javax.management outside the JRE is essentially illegal. Best to avoid this dependency in the first place. If you can't you'll be experimenting with `--limit-modules`, or more comfortably using the Module Dependencies tab of the Java Build Path configuration, to exclude that System module. – Stephan Herrmann Feb 24 '20 at 23:13
  • @FaizanMirza if you see your initial question answered, please consider accepting the answer. If you have follow-up problems, feel free to comment so we can sort out if it is already answered by the linked question (regarding ""), deserves a new question, or similar. – Stephan Herrmann Feb 25 '20 at 13:40