[hibernate-dev] New project layer

[Max Rydahl Andersen]

> validator
>    lib (empty)
>    compile depends on jpa-api, commons-annotations, core
>    compiletest depends on annotations //DDL integration, will depend on  
> jpa //JPA integration
>
> 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

I did not notice this until I actually tried to put this into eclipse.

You have a dependency cycle here - annotations needs validator, but
validator
(it's tests at least) cannot be compiled without annotations...

I can probably solve this by putting a compiled annotations on the
classpath of validator
but that is so yucky! :(

/max


> 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.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com