Exclusion of xml-apis from pom file

[enriquedelpino]

Hi all,

We in Graph.Build are users of the RMLMapper project you guys created. We were users of version 5.0 of the project, and are now trying to upgrade to your latest (6.5.1), which works on Java 17. The overall upgrade has been seamless, but we've found a problem on the build related to XML apis.

Since Java 11, xml-apis have been included in the core of JDK, and the usage of old dependencies like the following is disencouraged.

<!-- https://mvnrepository.com/artifact/xml-apis/xml-apis --> <dependency> <groupId>xml-apis</groupId> <artifactId>xml-apis</artifactId> <version>2.0.2</version> </dependency>
In fact, our consumers make use of some of the classes defined in the xml packages of the core language (which are also defined on the old xml-apis) and this breaks our build. Java complains the packages are defined by two different modules, which is not allowed in simple terms.

You are not directly using this dependency on your project, but rather have transitive dependencies to it through xlsx-streamer and simple-odf. As far as I know, you are on the latest version of simple-odf and this project has not been actively mantained for ages.

Normally, a problem like this would be easily solved on the projects we maintain and consume your RMLMapper (and hence dataio) by dependency managing and excluding the xml-apis, but in the case of your projects you use maven-shade-plugin which makes impossible to dependency manage imports which are fat jars.

I would like to request that at least the xml-apis dependencies are excluded as I suggest on my following snippet, even though I think it would be much more useful for consumers of your projects not to use maven shade plugin in order to allow us to dependency manage problems like this. I could understand your top-level project RMLMapper does shade the jar file, but I don't see why the anciliary projects created in the latest versions since v5 need to be shaded, such us dataio.

`
com.monitorjbl
xlsx-streamer
2.2.0


xml-apis
xml-apis

    <!--==============================================-->
    <!-- Open document format processing dependencies -->
    <!--==============================================-->
    <dependency>
        <groupId>org.odftoolkit</groupId>
        <artifactId>simple-odf</artifactId>
        <version>0.9.0</version>
        <exclusions>
            <exclusion>
                <groupId>xml-apis</groupId>
                <artifactId>xml-apis</artifactId>
            </exclusion>
        </exclusions>
    </dependency>`

I hope this is not a huge problem that cannot be dealt with easily, and I would like to emphasize that us from Graph.Build are more than happy to help maintaining this project in the best of shapes for the community. We really love the great work you've put into this.

Regards,
Enrique

[ghsnd]

Hi Enrique,

Thanks a lot for the suggestion. Also, you're absolutely right about the shade plugin, this must have been a copy-paste remainder from another project. Both have been changed an merged into the development branch.

Hope this helps.

Best regards,
Gerald

[ghsnd]

I just made a 1.2.0 release including these changes.

We will also update RMLMapper to use this version soon.

[enriquedelpino]

Hi Gerald,

First of all I would like to thank you greatly for your prompt response to my issue request. This is going to be very important for us in our upgrade to the latest versions of the RMLMapper.

I would like to ask you a couple of extra questions related to this topic.

The first one is if you are planning to remove the maven shade plugin to RMLMapper as well or this is something you are not happy to consider. I hope you don't mind me giving my two cents on the matter. The RMLMapper is a great tool but I would not say it is likely to be a final production artifact, but rather to be streamlined with other software that make use of it as a dependency. In these situations, I would normally be looking for my dependencies not to be shaded, in order to be able to manage other dependencies down the dependency tree. It is, of course up to the owners of the project to decide how they want to ship it, but it would be good for us to know what are your thoughts on the matter.

The second question is related to the fact you mentioned 'dataio' 1.2.0 will be included in RMLMapper soon, and I would like to ask you if there is any estimation of this new release version of RMLMapper would be available. We currently have forked your repos to make these adjustments, but our long term goal is to try to only depend on your released artifacts rather than mantaining our repos.

Kind Regards,
Enrique

[enriquedelpino]

Just following up with this topic. Would it be possible to get an answer to my last questions above? Thanks in advance.

Kind regards,
Enrique

[DylanVanAssche]

The first one is if you are planning to remove the maven shade plugin to RMLMapper as well or this is something you are not happy to consider. I hope you don't mind me giving my two cents on the matter. The RMLMapper is a great tool but I would not say it is likely to be a final production artifact, but rather to be streamlined with other software that make use of it as a dependency. In these situations, I would normally be looking for my dependencies not to be shaded, in order to be able to manage other dependencies down the dependency tree. It is, of course up to the owners of the project to decide how they want to ship it, but it would be good for us to know what are your thoughts on the matter

We mostly use RMLMapper as a CLI with a fat jar which is why we include them all. However, if we can streamline the process for others, we are open to patches supporting both use cases.

The second question is related to the fact you mentioned 'dataio' 1.2.0 will be included in RMLMapper soon, and I would like to ask you if there is any estimation of this new release version of RMLMapper would be available. We currently have forked your repos to make these adjustments, but our long term goal is to try to only depend on your released artifacts rather than mantaining our repos.

New RMLMapper version (7.0.0) is being prepared with support for the new RML specification. We cannot give an exact estimation though.

[enriquedelpino]

This is awesome news, I wasn't aware there is a new RML Spec coming out. Is there a chance you can point me to the draft of the new spec so we can assess the impact it will have in to the code produced in our organization.

On the topic of fat jars and CLI, I would say the best way to go would be to create a very small new project just for the CLI too which packages as a fat jar. This is also very beneficial in terms of separation of concerns in the architecture of the mapper.

Is that something you'd be willing to do? We are more than happy to help or even implement this for you guys, as of course, we don't have permissions to your repos, we'd need to have the project created in github to at least be able to issue a pull request to you with these changes, and maybe it'd be a great addition to version 7.0.0

[DylanVanAssche]

This is awesome news, I wasn't aware there is a new RML Spec coming out. Is there a chance you can point me to the draft of the new spec so we can assess the impact it will have in to the code produced in our organization.

The new specification is divided in RML modules. This way, implementations can start implementing the basic parts (RML-Core) which is similar to what we have now for RML. Input/Output with Logical Source and Logical Target resides in RML-IO. FnO data transformations in RML is specified by the RML-FNML module. RDF-Star support in RML-Star, and RDFS Collections and Containers in RML-CC.

You can find all specifications in the RML portal: https://w3id.org/rml/portal

On the topic of fat jars and CLI, I would say the best way to go would be to create a very small new project just for the CLI too which packages as a fat jar. This is also very beneficial in terms of separation of concerns in the architecture of the mapper.

Is that something you'd be willing to do? We are more than happy to help or even implement this for you guys, as of course, we don't have permissions to your repos, we'd need to have the project created in github to at least be able to issue a pull request to you with these changes, and maybe it'd be a great addition to version 7.0.0

We're happy to welcome your changes to the Maven project of the RMLMapper to make it possible for you to only depend on the library. We rather not change the current workflow and repository with fat jars for us. However, feel free to submit a PR which makes it possible to build the RMLMapper without the fat jar depedencies to publish RMLMapper as a new Maven publication called rmlmapper-java-lib. RMLMapper 7.0.0 was just released.

[enriquedelpino]

All these suggested changes were implemented successfully. Thanks all!