Eclipse cannot handle 11.3.0 for some reason

[crowlogic]

Eclipse cannot handle 11.3.0 for some reason

[wirew0rm]

@crowlogic please take a look at our Code of Conduct if you plan to continue interacting with this project. We should treat each other with respect and your previous comment fails to reflect that.

The point of testing with different maven implementations is an indicator whether we are doing something invalid in our pom structure or whether the problem is in the specific IDE's implementation. Closing this bug means that we believe that the problem should probably be fixed/investigated in eclipse or at least by other eclipse users. If that turns out new results or problems on our side you can still comment or reopen the issue.

In general we are trying to not break chart-fx for anyone independent of their preferred IDE or OS, but as we do not have infinite resources we cannot actively investigate issues on systems we are not actively using ourselves. I think that is reasonable.

[RalphSteinhagen]

@crowlogic, we need more information on this. Your description is inconclusive. Could you check that the effect you see is reproducible using the maven command line tool on a freshly checked out source tree?

[ennerf]

>> mvn dependency:tree --pl chartfx-dataset
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------< io.fair-acc:dataset >-------------------------
[INFO] Building chartfx-dataset master-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ dataset ---
[INFO] io.fair-acc:dataset:jar:master-SNAPSHOT
[INFO] +- io.fair-acc:bench:jar:master-SNAPSHOT:compile
[INFO] ... others ...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.063 s
[INFO] Finished at: 2023-12-18T11:42:39+01:00
[INFO] ------------------------------------------------------------------------

From the maven docs on the compile scope:

This is the default scope, used if none is specified. 
Compile dependencies are available in all classpaths of a project. 
Furthermore, those dependencies are propagated to dependent projects.

The dependency definition is valid according to the Maven spec, so there is no error here. That being said, we can specify the dependency explicitly to work around this apparent bug in Eclipse. Thanks for finding it.

There are only two industries who call people users, drug pushers, and software developers.

That's just nonsense 🤷‍♂️ Any tooling company refers to customers as users, and at the end of the day Software is just another tool.

[crowlogic]

Hi @RalphSteinhagen ,

The issue persists, from the commandline maven has no problem compiling it, which seems weird .. if i compile from maven, then delete the errors and dont touch the files that extend AbstractDataSet its ok, but otherwise its broken. You should be able to reproduce this pretty easily just by checking out the arb4j project in eclipse, see crowlogic/arb4j@9a9a25c

[RalphSteinhagen]

@crowlogic it seems that this is not reproducible with the command-line maven, other IDEs (N.B. we are using idea), or unit-test.

I suggest following up on this with the Eclipse IDE community that seems to reimplemented their own non-conformant version of maven.

I am closing this issue as this is not related to this specific library. Hope that the Eclipse community can fix your problem in their IDE.

[crowlogic]

The whole f****** point was eclipse specific so I don't know why you would even want to test it on another IDE in the first place but whatever you want dude. And has nothing to do with something not conforming with whatever rigid standards you think need to be conformed to it's called a f****** bug. Thanks for f****** nothing Hope you all can find a little diversity in your development environment for other environments besides crap beans or whatever that thing is

[yezhengli-Mr9]

Hi @RalphSteinhagen ,

The issue persists, from the commandline maven has no problem compiling it, which seems weird .. if i compile from maven, then delete the errors and dont touch the files that extend AbstractDataSet its ok, but otherwise its broken.

Dear @crowlogic, recommend Intellij (Community) if better for debug while command lines in terminal are enough for exec:java.

[crowlogic]

Hi @RalphSteinhagen ,

The issue persists, from the commandline maven has no problem compiling it, which seems weird .. if i compile from maven, then delete the errors and dont touch the files that extend AbstractDataSet its ok, but otherwise its broken.

Dear @crowlogic, recommend Intellij (Community) if better for debug while command lines in terminal are enough for exec:java.

Jet brain sucks I will check out the project in eclipse and then fix the bug in eclipse I would rather stab myself in the eye with a hot poker than use intelliJ. As it is to work around of just deleting the errors and eclipse works just fine for now. It's just maddening because this guy asked me for information and then I did a fair amount of work based on that request under the assumption that he was going to actually be helpful or useful instead of just redirect or say not my problem

[crowlogic]

If you want something done right you got to do it yourself, The Golden rule

[ennerf]

Eclipse has a tiny market share and none of the maintainers use it themselves. If there were a clear error message it'd be one thing, but the error is not particularly useful either. This issue also doesn't affect regular users, and I'm unclear why you need to build from an IDE in the first place.

[crowlogic]

I've fixed this error, it was indeed a problem with chartfx. The issue is that AbstractDataSet depends on Measurable which is in the bench project. If the bench project is not imported, this class is not available. Perhaps there is a module dependency not declared properly somewhere

[crowlogic]

@ennerf it boggles the mind how you could NOT build from the IDE. Nonetheless, your comments about "regular users" not withstanding, the issue is indeed one where your subpar IDEs are not exact enough to expose this error that was swept under the rug by this inferior IDEs. There are only two industries who call people users, drug pushers, and software developers.

[crowlogic]

Strangely, mvn:dependencies sees it, but eclipse doesnt pick it up unless its explicitly specified as required in the module-info. It could be a bug in m2e or perhaps related to a DTD parsing error being strict in one implementation and not the other, I've seen this as a cause of related problems before. I guess you aren't wrong there, you gotta call it something i guess. Thanks for humoring me, im grumpy as hell my eyes hurt my neck hurts half the time

when i add requires transitive io.fair_acc.bench;

the dependency:tree command remains the same but it makes eclipse happy.

The benefit of building from within the IDE is that changes are recompiled immediately when the file is saved and one doesn't have to waste time building and installing

[INFO] --------------------------< org.arblib:arb4j >--------------------------
[INFO] Building arb4j 0.8
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ arb4j ---
[INFO] org.arblib:arb4j:jar:0.8
[INFO] +- org.ow2.asm:asm:jar:9.5:compile
[INFO] +- org.ow2.asm:asm-util:jar:9.5:compile
[INFO] | +- org.ow2.asm:asm-tree:jar:9.5:compile
[INFO] | - org.ow2.asm:asm-analysis:jar:9.5:compile
[INFO] +- org.slf4j:slf4j-jdk14:jar:2.0.7:compile
[INFO] | - org.slf4j:slf4j-api:jar:2.0.7:compile
[INFO] +- org.openjfx:javafx-base:jar:20.0.2:compile
[INFO] | - org.openjfx:javafx-base:jar:linux:20.0.2:compile
[INFO] +- org.openjfx:javafx-swing:jar:20.0.2:compile
[INFO] | +- org.openjfx:javafx-swing:jar:linux:20.0.2:compile
[INFO] | - org.openjfx:javafx-graphics:jar:20.0.2:compile
[INFO] | - org.openjfx:javafx-graphics:jar:linux:20.0.2:compile
[INFO] +- org.openjfx:javafx-fxml:jar:20.0.2:compile
[INFO] | +- org.openjfx:javafx-fxml:jar:linux:20.0.2:compile
[INFO] | - org.openjfx:javafx-controls:jar:20.0.2:compile
[INFO] | - org.openjfx:javafx-controls:jar:linux:20.0.2:compile
[INFO] +- com.massisframework:j-text-utils:jar:0.3.4:compile
[INFO] | +- com.google.guava:guava:jar:21.0:compile
[INFO] | +- commons-lang:commons-lang:jar:2.6:compile
[INFO] | - au.com.bytecode:opencsv:jar:2.4:compile
[INFO] +- org.scilab.forge:jlatexmath:jar:1.0.7:compile
[INFO] | +- org.scilab.forge:jlatexmath-font-greek:jar:1.0.7:compile
[INFO] | - org.scilab.forge:jlatexmath-font-cyrillic:jar:1.0.7:compile
[INFO] +- io.fair-acc:chartfx:jar:11.3.0:compile
[INFO] | +- org.kordamp.ikonli:ikonli-javafx:jar:12.3.1:compile
[INFO] | | - org.kordamp.ikonli:ikonli-core:jar:12.3.1:compile
[INFO] | +- org.kordamp.ikonli:ikonli-fontawesome-pack:jar:12.3.1:compile
[INFO] | +- org.kordamp.ikonli:ikonli-fontawesome5-pack:jar:12.3.1:compile
[INFO] | +- io.fair-acc:dataset:jar:11.3.0:compile
[INFO] | +- io.fair-acc:math:jar:11.3.0:compile
[INFO] | | +- com.github.wendykierp:JTransforms:jar:3.1:compile
[INFO] | | | - pl.edu.icm:JLargeArrays:jar:1.5:compile
[INFO] | | - org.apache.commons:commons-math3:jar:3.6.1:compile
[INFO] | +- ar.com.hjg:pngj:jar:2.1.0:compile
[INFO] | +- org.hdrhistogram:HdrHistogram:jar:2.1.12:compile
[INFO] | +- org.apache.commons:commons-lang3:jar:3.13.0:compile
[INFO] | - org.jetbrains:annotations:jar:24.0.1:compile
[INFO] +- io.fair-acc:bench:jar:11.3.0:compile
[INFO] +- ch.qos.logback:logback-classic:jar:1.2.3:compile
[INFO] | - ch.qos.logback:logback-core:jar:1.2.3:compile
[INFO] +- org.controlsfx:controlsfx:jar:11.1.2:compile
[INFO] - junit:junit:jar:4.13.2:compile
[INFO] - org.hamcrest:hamcrest-core:jar:1.3:compile

[RalphSteinhagen]

@crowlogic, it's good that you seem to have isolated the root cause and workaround for your problem.

The Eclipse IDE implemented its own maven integration, which is known for having some non-conformities. Maybe you could let the good folks at Eclipse know that there is a non-conformity or even provide a patch to fix it there: https://github.com/eclipse-m2e/m2e-core/issues.

[wirew0rm]

when i add requires transitive io.fair_acc.bench;

Oh, I guess we are talking about different modules, maven modules have nothing to do with JPMS/jigsaw modules. The later unfortunately was still a big mess when I last tried to add proper support for it to chart-fx. The only way to really do that is to only use dependencies that are also fully modularized (or complicated maven plugins that essentially shard them and patch them to be modularized in the process).
Do you need to use jigsaw for anything specific (e.g. jlink)? Otherwise you could probably just put chart-fx on the classpath instead of the module path and be good...