Hi guys, I just played around with the Hibernate Validator AP in my IDE, and it's really awesome to see all these constraint checks in action. There is just one thing which I think we can improve: right now the user has to to add three different JARs to the annotation processor path: * the AP itself * validation-api.jar (some types such as @Valid are imported in the AP) * and also hibernate-validator.jar (due to HV-436 and in the future HV-270 where types from HV core are used in the AP). I think that's pretty cumbersome for the users, so I thought about shading HV core and the validation API into the AP JAR. That way only one single JAR must be put onto the AP class path. I'm generally no big fan of uber-jars, but I think in this special case this makes sense pretty much.

Hi guys, I've made an AP shaded jar and played with it in Eclipse, Netbeans and IntelliJ (it seems that all works fine :) I've also opened an issue HV-457 ( http://opensource.atlassian.com/projects/hibernate/browse/HV-457) and If you want to try this approach I've created a topic branch with the maven configuration ( https://github.com/kevinpollet/hibernate-validator/commits/HV-457) -- Kevin On samedi 19 mars 2011 at 13:11, Hardy Ferentschik wrote: On Sat, 19 Mar 2011 12:10:11 +0100, Gunnar Morling <gunnar.morling(a)googlemail.com&gt; wrote: Hi guys, I just played around with the Hibernate Validator AP in my IDE, and it's really awesome to see all these constraint checks in action. There is just one thing which I think we can improve: right now the user has to to add three different JARs to the annotation processor path: * the AP itself * validation-api.jar (some types such as @Valid are imported in the AP) * and also hibernate-validator.jar (due to HV-436 and in the future HV-270 where types from HV core are used in the AP). I think that's pretty cumbersome for the users, so I thought about shading HV core and the validation API into the AP JAR. That way only one single JAR must be put onto the AP class path. I'm generally no big fan of uber-jars, but I think in this special case this makes sense pretty much. I think this is an idea worth exploring. I am not big fan of shading either (even though we already do it in HV itself ;-)), but as you say in this case it makes sense and makes the setup easier. Could that have any implication with the classpath seup? Could there be conflicts? AFAIU the AP classpath is separated from the app classpath (at least it should be). Probably worth testing with at least Eclipse and Idea. Speaking of shading, this could be an easy solution for METAGEN-53 as well. Let's explore this idea. --Hardy

> Speaking of shading, this could be an easy solution for METAGEN-53 as > well. > For metagen-53 I recall that the only dependency is class name lookup which could just as easily be replaced with strings to avoid the multijar setup.

Maybe the same goes for validator annotation processor ?