[hibernate-dev] Project layout

[Steve Ebersole]

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
that.

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.

Caveats:
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 of
> 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
> idea:idea`).
> 
> 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 seems :)
> > 
> > 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 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
> > >>> steve at hibernate.org
> > >>> http://hibernate.org
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> 
> > > 
> > > -- 
> > > Steve Ebersole <steve at hibernate.org>
> > > http://hibernate.org
> > > 
> > 
> 

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org