So I think it really comes down to the answer to 2 questions:
1) Do we care whether src/test and src/intgTest compile into the same
directory? The implication there is that you would effectively not be
able to set up two different test tasks to run unit and integration
tests separately. Not sure this is such a big deal, TBH. See caveat #1
below. Anyway I said effectively because you could do it with
includes/excludes as I mentioned before; but I am not a huge fan of
2) Do we care whether src/testing compiles into the same directory as
where ever we end up compiling src/intgTest? The implication here is
that it is effectively not possible to then create a jar from just those
classes/ See caveat #2 below. Again, I said effectively here because
we can use includes/excludes here as well to achieve.
1) Gradle's build has a similar set up. What they do is to define the 2
sourceSets and have each compile to its own directory. In the IntelliJ
they tell it to use the same directory (a third one) for both.
2) Gradle plans to make sourceSets sensitive to the outputs they
explicitly contributed to the output dirs. Essentially the
includes/excludes become baked into the sourceSets themselves. In fact
Hans said they already know this information today and that it is just a
matter of applying it when you ask the sourceSet for its classes, etc.
On Thu, 2010-06-17 at 08:33 -0500, Steve Ebersole wrote:
No, you define your dependencies in the gradle build files (using for
an ivy syntax afaiu). Gradle will transfer that information to the pom
it *generates* as part of the "upload" (deploy) process.
And, yes, as Hardy mentioned as of the moment you need to do `gradle
idea` from command line to generate the IntelliJ project (ala `mvn
On Thu, 2010-06-17 at 14:52 +0200, Emmanuel Bernard wrote:
> I thought gradle kept the pom dependency information as is but I'm wrong it
> My question is:
> Once checked out of svn, what do I need to do to get the project ready to work in
IntelliJ / Eclipse (lib deps declaration, test config etc)?
> Today, with the pom.xml, it's a two page wizard and I'm good to go,
including running tests and all.
> On 17 juin 2010, at 14:45, Steve Ebersole wrote:
> > 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
> > 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
> >>> 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
> > --
> > Steve Ebersole <steve(a)hibernate.org>
> > http://hibernate.org