Remove dnet-openaireplus-mapping-utils dependency

[marekhorst]

After abandoning an old protocol buffer model and shifting towards new oaf dhp model (#1045 and #1051) we could get rid of some of the dnet dependencies revolving around the old model.

This was partially done by removing dnet-openaire-data-protos explicitly defined as direct dependency which came back as transitive one because of dnet-openaireplus-mapping-utils dependency which seems also to be mostly related to the old protobuf model.

We should get rid of dnet-openaireplus-mapping-utils dependency which will result in dropping several other unwanted dependencies such as dnet-openaire-data-protos and dnet-pace-core including pretty long external dependency tail.

After inspecting IIS source code I have found two groups of references to classes from dnet-openaireplus-mapping-utils:

• eu.dnetlib.data.transform.xmlAbstractDNetXsltFunctions.md5() in several places within exporter module
• eu.dnetlib.openaire.exporter.model.ProjectDetail in projects importer module relying on RESTful streaming endpoint

The first one should be quite easily replaceable while the second one might require additional effort because it is used to deserialize JSON records obtained from projects streaming endpoint.

[marekhorst]

After inspecting IIS source code I have found two groups of references to classes from dnet-openaireplus-mapping-utils:

• eu.dnetlib.data.transform.xmlAbstractDNetXsltFunctions.md5() in several places within exporter module
• eu.dnetlib.openaire.exporter.model.ProjectDetail in projects importer module relying on RESTful streaming endpoint

The first one should be quite easily replaceable while the second one might require additional effort because it is used to deserialize JSON records obtained from projects streaming endpoint.

@claudioatzori do you also see the dnet-openaireplus-mapping-utils as something we could get rid of while abandoning an old protobuf Oaf model? If this is the case do you plan to move e.g. projects streaming endpoint model (mentioned above) to some other module? I know you have plenty to do so if you come to any kind of refactoring in near future just keep my note in your mind :)

[dnet-team]

The ProjectDetail bean can probably be moved in the dhp-schema module; It is already the IIS reference module for the recent D-Net common model definitions, so it could be the target of a simple refactoring. I only need to check which other model classes could be moved there. I will give you a note as soon as I manage to progress on this front.

[claudioatzori]

The ProjectDetail bean can probably be moved in the dhp-schema module; It is already the IIS reference module for the recent D-Net common model definitions, so it could be the target of a simple refactoring. I only need to check which other model classes could be moved there. I will give you a note as soon as I manage to progress on this front.

Typical account/login confusion :)

[przemyslawjacewicz]

I've managed to remove dnet-openaireplus-mapping-utils dependency

• ProjectDetail bean was pretty simple so I've cloned it in IIS, taking only the needed functionalities
• AbstractDNetXsltFunctions.md5() was replaced by Apache Commons DigestUtils.md5Hex()
• there was also AbstractDNetXsltFunctions.oafId() used in IIS - the method was pretty simple so I've also cloned it to IIS with minor improvements