I opt for class filtering. We can fold testing back into src/test. As you are saying we can then create an additional testing jar using class in- and excludes. I've done this before in another project using ant and it worked just fine. Of course a true conventionalist will crucify me for that.
--Hardy On Thu, 17 Jun 2010 14:28:25 +0200, Steve Ebersole <st...@hibernate.org> wrote: > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
