[hibernate-dev] Project layout

Steve Ebersole steve at hibernate.org
Thu Jun 17 13:53:29 EDT 2010


To me it has nothing to do with convention.  My concern is the
maintenance of that.  We have this issue somewhat today as well in the
Maven build with building release bundles.  Its a matter of remembering
to add/subtract from these include/exclude lists.  For example, today
the includes for testing would look like:
org/hibernate/junit/**
org/hibernate/test/annotations/**
org/hibernate/test/cache/**
org/hibernate/test/tm/**

(lets forget the "org/hibernate/test/annotations/**" pattern and the
fact that we also want to merge hibernate-annotations and its test suite
using this package in here as well for the moment).

What happens when we want to add a unit test for some cache related
class and we use the org.hibernate.test.cache package for the test too?
What happens when we want to add some testing support classes related to
in container testing with arquillian and add a new
org.hibernate.test.arquillian package in src/testing/java?  Who gets to
remember these and update them accordingly?

I am just being very honest about my memory.  It sucks and I guarantee I
will forget to update these includes/excludes appropriately.  In my
opinion I use a build tool so that I don't have to remember these little
details.

On Thu, 2010-06-17 at 14:43 +0200, Hardy Ferentschik wrote:
> I opt for class filtering. We can fold testing back into src/test.
> As you are saying we can then create an additional testing jar using class  
> in- and excludes.
> I've done this before in another project using ant and it worked just fine.
> Of course a true conventionalist will crucify me for that.
> 
> --Hardy
> 
> On Thu, 17 Jun 2010 14:28:25 +0200, Steve Ebersole <steve at hibernate.org>  
> wrote:
> 
> > On the branch using Gradle for builds I started working on folding  
> > together hibernate-core, hibernate-testing and hibernate-testsuite.  
> > &nbsp;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. &nbsp;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). &nbsp;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. &nbsp;In  
> > IntelliJ we'd split the project into 2 modules. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;We did this as a convenience so that  
> > users could use it in their own project tests. &nbsp;To be honest I have  
> > no idea how much use it gets in that way. &nbsp;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. &nbsp;Gradle itself has this set up so we  
> > have a template we could easily follow for this approach. &nbsp;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. &nbsp;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. &nbsp;Also I  
> > need to decide whether that really matters. &nbsp;
> >
> > 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




More information about the hibernate-dev mailing list