This is what I mean: In the type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java there are these imports:
import test.javafx.collections.MockListObserver; import java.util.BitSet; import javafx.beans.Observable; The first one is the one in FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java The second one is in the referenced JDK which was built with FX: jdk\modules\java.base\java\util\BitSet.class The third one exists in both: - in JFX it's in: rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java - in the JDK it's in: jdk\modules\javafx.base\javafx\beans\Observable.class Does the question make sense now? On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > > one in > "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" > or the one in "jdk\modules\javafx.base\javafx\beans\ > InvalidationListener.class"? > > > Not sure I get what you mean. There isn't a jdk/modules/ directory created > by the build. Perhaps this is an Eclipse construct that it uses to indicate > the modules that are in the JDK that you are using? The FX build puts the > class files in: > > rt/build/modular_sdk/modules/javafx.base/... > > > -- Kevin > > > Nir Lisker wrote: > > Another question: do imports of javafx.* packages point to the javafx > source or to the jdk compilation? > > For example, in the base module, the type > test.javafx.beans.InvalidationListenerMock > imports javafx.beans.InvalidationListener (twice, by the way, along with > Observable). Should the imported class be the one in > "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" > or the one in "jdk\modules\javafx.base\javafx\beans\ > InvalidationListener.class"? > > Currently, the way it is in the Eclipse files is that the jdk .class files > are imported first[1], but it seemed odd to me - if I work on 2 files which > depend on each other they should see the changes in each other at once. > > [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/ > 305d127c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before > "src/main/java"), > > - Nir > > On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> inline >> >> Nir Lisker wrote: >> >> Alright, cleaned that part. fxpackager build fails with an internal NPE >> in Eclipse, so I'm going to leave that alone and all of the projects that >> depends on it. >> >> Now that projects can be built there are errors in deeper levels: >> >> 1. All org.junit imports cannot be resolved. This causes tons of errors >> in various test folders obviously. All the .classpath files use >> >> <classpathentry kind="con" path="org.eclipse.jdt.junit.JU >> NIT_CONTAINER/4"/> >> >> which is a jar distributed with Eclipse (in the plugins folder) with >> version 4.12.0. Is this really where the imports are supposed to come from? >> How does it work in Netbeans or IntelliJ? >> >> >> For NetBeans we use their internal version of JUnit. I don't know about >> IntelliJ (maybe someone else on the list can answer that). >> >> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >> are these located? >> >> >> These classes used to be part of the JFR commercial feature in the Oracle >> JDK. The java-jfr sources are obsolete and no longer built (and no longer >> buildable), so you can safely remove it from your IDE files. I also still >> see references to it in the netbeans/base project. I will file a bug to >> remove this obsolete code and fix the NetBeans references at the same time. >> >> -- Kevin >> >> >> >> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >> kevin.rushfo...@oracle.com> wrote: >> >>> Ah, I see. Then yes, just removing the old ones is fine. >>> >>> As for the larger question, unless there are dependencies on apps, you >>> can assume that the only ones you care about are the ones created by >>> "gradle sdk". >>> >>> -- Kevin >>> >>> >>> >>> Nir Lisker wrote: >>> >>> So this is why I was asking about the optional stuff: 'graphics' module >>> has BOTH >>> >>> build/resources/jsl-decora >>> build/resources/jsl-prism >>> >>> and >>> >>> build/gensrc/jsl-decora >>> build/gensrc/jsl-prism >>> >>> That led me to think that when the new dependencies were added the old >>> ones weren't removed. Those that weren't optional (like the /resources >>> ones, which I removed) were easy to catch and we could have finished here. >>> Those that are optional are not causing trouble even when missing because >>> they are optional. >>> >>> gradle sdk does not create the ones which are marked optional that Iv'e >>> surveyed, but I don't know if that's the only way they can be created. If I >>> compare solely with gradle sdk then I can just remove whatever is missing >>> on grounds that it's left over. >>> >>> - Nir >>> >>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>> kevin.rushfo...@oracle.com> wrote: >>> >>>> One more thing about the specific path you mentioned as not being there. >>>> >>>> <classpathentry kind="src" exported="true" >>>> path="build/resources/jsl-decora"/> >>>> <classpathentry kind="src" exported="true" >>>> path="build/resources/jsl-prism"/> >>>> >>>> These are still being created by 'gradle sdk', but the path is wrong >>>> (the files moved in JDK 9) and should be: >>>> >>>> build/gensrc/jsl-decora >>>> build/gensrc/jsl-prism >>>> >>>> You might want to take that into account. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Kevin Rushforth wrote: >>>> >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>>> Iv'e removed all the classpath dependencies that were causing errors. >>>>>> I don't mind sorting out the rest of the files while at it, though for >>>>>> that >>>>>> there are a few things I'm not sure about: >>>>>> >>>>>> 1. Some dependencies are marked as optional and as such they don't >>>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>>> it possible that they will be created as some point? >>>>>> >>>>> >>>>> Some of them might be created...not sure without checking. I recommend >>>>> running "gradle sdk" and then seeing if the dependencies are there. >>>>> >>>>> Examples are the 'base' module with "src/test/resources" and >>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>> optional dependency "src/main/resources" commented out. >>>>>> >>>>> >>>>> I see. You might as well leave them, but it probably doesn't matter. >>>>> >>>>> 2. Can I assume that all other dependencies are really needed? >>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>> >>>>> >>>>> That seems best. >>>>> >>>>> 3. What are the formatting standards for XML (indentation, line >>>>>> length...)? From a quick look I see different styles in different files. >>>>>> >>>>> >>>>> For IDE files, we don't worry about formatting. In many cases they are >>>>> auto-generated anyway. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>>> - Nir >>>>>> >>>>> >>> >> >