> > rt/modules/javafx.base/build/classes/main/javafx.base/ > rt/modules/javafx.base/src/main/java/
Why not rely on source first? Another question as I move along: there are imports from java.util.logging in base module, but the module-info doesn't require java.logging. How do I give access to these imports? On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > Oh, I see. You are pointing to the exploded modules for the JDK in > build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. > > Yes, I think it would be preferable to both reverse the order and also add > in the location of the built class files. So the following order seems best: > > rt/modules/javafx.base/build/classes/main/javafx.base/ > rt/modules/javafx.base/src/main/java/ > jdk/modules/javafx.base > > > -- Kevin > > > Nir Lisker wrote: > > 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/305d12 >> 7c6ed5/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 >>>>>>> >>>>>> >>>> >>> >> >
