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
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
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
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
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
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"
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
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
>
> 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
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:
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:
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
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
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
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
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
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
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,
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.
19 matches
Mail list logo
