oasp4j-jpa compatiblity for DAO with paging support

[vapadwal]

Please find the PR for issue https://github.com/oasp/oasp4j/issues/669

[vapadwal]

Please also see mtsj PR https://github.com/oasp/my-thai-star/pull/128

[hohwille]

Here is my design suggestion. Indeed quite complicated. However, when removing/ignoring the deprecated legacy stuff, the official things do not get any more complex. And this way we avoid namespace clashing when multiple oasp4j JARs come together on the classpath. Please note comments below. I do not have time to rework the entire diagram. Sorry.

IMPORTANT: I just realized that the DAO interfaces actually do not differ between the new and the legacy world. Therefore we IMHO should not duplicate them. Maybe then the package separation (adding dao subpackage in the new world) does not make much sense. It might then be better to change the Abstract*Dao names in the new world so the legacy world can keep the existing names. My first guess would be to add some Impl suffix to the new world ( e.g. AbstractGenericDaoImpl).

The important requirement is that:

• existing projects depending on oasp4j-jpa or oasp4j-jpa-envers can still compile their code without API changes (no matter if classes are moved keeping the namespace to new modules that are transitive dependencies).
• (new) projects can get rid of the legacy modules (oasp4j-jpa or oasp4j-jpa-envers) and move to only the new ones (oasp4j-jpa-dao) and will not see any deprecated code anymore. This however would imply for existing projects that they have to migrate their code (e.g. extends directly AbstractGenericDaoImpl instead of AbstractGenericDao).

[vapadwal]

Regarding renaming Dao interfaces in oasp-jpa-dao and oasp-jpa-dao-envers had prefix "I" and Dao abstract class have put suffix "Impl"

[hohwille]

Regarding renaming Dao interfaces in oasp-jpa-dao and oasp-jpa-dao-envers had prefix "I"

https://github.com/oasp/oasp4j/wiki/coding-conventions#naming

Did you read the IMPORTANT: note? IMHO there is no need to duplicate the interfaces. Also the Envers-Classes are not DAO specific and should IMHO not have been moved to a dao specific module. What if someone wants to use envers with oasp4j-jpa-spring-data instead? Then he would also have to depend on oasp4j-jpa-dao-envers what does not make sense to me.

[hohwille]

As we are running out of time I will try to create another PR and give it a try. Then we can match and compare, discuss, pick and choose. It seems to complicated to express all in words without misunderstandings (and between the few time slots I do have).

[hohwille]

Community voted for #675 so I am closing this PR.