Yes, that seems best. Can you also add a comment to the JBS bug to that
effect? That way if someone else wants to pick it back up they'll have a
clear pointer to the old PR.
Thanks.
-- Kevin
On 11/20/2020 2:50 AM, Jeanette Winzenburg wrote:
Kevin,
had taken it, created a PR
https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/352__;!!GqivPVa7Brio!MZUfQlysgJ4YALuP_Dajocgq4pWaSfmMelA0rUxhP2IGide7fOOWSG3a9rikTniInRc3$
with the suggested changes. In review it turned out to be not enough
to cover its current usage, tests need it as well. Doing it completely
would require to setup all fx modules (and tests) in my local Eclipse
environment - which .. is off-scope for me ;)
So stopped work, unassigned the issue - which the bot didn't notice:
should I close the PR manually?
-- Jeanette
Zitat von Kevin Rushforth <kevin.rushfo...@oracle.com>:
Yes, it does seem that as long as the .classpath files are in the
repo, they should work. I assigned the JBS bug to you since you have
proposed a fix. You can reassign it if you want. I'm not an Eclipse
user, so it would need to be done by someone who is.
-- Kevin
On 11/11/2020 2:00 AM, Jeanette Winzenburg wrote:
FYI: filed an issue https://bugs.openjdk.java.net/browse/JDK-8256184
don't know what the plans for supporting IDE builds are - but as
long as it is available, they should work, IMO.
-- Jeanette
Zitat von Jeanette Winzenburg <faste...@swingempire.de>:
Zitat von Florian Kirmaier <florian.kirma...@gmail.com>:
Eclipse probably handles the modules differently than Gradle.
probably - couldn't find gradle's magic in the build script (and
lost interest, because that part is running okay and there are
enough experts around to keep it that way :)
The simplest solution would be to remove the code to automatically
create
heap dumps.
Adding java.management to module-info of the tests doesn't sound
wrong to
me if it's using it.
that's basically, what I ended up with.
To summarize the problem: when compiling base and running tests of
controls in Eclipse I got
a) JMemoryBuddy doesn't compile, Eclipse suggests to add requires
jdk.management and java.management
b) following the suggestion, some controls test don't compile due
to base:test.util.memory not being accessible
As changing production module-info is not an option (and Eclipse'
support for test module-info is wip - see
https://urldefense.com/v3/__https://bugs.eclipse.org/bugs/show_bug.cgi?id=559601__;!!GqivPVa7Brio!MZUfQlysgJ4YALuP_Dajocgq4pWaSfmMelA0rUxhP2IGide7fOOWSG3a9rikTtQcIFO5$
) I played a bit with the (new to me ;) module dependencies tab in
build path config and added reads to both modules. Couldn't find a
way to add them to test sources only (Eclipse added them to java
src), so manually moved in .classpath file, its test entry now is:
<classpathentry kind="src" output="testbin" path="src/test/java">
<attributes>
<attribute name="test" value="true"/>
<attribute name="optional" value="true"/>
<attribute name="module" value="true"/>
<attribute name="add-reads"
value="javafx.base=jdk.management:javafx.base=java.management"/>
</attributes>
</classpathentry>
This fixed the error in base.
To fix the error in controls, I added the export of new base test
package in :controls .classpath
<classpathentry combineaccessrules="false" kind="src" path="/base">
<attributes>
<attribute name="module" value="true"/>
<attribute name="add-exports"
value="javafx.base/test.com.sun.javafx.binding=javafx.controls:javafx.base/test.util.memory=javafx.controls"/>
</attributes>
</classpathentry>
no idea how stable all this is, working for me at least. Should the
eclipse specific files updated in master, with this or something
similar/better?
Opinions, please?
-- Jeanette
On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth
<kevin.rushfo...@oracle.com>
wrote:
I didn't try it with an earlier JDK, but if it breaks when using
JDK 11
it will need to be fixed.
-- Kevin
On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote:
just fetched the latest upstream master and getting compile errors
around xx.management packages (eclipse wants to add requires
into the
module-info - which certainly is the wrong way to go ;) Compiling
against jdk12, if that matters (will update one of these days but
shouldn't jdk11 be good enough).
Any quick ideas on what might be wrong?
-- Jeanette
