JDK-8196130: Eclipse configuration files need to be updated
Kevin Rushforth
kevin.rushforth at oracle.com
Wed Feb 7 03:15:23 UTC 2018
Looks good.
-- Kevin
Nir Lisker wrote:
> Attached updated webrev.
>
> Changed line endings. If something is still wrong you can change it.
>
> You were right about the missing web source folder. Project now builds
> without errors.
>
> On Tue, Feb 6, 2018 at 3:26 PM, Kevin Rushforth
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
> 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