JDK-8196130: Eclipse configuration files need to be updated

Thu Feb 1 21:13:50 UTC 2018

So it seems either a workaround is needed, or else maybe create two 
Eclipse projects: one for the sources and one for the tests.

-- Kevin

Michael Paus wrote:
> Am 01.02.18 um 19:41 schrieb Nir Lisker:
>> 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?
> I would not expect a change of this any time soon. There was a lengthy
> discussion of this topic and they decided to do it the way they have 
> always
> done it. One project = one module.
>>
>> 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.rushforth at 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.rushforth at 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.rushforth at 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.rushforth at 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.rushforth at 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.rushforth at 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
>>>>>>>>>>
>