> 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. you keep these things in hibernateext, correct ? ..and how much do i need to do to have the same "dependency" check for tools ? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate max(a)hibernate.org http://hibernate.org JBoss a division of Red Hat max.andersen(a)jboss.com

> 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev