[hibernate-dev] Project layout

[Hardy Ferentschik]

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