search

openminted / omtd-registry-api

Other
0 stars 0 forks source link

Separate modules for domain model #2

Open reckart opened 7 years ago

reckart commented 7 years ago

Currently, the omtd-registry-api contains a JAXB version of the OMTD-SHARE domain model as well as some interfaces. These interfaces seem to have a pretty large dependency footprint, i.e. they draw in the whole of ElasticSearch.

It would be nice if the OMTD-SHARE domain model would be in a separate artifact with out such a large dependency footprint.

reckart commented 7 years ago

Actually, separate Maven artifacts for each part (i.e. XSD) of the OMTD-SHARE schema would be even nicer.

And also if the Java classes for the different XSDs would be in separate Java packages.

courado commented 7 years ago

Currently, the omtd-registry-api contains a JAXB version of the OMTD-SHARE domain model as well as some interfaces. These interfaces seem to have a pretty large dependency footprint, i.e. they draw in the whole of ElasticSearch.

Indeed the elastic search is getting imported from registry-core-api, I will exclude it and see if the dependency is needed anyways and/or remove it.

Actually, separate Maven artifacts for each part (i.e. XSD) of the OMTD-SHARE schema would be even nicer.

I disagree, the footprint without the elasticsearch is not going to be big, and the amount of effort to automate the class generation, especially in different packages will waste a lot of time for every change of the model (which requires quite a bit of manual work every time).

And also if the Java classes for the different XSDs would be in separate Java packages.

What will the packages be ?

  1. Package name for every xsd filename ?
  2. Package name for type of resource plus common classes ?

That doesn't sound bad, but I have to see how easy it easy to automate and xjc is not the friendliest tool for these kinds of modifications.

reckart commented 7 years ago

Excludes can make the Maven dependency resolution work in unexpected ways. I would recommend strongly against that.

It should be possible to automatize the generation of the classes using the JAXB maven plugin - I expect that actually only the XSDs must be in the repo and the Java sources do not need to be in the repo as they can be automatically generated from the XSDs during the build.

courado commented 7 years ago

It should be possible to automatize the generation of the classes using the JAXB maven plugin - I expect that actually only the XSDs must be in the repo and the Java sources do not need to be in the repo as they can be automatically generated from the XSDs during the build.

It is in the latest snapshot version, but again XJC I repeat is not friendly, especially for multi xsd files with dependencies and still, the auto-generation has many flaws and a lot of effort goes in generating intermediate schemas.

reckart commented 7 years ago

Could that be fixed by maintaining the original XSDs in a different way to start with?