Hi, >From my perspective, we can stop activities related to SYNCOPE-241 with option >(1) for now. I find refactoring already made by Christian very useful and >important.
In perspective, let see if we will have some real requirements resulting to split core module, for example: - alternative persistence implementation (Hybernate, EclipseLink, etc); - clean OSGi design (but on the first step by OSGi support core can still stay monolithic); - alternative remote access (no REST based); - etc As soon as such requirements are accepted, let resolve the problems mentioned by Christian and split core module including the tests. I think it will be not artificial, but more requirements and features driven approach. Regards, Andrei. > -----Original Message----- > From: Christian Schneider [mailto:[email protected]] On Behalf Of > Christian Schneider > Sent: Dienstag, 15. Januar 2013 15:59 > To: [email protected] > Subject: Discussion: Persistence module without tests > > 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.
