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 <nlis...@gmail.com
<mailto:nlis...@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.rushfo...@oracle.com <mailto: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
<mailto: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
<mailto:kevin.rushfo...@oracle.com>> wrote:
Oh, I see. You are pointing to the exploded modules
for the JDK in build/XXXXX/jdk rather than the JDK
image in build/XXXXX/images/jdk.
Yes, I think it would be preferable to both reverse
the order and also add in the location of the built
class files. So the following order seems best:
rt/modules/javafx.base/build/classes/main/javafx.base/
rt/modules/javafx.base/src/main/java/
jdk/modules/javafx.base
-- Kevin
Nir Lisker wrote:
This is what I mean: In the
type
/base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java
there are these imports:
import test.javafx.collections.MockListObserver;
import java.util.BitSet;
import javafx.beans.Observable;
The first one is the one in
FX:
rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java
The second one is in the referenced JDK which was
built with
FX: jdk\modules\java.base\java\util\BitSet.class
The third one exists in both:
- in JFX it's in:
rt\modules\javafx.base\src\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
<mailto: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/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.rushfo...@oracle.com
<mailto:kevin.rushfo...@oracle.com>> wrote:
inline
Nir Lisker wrote:
Alright, cleaned that part. fxpackager
build fails with an internal NPE in
Eclipse, so I'm going to leave that alone
and all of the projects that depends on it.
Now that projects can be built there are
errors in deeper levels:
1. All org.junit imports cannot be
resolved. This causes tons of errors in
various test folders obviously. All the
.classpath files use
<classpathentry kind="con"
path="org.eclipse.jdt.junit.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.rushfo...@oracle.com
<mailto: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
<mailto:kevin.rushfo...@oracle.com>>
wrote:
One more thing about the
specific path you mentioned as
not being there.
<classpathentry kind="src"
exported="true"
path="build/resources/jsl-decora"/>
<classpathentry kind="src"
exported="true"
path="build/resources/jsl-prism"/>
These are still being created by
'gradle sdk', but the path is
wrong (the files moved in JDK 9)
and should be:
build/gensrc/jsl-decora
build/gensrc/jsl-prism
You might want to take that into
account.
-- Kevin
Kevin Rushforth wrote:
Nir Lisker wrote:
Iv'e removed all the
classpath dependencies
that were causing
errors. I don't mind
sorting out the rest of
the files while at it,
though for that there
are a few things I'm not
sure about:
1. Some dependencies are
marked as optional and
as such they don't cause
errors, but they are
still missing. Is it
safe to remove them or
is it possible that they
will be created as some
point?
Some of them might be
created...not sure without
checking. I recommend
running "gradle sdk" and
then seeing if the
dependencies are there.
Examples are the 'base'
module with
"src/test/resources" and
"src/main/resources"
optional dependencies,
and 'controls' module
has the optional
dependency
"src/main/resources"
commented out.
I see. You might as well
leave them, but it probably
doesn't matter.
2. Can I assume that all
other dependencies are
really needed? (Eclipse
won't complain about
unused ones as far as I
know.)
That seems best.
3. What are the
formatting standards for
XML (indentation, line
length...)? From a quick
look I see different
styles in different files.
For IDE files, we don't
worry about formatting. In
many cases they are
auto-generated anyway.
-- Kevin
- Nir
