Error: “Package is declared 'javafx.beans.value' in module 'foo.bar'”










2















I've developed a library which module-info.java looks like that:



module foo.bar 
requires org.apache.commons.lang3;
requires javafx.base;
requires java.validation;
exports foo.bar;



This library is used in another project where the module-info.java contains the following:



module other.project 
requires org.apache.commons.lang3;
requires javafx.base;
requires javafx.graphics;
requires javafx.fxml;
requires foo.bar;



When I try to use import javafx.beans.value.WritableValue; I get the error




Package javafx.beans.value is declared in foo.bar, which does not
export it to module other.project.




UPDATE: I created two example projects which reproduce the problem. Please find them here to download.



I do not understand why that is and yet I could not find a solution.










share|improve this question
























  • Can you post the full exception? Did you manage to get each of the modules running standalone, without having dependencies between them?

    – José Pereda
    Nov 11 '18 at 13:35











  • @JoséPereda I do not get an exception as such, it is just a info provided by IDEA - please see img.picload.org/image/dcoogipr/snippet.png

    – Hannes
    Nov 11 '18 at 14:05











  • And did you try your modules as standalone? Do you build/run them normally?

    – José Pereda
    Nov 11 '18 at 14:13











  • module 'foo.bar' works stand-alone, the other one I cannot test since 'foo.bar' is a strict dependency.

    – Hannes
    Nov 11 '18 at 14:21






  • 1





    Yes, the HelloFX works fine for me. As soon as I remove the dependency of my other lib I can use the JFX libs. But apparently there is a problem if both my project and the external lib requires the same external module.

    – Hannes
    Nov 11 '18 at 14:51















2















I've developed a library which module-info.java looks like that:



module foo.bar 
requires org.apache.commons.lang3;
requires javafx.base;
requires java.validation;
exports foo.bar;



This library is used in another project where the module-info.java contains the following:



module other.project 
requires org.apache.commons.lang3;
requires javafx.base;
requires javafx.graphics;
requires javafx.fxml;
requires foo.bar;



When I try to use import javafx.beans.value.WritableValue; I get the error




Package javafx.beans.value is declared in foo.bar, which does not
export it to module other.project.




UPDATE: I created two example projects which reproduce the problem. Please find them here to download.



I do not understand why that is and yet I could not find a solution.










share|improve this question
























  • Can you post the full exception? Did you manage to get each of the modules running standalone, without having dependencies between them?

    – José Pereda
    Nov 11 '18 at 13:35











  • @JoséPereda I do not get an exception as such, it is just a info provided by IDEA - please see img.picload.org/image/dcoogipr/snippet.png

    – Hannes
    Nov 11 '18 at 14:05











  • And did you try your modules as standalone? Do you build/run them normally?

    – José Pereda
    Nov 11 '18 at 14:13











  • module 'foo.bar' works stand-alone, the other one I cannot test since 'foo.bar' is a strict dependency.

    – Hannes
    Nov 11 '18 at 14:21






  • 1





    Yes, the HelloFX works fine for me. As soon as I remove the dependency of my other lib I can use the JFX libs. But apparently there is a problem if both my project and the external lib requires the same external module.

    – Hannes
    Nov 11 '18 at 14:51













2












2








2








I've developed a library which module-info.java looks like that:



module foo.bar 
requires org.apache.commons.lang3;
requires javafx.base;
requires java.validation;
exports foo.bar;



This library is used in another project where the module-info.java contains the following:



module other.project 
requires org.apache.commons.lang3;
requires javafx.base;
requires javafx.graphics;
requires javafx.fxml;
requires foo.bar;



When I try to use import javafx.beans.value.WritableValue; I get the error




Package javafx.beans.value is declared in foo.bar, which does not
export it to module other.project.




UPDATE: I created two example projects which reproduce the problem. Please find them here to download.



I do not understand why that is and yet I could not find a solution.










share|improve this question
















I've developed a library which module-info.java looks like that:



module foo.bar 
requires org.apache.commons.lang3;
requires javafx.base;
requires java.validation;
exports foo.bar;



This library is used in another project where the module-info.java contains the following:



module other.project 
requires org.apache.commons.lang3;
requires javafx.base;
requires javafx.graphics;
requires javafx.fxml;
requires foo.bar;



When I try to use import javafx.beans.value.WritableValue; I get the error




Package javafx.beans.value is declared in foo.bar, which does not
export it to module other.project.




UPDATE: I created two example projects which reproduce the problem. Please find them here to download.



I do not understand why that is and yet I could not find a solution.







java java-module jigsaw java-11 javafx-11






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 12 '18 at 20:58







Hannes

















asked Nov 11 '18 at 12:28









HannesHannes

1,61151731




1,61151731












  • Can you post the full exception? Did you manage to get each of the modules running standalone, without having dependencies between them?

    – José Pereda
    Nov 11 '18 at 13:35











  • @JoséPereda I do not get an exception as such, it is just a info provided by IDEA - please see img.picload.org/image/dcoogipr/snippet.png

    – Hannes
    Nov 11 '18 at 14:05











  • And did you try your modules as standalone? Do you build/run them normally?

    – José Pereda
    Nov 11 '18 at 14:13











  • module 'foo.bar' works stand-alone, the other one I cannot test since 'foo.bar' is a strict dependency.

    – Hannes
    Nov 11 '18 at 14:21






  • 1





    Yes, the HelloFX works fine for me. As soon as I remove the dependency of my other lib I can use the JFX libs. But apparently there is a problem if both my project and the external lib requires the same external module.

    – Hannes
    Nov 11 '18 at 14:51

















  • Can you post the full exception? Did you manage to get each of the modules running standalone, without having dependencies between them?

    – José Pereda
    Nov 11 '18 at 13:35











  • @JoséPereda I do not get an exception as such, it is just a info provided by IDEA - please see img.picload.org/image/dcoogipr/snippet.png

    – Hannes
    Nov 11 '18 at 14:05











  • And did you try your modules as standalone? Do you build/run them normally?

    – José Pereda
    Nov 11 '18 at 14:13











  • module 'foo.bar' works stand-alone, the other one I cannot test since 'foo.bar' is a strict dependency.

    – Hannes
    Nov 11 '18 at 14:21






  • 1





    Yes, the HelloFX works fine for me. As soon as I remove the dependency of my other lib I can use the JFX libs. But apparently there is a problem if both my project and the external lib requires the same external module.

    – Hannes
    Nov 11 '18 at 14:51
















Can you post the full exception? Did you manage to get each of the modules running standalone, without having dependencies between them?

– José Pereda
Nov 11 '18 at 13:35





Can you post the full exception? Did you manage to get each of the modules running standalone, without having dependencies between them?

– José Pereda
Nov 11 '18 at 13:35













@JoséPereda I do not get an exception as such, it is just a info provided by IDEA - please see img.picload.org/image/dcoogipr/snippet.png

– Hannes
Nov 11 '18 at 14:05





@JoséPereda I do not get an exception as such, it is just a info provided by IDEA - please see img.picload.org/image/dcoogipr/snippet.png

– Hannes
Nov 11 '18 at 14:05













And did you try your modules as standalone? Do you build/run them normally?

– José Pereda
Nov 11 '18 at 14:13





And did you try your modules as standalone? Do you build/run them normally?

– José Pereda
Nov 11 '18 at 14:13













module 'foo.bar' works stand-alone, the other one I cannot test since 'foo.bar' is a strict dependency.

– Hannes
Nov 11 '18 at 14:21





module 'foo.bar' works stand-alone, the other one I cannot test since 'foo.bar' is a strict dependency.

– Hannes
Nov 11 '18 at 14:21




1




1





Yes, the HelloFX works fine for me. As soon as I remove the dependency of my other lib I can use the JFX libs. But apparently there is a problem if both my project and the external lib requires the same external module.

– Hannes
Nov 11 '18 at 14:51





Yes, the HelloFX works fine for me. As soon as I remove the dependency of my other lib I can use the JFX libs. But apparently there is a problem if both my project and the external lib requires the same external module.

– Hannes
Nov 11 '18 at 14:51












1 Answer
1






active

oldest

votes


















2





+100









Based on the project posted here, the error that you get when you open the project is:




Package 'javafx.beans.property' is declared in module 'com.example.external.lib', which does not export it to module 'example.project'




The reason for this error is that you are adding some packages from javafx.base to your external library, but those are not exported to the project that uses this library. The javafx.beans.property package is internally used by the external module, but it can't be exported.



So these are some proposed changes to make it work.



If you are creating a modular jar (using a module-info class) as a dependency for another project, you don't need to use the shadow plugin, and you don't need to bundle the JavaFX dependencies in your jars.



  1. External-library project

So you can have the same module-info.java file:



module com.example.external.lib 
requires javafx.base;
requires org.apache.commons.lang3;

exports com.example.external.library;



with a build.gradle like this:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




Now, when you run gradle build, you will generate libs/external-library.jar, a 2 KB jar, without JavaFX dependencies.



Note that if you still want to do shadow jar with this external project, you can use compileOnly "org.openjfx:javafx-base:11:$platform" to keep the JavaFX dependencies out of this jar.



  1. Project-using-external-lib

You can add that jar to the project.



build.gradle:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




But now your module-info file should include again the javafx.base dependency:



module example.project 
requires javafx.base;
requires com.example.external.lib;

exports com.example.project;



You can run gradle build to generate a jar, and IntelliJ won't complain anymore.



If you want to have a shadow jar at the end, you can also apply:



buildscript 
repositories
mavenCentral()
maven
url "https://plugins.gradle.org/m2/"


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'application'
apply plugin: 'com.google.osdetector'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



run
doFirst
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



mainClassName = "com.example.project.PublicClass"

jar
manifest
attributes 'Main-Class': 'com.example.project.PublicClass'

from
configurations.compile.collect it.isDirectory() ? it : zipTree(it)




so you would be able to run java -jar build/libs/project-using-external-lib.jar. Note that this jar will contain the JavaFX classes.



Doing a shadow jar is not to the recommended way to distribute your project, but since you have automatic modules (commons-lang3) you can't use jlink, unless you convert that into an explicit module (see this answer).






share|improve this answer

























  • Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

    – Hannes
    Nov 18 '18 at 22:09











  • I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

    – José Pereda
    Nov 18 '18 at 22:40











  • As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

    – José Pereda
    Nov 18 '18 at 22:48












  • Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

    – Hannes
    Nov 20 '18 at 11:52











  • There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

    – José Pereda
    Nov 20 '18 at 12:06










Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53248763%2ferror-package-is-declared-javafx-beans-value-in-module-foo-bar%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2





+100









Based on the project posted here, the error that you get when you open the project is:




Package 'javafx.beans.property' is declared in module 'com.example.external.lib', which does not export it to module 'example.project'




The reason for this error is that you are adding some packages from javafx.base to your external library, but those are not exported to the project that uses this library. The javafx.beans.property package is internally used by the external module, but it can't be exported.



So these are some proposed changes to make it work.



If you are creating a modular jar (using a module-info class) as a dependency for another project, you don't need to use the shadow plugin, and you don't need to bundle the JavaFX dependencies in your jars.



  1. External-library project

So you can have the same module-info.java file:



module com.example.external.lib 
requires javafx.base;
requires org.apache.commons.lang3;

exports com.example.external.library;



with a build.gradle like this:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




Now, when you run gradle build, you will generate libs/external-library.jar, a 2 KB jar, without JavaFX dependencies.



Note that if you still want to do shadow jar with this external project, you can use compileOnly "org.openjfx:javafx-base:11:$platform" to keep the JavaFX dependencies out of this jar.



  1. Project-using-external-lib

You can add that jar to the project.



build.gradle:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




But now your module-info file should include again the javafx.base dependency:



module example.project 
requires javafx.base;
requires com.example.external.lib;

exports com.example.project;



You can run gradle build to generate a jar, and IntelliJ won't complain anymore.



If you want to have a shadow jar at the end, you can also apply:



buildscript 
repositories
mavenCentral()
maven
url "https://plugins.gradle.org/m2/"


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'application'
apply plugin: 'com.google.osdetector'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



run
doFirst
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



mainClassName = "com.example.project.PublicClass"

jar
manifest
attributes 'Main-Class': 'com.example.project.PublicClass'

from
configurations.compile.collect it.isDirectory() ? it : zipTree(it)




so you would be able to run java -jar build/libs/project-using-external-lib.jar. Note that this jar will contain the JavaFX classes.



Doing a shadow jar is not to the recommended way to distribute your project, but since you have automatic modules (commons-lang3) you can't use jlink, unless you convert that into an explicit module (see this answer).






share|improve this answer

























  • Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

    – Hannes
    Nov 18 '18 at 22:09











  • I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

    – José Pereda
    Nov 18 '18 at 22:40











  • As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

    – José Pereda
    Nov 18 '18 at 22:48












  • Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

    – Hannes
    Nov 20 '18 at 11:52











  • There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

    – José Pereda
    Nov 20 '18 at 12:06















2





+100









Based on the project posted here, the error that you get when you open the project is:




Package 'javafx.beans.property' is declared in module 'com.example.external.lib', which does not export it to module 'example.project'




The reason for this error is that you are adding some packages from javafx.base to your external library, but those are not exported to the project that uses this library. The javafx.beans.property package is internally used by the external module, but it can't be exported.



So these are some proposed changes to make it work.



If you are creating a modular jar (using a module-info class) as a dependency for another project, you don't need to use the shadow plugin, and you don't need to bundle the JavaFX dependencies in your jars.



  1. External-library project

So you can have the same module-info.java file:



module com.example.external.lib 
requires javafx.base;
requires org.apache.commons.lang3;

exports com.example.external.library;



with a build.gradle like this:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




Now, when you run gradle build, you will generate libs/external-library.jar, a 2 KB jar, without JavaFX dependencies.



Note that if you still want to do shadow jar with this external project, you can use compileOnly "org.openjfx:javafx-base:11:$platform" to keep the JavaFX dependencies out of this jar.



  1. Project-using-external-lib

You can add that jar to the project.



build.gradle:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




But now your module-info file should include again the javafx.base dependency:



module example.project 
requires javafx.base;
requires com.example.external.lib;

exports com.example.project;



You can run gradle build to generate a jar, and IntelliJ won't complain anymore.



If you want to have a shadow jar at the end, you can also apply:



buildscript 
repositories
mavenCentral()
maven
url "https://plugins.gradle.org/m2/"


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'application'
apply plugin: 'com.google.osdetector'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



run
doFirst
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



mainClassName = "com.example.project.PublicClass"

jar
manifest
attributes 'Main-Class': 'com.example.project.PublicClass'

from
configurations.compile.collect it.isDirectory() ? it : zipTree(it)




so you would be able to run java -jar build/libs/project-using-external-lib.jar. Note that this jar will contain the JavaFX classes.



Doing a shadow jar is not to the recommended way to distribute your project, but since you have automatic modules (commons-lang3) you can't use jlink, unless you convert that into an explicit module (see this answer).






share|improve this answer

























  • Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

    – Hannes
    Nov 18 '18 at 22:09











  • I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

    – José Pereda
    Nov 18 '18 at 22:40











  • As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

    – José Pereda
    Nov 18 '18 at 22:48












  • Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

    – Hannes
    Nov 20 '18 at 11:52











  • There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

    – José Pereda
    Nov 20 '18 at 12:06













2





+100







2





+100



2




+100





Based on the project posted here, the error that you get when you open the project is:




Package 'javafx.beans.property' is declared in module 'com.example.external.lib', which does not export it to module 'example.project'




The reason for this error is that you are adding some packages from javafx.base to your external library, but those are not exported to the project that uses this library. The javafx.beans.property package is internally used by the external module, but it can't be exported.



So these are some proposed changes to make it work.



If you are creating a modular jar (using a module-info class) as a dependency for another project, you don't need to use the shadow plugin, and you don't need to bundle the JavaFX dependencies in your jars.



  1. External-library project

So you can have the same module-info.java file:



module com.example.external.lib 
requires javafx.base;
requires org.apache.commons.lang3;

exports com.example.external.library;



with a build.gradle like this:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




Now, when you run gradle build, you will generate libs/external-library.jar, a 2 KB jar, without JavaFX dependencies.



Note that if you still want to do shadow jar with this external project, you can use compileOnly "org.openjfx:javafx-base:11:$platform" to keep the JavaFX dependencies out of this jar.



  1. Project-using-external-lib

You can add that jar to the project.



build.gradle:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




But now your module-info file should include again the javafx.base dependency:



module example.project 
requires javafx.base;
requires com.example.external.lib;

exports com.example.project;



You can run gradle build to generate a jar, and IntelliJ won't complain anymore.



If you want to have a shadow jar at the end, you can also apply:



buildscript 
repositories
mavenCentral()
maven
url "https://plugins.gradle.org/m2/"


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'application'
apply plugin: 'com.google.osdetector'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



run
doFirst
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



mainClassName = "com.example.project.PublicClass"

jar
manifest
attributes 'Main-Class': 'com.example.project.PublicClass'

from
configurations.compile.collect it.isDirectory() ? it : zipTree(it)




so you would be able to run java -jar build/libs/project-using-external-lib.jar. Note that this jar will contain the JavaFX classes.



Doing a shadow jar is not to the recommended way to distribute your project, but since you have automatic modules (commons-lang3) you can't use jlink, unless you convert that into an explicit module (see this answer).






share|improve this answer















Based on the project posted here, the error that you get when you open the project is:




Package 'javafx.beans.property' is declared in module 'com.example.external.lib', which does not export it to module 'example.project'




The reason for this error is that you are adding some packages from javafx.base to your external library, but those are not exported to the project that uses this library. The javafx.beans.property package is internally used by the external module, but it can't be exported.



So these are some proposed changes to make it work.



If you are creating a modular jar (using a module-info class) as a dependency for another project, you don't need to use the shadow plugin, and you don't need to bundle the JavaFX dependencies in your jars.



  1. External-library project

So you can have the same module-info.java file:



module com.example.external.lib 
requires javafx.base;
requires org.apache.commons.lang3;

exports com.example.external.library;



with a build.gradle like this:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




Now, when you run gradle build, you will generate libs/external-library.jar, a 2 KB jar, without JavaFX dependencies.



Note that if you still want to do shadow jar with this external project, you can use compileOnly "org.openjfx:javafx-base:11:$platform" to keep the JavaFX dependencies out of this jar.



  1. Project-using-external-lib

You can add that jar to the project.



build.gradle:



buildscript 
repositories
jcenter()


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'com.google.osdetector'
apply plugin: 'java'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]




But now your module-info file should include again the javafx.base dependency:



module example.project 
requires javafx.base;
requires com.example.external.lib;

exports com.example.project;



You can run gradle build to generate a jar, and IntelliJ won't complain anymore.



If you want to have a shadow jar at the end, you can also apply:



buildscript 
repositories
mavenCentral()
maven
url "https://plugins.gradle.org/m2/"


dependencies
classpath 'com.google.gradle:osdetector-gradle-plugin:1.6.0'



apply plugin: 'application'
apply plugin: 'com.google.osdetector'

ext.platform = osdetector.os == 'osx' ? 'mac' : osdetector.os == 'windows' ? 'win' : osdetector.os

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

repositories
mavenCentral()


dependencies
compile files('libs/external-library.jar')
compile 'org.apache.commons:commons-lang3:3.8.1'
compile "org.openjfx:javafx-base:11:$platform"


compileJava
doFirst
options.compilerArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



run
doFirst
jvmArgs = [
'--module-path', classpath.asPath,
'--add-modules', 'javafx.base'
]



mainClassName = "com.example.project.PublicClass"

jar
manifest
attributes 'Main-Class': 'com.example.project.PublicClass'

from
configurations.compile.collect it.isDirectory() ? it : zipTree(it)




so you would be able to run java -jar build/libs/project-using-external-lib.jar. Note that this jar will contain the JavaFX classes.



Doing a shadow jar is not to the recommended way to distribute your project, but since you have automatic modules (commons-lang3) you can't use jlink, unless you convert that into an explicit module (see this answer).







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 14 '18 at 0:32

























answered Nov 14 '18 at 0:18









José PeredaJosé Pereda

25.9k34269




25.9k34269












  • Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

    – Hannes
    Nov 18 '18 at 22:09











  • I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

    – José Pereda
    Nov 18 '18 at 22:40











  • As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

    – José Pereda
    Nov 18 '18 at 22:48












  • Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

    – Hannes
    Nov 20 '18 at 11:52











  • There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

    – José Pereda
    Nov 20 '18 at 12:06

















  • Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

    – Hannes
    Nov 18 '18 at 22:09











  • I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

    – José Pereda
    Nov 18 '18 at 22:40











  • As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

    – José Pereda
    Nov 18 '18 at 22:48












  • Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

    – Hannes
    Nov 20 '18 at 11:52











  • There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

    – José Pereda
    Nov 20 '18 at 12:06
















Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

– Hannes
Nov 18 '18 at 22:09





Thank you for your answer - that worked out for me on the small example project. But I am not quite sure how to progress with my large codebase depending on a larger number of external libraries which have not been modularized yet. Any thoughts on that? I opened another question regarding this: stackoverflow.com/questions/53314512/…

– Hannes
Nov 18 '18 at 22:09













I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

– José Pereda
Nov 18 '18 at 22:40





I'd say you can do a combination of a fat jar for all non-modular dependencies, with a custom JRE with all the modular dependencies via jlink. Jpackager is around the corner, and that will allow creating an installer for your app, no matter if it has non-modular dependencies. Internally, by the way, is uses jlink, so it works pretty much as I described before.

– José Pereda
Nov 18 '18 at 22:40













As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

– José Pereda
Nov 18 '18 at 22:48






As mentioned at the end of my answer, there are also some "tricky" ways to generate modules out of non modular jars. See this, and this repo. This might help you to modularize jars that won't be ever modularized.

– José Pereda
Nov 18 '18 at 22:48














Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

– Hannes
Nov 20 '18 at 11:52





Well, I believe I am stuck ... that tricky way is nice if you have one or two dependencies but it is not possible to maintain that for a larger amount of libraries. Is there any roadmap if and when jpacker will be available?

– Hannes
Nov 20 '18 at 11:52













There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

– José Pereda
Nov 20 '18 at 12:06





There is a JEP for it, the initial target is Java 12, but it might not make it on time. Anyway, Gluon is working on a ea release for Java 11.

– José Pereda
Nov 20 '18 at 12:06

















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53248763%2ferror-package-is-declared-javafx-beans-value-in-module-foo-bar%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Crossroads (UK TV series)

ữḛḳṊẴ ẋ,Ẩṙ,ỹḛẪẠứụỿṞṦ,Ṉẍừ,ứ Ị,Ḵ,ṏ ṇỪḎḰṰọửḊ ṾḨḮữẑỶṑỗḮṣṉẃ Ữẩụ,ṓ,ḹẕḪḫỞṿḭ ỒṱṨẁṋṜ ḅẈ ṉ ứṀḱṑỒḵ,ḏ,ḊḖỹẊ Ẻḷổ,ṥ ẔḲẪụḣể Ṱ ḭỏựẶ Ồ Ṩ,ẂḿṡḾồ ỗṗṡịṞẤḵṽẃ ṸḒẄẘ,ủẞẵṦṟầṓế