Hi all, I am currently working on https://issues.apache.org/jira/browse/SYNCOPE-241 .
I succeeded in moving the production classes for the persistence layer to a separate module. One interesting last problem I solved there was that spring did not auto detect the entities. I found that the peristence.xml has to be in the same jar as the entities. Only then will spring correctly detect the classes. When trying to also move the persistence tests into the persistence module I faced a lot of problems as our current build only works when the tests are in one module. (See below). I do not see a good way to move the persistence tests right now. With some bigger changes in the way syncope builds and tests this may be possible but it would be to big for me to tackle at the moment. So I see two alternatives: 1. Keep persistence inside core but try to keep it as a separate architectural layer. This would mean to avoid cycles between persistence and the rest of core "by hand". 2. Only move the persistence classes to the persistence module but not the tests. I created a patch for this in the issue above. I personally prefer option 2. While it would be better to have the tests in persistence too it is a good step in the right direction and already has some benefits: - It is impossible to accidently create new dependencies from persistence classes to other parts of core. So persistence is guaranteed to be a inner core of syncope that can be understood on its own - The jpa enhancement happens in persistence. So when you work at core you can leave the persistence project closed and this way eclipse will not accidently overwrite the enhanced classes with the original classes and make your tests fail So what do you guys think about this? Christian ---- The problems I faced: - Persistence test as well as the other core tests have to support a wide range of databases. So this results in a lot of duplication between the poms of core and persistence - The tests require a lot of test resources that are partly changed during the build depending on the profile. So this could also lead to a lot of duplication - I tried to move the test resources into a separate test-resources project. There these resources would then be in src/main/resources to go into the jar to be available to core and persistence. This separate project alone is already a bit ugly. Additionally we have some resources like persistence.properties also in src/main/resources of core. The current tests rely on the fact that src/test/resources override src/main/resources. With a separate test-resources project this does not work anymore.
