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
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to