On Thu, 2010-06-17 at 14:37 +0200, Emmanuel Bernard wrote: > How much manual change is required in the IDE configuration for that? > Assuming we start with a pom.xml import? I do not understand the questions. Do you mean "manual change" to the IntelliJ project after it is created/opened? There is no pom.xml so how would we start with it for an 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 > > st...@hibernate.org > > http://hibernate.org > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
