Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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  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.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/X/jdk rather than the JDK image in build/X/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
 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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

Oh, I see. You are pointing to the exploded modules 
for the JDK in build/X/jdk rather than the JDK

image in build/X/images/jdk.

Yes, I think it would be preferable to both reverse
the order and also add in the location of the 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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 
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/X/jdk rather than the JDK image in build/X/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 
 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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


Oh, I see. You are pointing to the exploded modules  for the JDK in
build/X/jdk rather than the JDK image in build/X/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



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 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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

Oh, I see. You are pointing to the exploded modules  for the
JDK in build/X/jdk rather than the JDK image in
build/X/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
> 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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Michael Paus]

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


Oh, I see. You are pointing to the exploded modules  for the JDK in
build/X/jdk rather than the JDK image in build/X/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



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 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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


Oh, I see. You are pointing to the exploded modules  for the JDK
in build/X/jdk rather than the JDK image in
build/X/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
>
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


("JRE_CONTAINER" is before "src/main/java"),

- Nir

On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth
> 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



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 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

>
> rt/modules/javafx.base/build/classes/main/javafx.base/
> rt/modules/javafx.base/src/main/java/


Why not rely on source first?

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?

On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth  wrote:

> Oh, I see. You are pointing to the exploded modules  for the JDK in
> build/X/jdk rather than the JDK image in build/X/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.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\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/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
>>>
>>> 
>>>
>>> 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".

 -- 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

Oh, I see. You are pointing to the exploded modules  for the JDK in 
build/X/jdk rather than the JDK image in build/X/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 
> 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


("JRE_CONTAINER" is before "src/main/java"),

- Nir

On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth
>
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



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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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 
("JRE_CONTAINER" is before "src/main/java"),


- Nir

On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth 
> 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



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

One more thing about the specific path you mentioned as
not being there.




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 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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
("JRE_CONTAINER" is before "src/main/java"),

- Nir

On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth  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
>
> 
>
> 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.
>>>
>>> 
>>> 
>>>
>>> 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 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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


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

One more thing about the specific path you mentioned as not
being there.




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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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


One more thing about the specific path you mentioned as not being
there.




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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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

> One more thing about the specific path you mentioned as not being there.
>
> 
> 
>
> 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
>>>
>>

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

One more thing about the specific path you mentioned as not being there.

path="build/resources/jsl-decora"/>
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

Re: JDK-8196130: Eclipse configuration files need to be updated

[Kevin Rushforth]

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

JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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

2. Can I assume that all other dependencies are really needed? (Eclipse
won't complain about unused ones as far as I know.)

3. What are the formatting standards for XML (indentation, line length...)?
>From a quick look I see different styles in different files.

- Nir