On the branch using Gradle for builds I started working on folding together hibernate-core, hibernate-testing and hibernate-testsuite. Gradle makes this very flexible and without further considerations I would simply define a total of 4 sourceSets in the hibernate-core project: 1) src/main 2) src/test 3) src/testing 4) src/intgTest
Gradle would let me define the compilation output directory for each sourceSet and we'd be on our way. But of course we want this easily workable in IDEs. IntelliJ for example would not like the fact that we would need to define a total of 4 different compilation output directories for a single project (what IntelliJ calls module). So we need to find the balance that works best in command line as well as IntelliJ and Eclipse. I've put together a few proposals based on knowing what will work in IntelliJ and talking to Max and Hans. 1) As far as we can tell the above would actually work. In IntelliJ we'd split the project into 2 modules. There was some drawback to this in Eclipse as well though the details escape me atm (max?). 2) Only fold hibernate-testsuite back into hibernate-core and leave hibernate-testing separate. This creates a semi-circular dependency but Gradle and IntelliJ can deal with it because the nature of the deps is limited in such a way that hibernate-testing would depend on classes from hibernate-core and hibernate-core would depend on hibernate-testing for it's test-classes. No clue if this would work in Eclipse. 3) Another thing to consider is whether hibernate-testing still needs to be deployed on it's own. We did this as a convenience so that users could use it in their own project tests. To be honest I have no idea how much use it gets in that way. If the answer here is no then the problem becomes a little simpler in that we could just compile the hibernate-testing classes would just be part of hibernate-core/src/test/java and would get compiled along with the test classes into test-classes. Gradle itself has this set up so we have a template we could easily follow for this approach. Worst case we could use this approach and still build the additional hibernate-testing jar for upload using include/exclude definitions to get the correct classes into the jar. All things considered I think I prefer (2) or (3) as the solution to implement. One concern I had with them that I need to verify works is compiling unit tests and intg tests into the same output directory and whether separate test tasks could really work there. Also I need to decide whether that really matters. Thoughts? -- Sent from my Palm Pre st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
