JDK-8196130: Eclipse configuration files need to be updated
Kevin Rushforth
kevin.rushforth at oracle.com
Tue Feb 6 13:26:30 UTC 2018
It looks fine to me, although the files should be change back to have
UNIX-style line endings to minimize diffs (I can easily do that when I
push the change for you).
As for the javafx.web failures, you likely won't get any different
results when building webkit. To fix these failures, you might need to
add the following directory:
modules/javafx.web/src/main/native/Source/WebCore/bindings/java/dom3/java/
-- Kevin
Nir Lisker wrote:
> Attached webrev for .classpath changes for all javafx.xxx projects
> under /modules (though 2 of them are not modules).
>
> Change details:
> - The files were completely rewritten for Eclipse's current modular
> support, version 4.8M5, which is pre-release.
> - Some projects also need to change module-info.java for test code to
> identify imports properly due to bugs in Eclipse. These changes are
> excluded from the Webrev.
> - Since I didn't build Webkit, the web module has extra errors which I
> couldn't address, so the fix does not guarantee that this module will
> compile even with Webkit.
> - The swt project has external org.eclipse.swt imports which weren't
> addressed.
>
> Let's call this round 1. Next rounds will be when Eclipse fixes some
> bugs and when the source repo is cleaned from unused projects.
>
> - Nir
>
> On Fri, Feb 2, 2018 at 6:52 PM, Nir Lisker <nlisker at gmail.com
> <mailto:nlisker at gmail.com>> wrote:
>
> 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.rushforth at oracle.com <mailto:kevin.rushforth at 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.rushforth at oracle.com
>> <mailto: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
>>> <mailto: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\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.rushforth at oracle.com
>>>> <mailto: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\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
>>>>> <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.rushforth at oracle.com
>>>>> <mailto: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.JUNIT_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
>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
More information about the openjfx-dev
mailing list