search

RMLio / rmlmapper-java

The RMLMapper executes RML rules to generate high quality Linked Data from multiple originally (semi-)structured data sources
http://rml.io
MIT License
144 stars 61 forks source link

Dependency resolution of rmlmapper 6.2.1 fails #215

Closed IanEmmons closed 10 months ago

IanEmmons commented 10 months ago

When I try to use rmlmapper as a library (via the gradle dependency 'be.ugent.rml:rmlmapper:6.2.1'), gradle is unable to resolve the following dependencies against MavenCentral:

When I add the artifact repository 'https://jitpack.io', gradle successfully resolves the four above, but is unable to resolve this one:

Which is pulled in via the following dependency chain:

Is there another Maven repository that I need? Or is there a library you forgot to publish? Or is something more subtle going on?

bjdmeest commented 10 months ago

We'll look into this (because it's at least weird that this isn't happening locally or in our CI processes), but I suggest that you also follow-up on the RDFHDT github: I would expect the proper fix to be something on their end (given it's a dependency of rdfhdt that doesn't resolve)

IanEmmons commented 10 months ago

Thanks. I've submitted https://github.com/rdfhdt/hdt-java/issues/198. One further note: I discovered that MavenCentral has a library under the designation 'org.rdfhdt:hdt-java-core:3.0.5' (with latest version 3.0.9). That runs into the same problem with JLargeArrays, however. But it may be the case that your hdt-java dependency is not using the preferred organization ID. (I've asked this in the issue above.)

IanEmmons commented 10 months ago

The rdfhdt team put out a new release, in which they removed JLargeArrays and replaced it with their own implementation. They recommend that you change your rdfhdt dependency from 'com.github.rdfhdt.hdt-java:hdt-java:v3.0.5' to 'org.rdfhdt:hdt-java-core:3.0.10'. Notice the change in group ID — this means the dependency will come from MavenCentral rather than 'https://jitpack.io', which is a happy thing.

IanEmmons commented 10 months ago

Given the new 3.0.10 rdfhdt release, it seems to me that the path forward would be for the RMLMapper team to update that dependency and release version 6.2.2. Just so I can best decide how to move forward with my work, could you please comment on whether that's correct and what your estimated timeline looks like? Sorry to nag, but in the near it changes my best path forward term quite a bit.

DylanVanAssche commented 10 months ago

We can update the dependency. Could you verify then from the development branch if your problem is fixed?

IanEmmons commented 10 months ago

Sure, I can do that. But I can already report that if I create a test project with a dependency on 'org.rdfhdt:hdt-java-core:3.0.10' then the dependency resolution works, whereas the similar experiement with 'com.github.rdfhdt.hdt-java:hdt-java:v3.0.5' reproduced the problem with resolving the JLargeArrays library. This should raise your confidence that the updated dependency will work. Let me know when you are ready for me to test.

DylanVanAssche commented 10 months ago

@IanEmmons Thanks! Pushed a commit to the dev branch. Once tested, we can close this.

IanEmmons commented 10 months ago

@DylanVanAssche Yes, it checks out. I am able to build against this version. I look forward to seeing 6.2.2 released soon-ish, though I have a workaround with my local build, so it's no emergency.

DylanVanAssche commented 10 months ago

Awesome! Thanks for confirming @IanEmmons !