We already have internal discussions about utilizing spring-data in OASP. Currently we have a module oasp4j-jpa for JPA related stuff. So far we already separated oasp4j-jpa-envers. However, oasp4j-jpa contains both JPA fundamental code (what is going to improve and grow with currently upcoming PRs such as #617) as well as DAO infrastructure.
Now, if someone wants to go for spring-data he would still have the DAO infrastructure on his classpath. I see two options:
leave it like this and close this issue as wontfix
create a new module (e.g. oasp4j-jpa-dao) and move the DAO stuff to that module (depending on oasp4j-jpa and oasp4j-jpa-envers depending on oasp4j-jpa-dao). The result would be more clean regarding our "opt in/out" strategy and the impact for upgrading projects would be that they have to replace oasp4j-jpa dependency with oasp4j-jpa-dao (except they already depend on oasp4j-jpa-envers) as otherwise they will get compile errors if they are using DAOs.
hohwille
commented
6 years ago
We already have internal discussions about utilizing spring-data in OASP. Currently we have a module
oasp4j-jpafor JPA related stuff. So far we already separatedoasp4j-jpa-envers. However,oasp4j-jpacontains both JPA fundamental code (what is going to improve and grow with currently upcoming PRs such as #617) as well as DAO infrastructure. Now, if someone wants to go for spring-data he would still have the DAO infrastructure on his classpath. I see two options:oasp4j-jpa-dao) and move the DAO stuff to that module (depending onoasp4j-jpaandoasp4j-jpa-enversdepending onoasp4j-jpa-dao). The result would be more clean regarding our "opt in/out" strategy and the impact for upgrading projects would be that they have to replaceoasp4j-jpadependency withoasp4j-jpa-dao(except they already depend onoasp4j-jpa-envers) as otherwise they will get compile errors if they are using DAOs.