Alright, got most of them ready. About buildSrc: - What is "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler" supposed to be? It is listed as a source folder but it's empty. - The project lists dependencies such as "build/libs/swt-debug.jar", JUnit and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view). I see the base module listing this project as a dependency, but it's not used. Where is it located in the dependency chain?
On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > It probably makes sense to submit what you have now as a partially working > solution. > > As for Eclipse making any changes, I'm not sure there is a spec you could > point to ... we do some of the same magic that I'm sure other projects have > had to do w.r.t running tests: > > * We have test "shims" for white-box testing that we add into our modules > when running tests (this requires copying all of the class files for our > modules and adding the shim classes on top of that) > > * We build the tests separately (the tests are in a separate source set in > gradle) without a module-info so that they run in the unnamed module. This > allows them to access JUnit, etc., as well as any public package of any > module in the system. As such we need to explicitly list any internal > packages that they use from the module they are testing. These are listed > in src/test/addExports > > > -- Kevin > > > Nir Lisker wrote: > > Looks like I understood the problem. Eclipse does not support (yet) > multiple modules per project. Do you know any specifications I can point > them to to fix this properly? > > The current workaround would be to add 'requires' for all the modules > which are used in tests as well. This change is local and would be excluded > from webrevs. > > At this point I can either submit the partially fixed Eclipse files, which > work with main code fully and with test code only if the above fix is used; > or wait until Eclipse sorts it out. > > On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> >> >> Nir Lisker wrote: >> >> rt/modules/javafx.base/build/classes/main/javafx.base/ >>> rt/modules/javafx.base/src/main/java/ >> >> >> Why not rely on source first? >> >> >> Yes, that might work...you could try switching the order. >> >> >> >> 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? >> >> >> The only references to java.util.logging are in the javafx.base unit >> tests, which are compiled and run in the unnamed modules (no >> module-info.java for the unit tests). >> >> -- Kevin >> >> >> >> 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\mai >>> n\java\javafx\beans\Observable.java >>> - in the JDK it's in: jdk\modules\javafx.base\ja >>> vafx\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\javaf >>>> x\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\javaf >>>> x\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 >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >
