Re: [hibernate-dev] Project layout

How much manual change is required in the IDE configuration for that? Assuming we start with a pom.xml import?

On 17 juin 2010, at 14:28, Steve Ebersole 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 > steve(a)hibernate.org > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev