[hibernate-dev] New project layer

[Emmanuel Bernard]

With the help of Paolo on commons-annotations refactoring, I came up  
with a decent prototype, here is the structure

jpa-api
   lib (empty)
   compile depends on nothing
   compiletest depends on nothing

commons-annotations
   lib (empty)
   compile depends on commons logging, log4j
   compiletest depends on jpa-api //jpa annotations are used for tests

validator
   lib (empty)
   compile depends on jpa-api, commons-annotations, core
   compiletest depends on annotations //DDL integration, will depend  
on jpa //JPA integration

search
   lib (empty)
   compile depends on commons-annotations, core
   compiletest depends on annotations, validator, jpa-api

annotations
   lib (empty)
   compile depends on jpa-api, validator, commons-annotations, core
     //want to add a dependency to search for ease of use
   compiletest depends on nothing more

jpa
   lib (jboss-archive-browser)
   compile depends on jpa-api, validator, commons-annotations,  
annotations, core
   compiletest depends on nothing more


Dependencies are managed by the building system automatically. The  
way it is done is a hack in the build.xml files (no clean  
encapsulation), but it deals nicely with compilation dependencies vs  
test compilation dependencies: it could be improved by implementing a  
specific ant task. The build looks for the availability of the jar  
dependencies, and if not present clean, jar is called on this  
dependency project
Alternatively, Ivy looks very promising and quite lightweight in the  
way dependencies are handled, so we could use it: no rush though,  
since the job is done and there won't be much dependency changes.

The nice thing about it is that there is no more lib/* duplication  
(most are shared)

I still need to tackle with the dist task and copy the dependency  
libraries instead.

Aside from the build changes:
  - commons-annotations is now independent with no dependencies
  - validator still depend on core (it is actually hard not to), but  
it can work fine without HAN, you can use it with a plain JPA engine.
  - search is independent of HAN, per se but not from core, it could  
be easily though I think and we could support plain JPA engines as well.

A few remaining questions:
  - HAN as an integration project
Should Hibernate Annotations embed search and validator jars, I think  
so as third party jars, it would make the full blend HAN usage  
smoother (like event listener auto configuration)
The idea is to embed a reference version of validator and search in  
HAN with he ability for a user to upgrade validator or search for a  
given HAN version

  - Version number
I am in favor of keeping the version number root 3.2.2. Hibernate  
Search however is still beta, so a different versioning would be  
better 3.2.2.beta1 and so on (3.2.2.beta2 or 3.2.3.beta1).

  - Documentation
Since Validator and Search will be integrated to HAN, should I keep  
the chapters in both the HAN doc and the validator doc?

I plan to apply that sometimes this week (tomorrow hopefully). Once  
I'm done we'll be able to think about the website changes.
Comments welcome before I commit that work.