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