Re: [hibernate-dev] Shaded build for the HV annotation processor
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 > 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 > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [HV] Programmatic definition of method level constraints
Hi guys, I'm working on HV-431, http://opensource.atlassian.com/projects/hibernate/browse/HV-431. The aim of this issue is to extend the programmatic API to allow constraints definition on methods in a programmatic way. I've discussed with Hardy about some proposals and I've made a gist to expose the different possibility, look at https://gist.github.com/903302. Comments and new proposals are welcome :) --Kevin ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On vendredi 8 avril 2011 at 13:13, Gunnar Morling wrote: Hi, > > I also like https://gist.github.com/903302#file_1_method_configuration.java > best. As we already decided to accept some breaking changes around > ConstraintDef, I also think it's better to do other breaking changes > now instead of later. > > Just one remark: we need a way to clearly identify overloaded methods. > In addition to ConstraintDef#method(String name) from the proposal > there should be another method like ConstraintDef#method(String name, > Class... parameterTypes). > > The first could be used if only one method with a given name exists, > the latter if several overloaded methods with the same name exist. > > Gunnar Good catch, I haven't seen this case. My thinking is that only ConstraintDef#method(String name, Class... parameterTypes) would suffice (parameterTypes is a varargs and can be empty). --Kevin > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Programmatic definition of method level constraints
On vendredi 8 avril 2011 at 15:54, Emmanuel Bernard wrote: Make sure you write a client of this API, I suspect Class... parameterTypes might not be what you want. > > On 8 avr. 2011, at 13:41, Kevin Pollet wrote: What do you mean ? Have you a tricky/special case in mind ? --Kevin ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HV] Changes to API for programmatic constraint definition
Hi guys, First, sorry for this late response. I think too that there is no solution to keep the single invocation chain and the grouping approach. IMHO, avoid the misuse of the API is more important than keeping the single invocation chain. Regarding https://gist.github.com/940438, I really prefer the last one. ConstraintMapping mapping = new ConstraintMapping(); mapping.type( Marathon.class ) .constraint( ConstraintDef.createGeneric( MarathonConstraint.class ).param( "minRunner", 1 ) ) .property( "name", METHOD ) .constraint( ConstraintDef.create(SizeDef.class).message( "name too short" ).min( 3 ) ) .constraint( ConstraintDef.create(NotNullDef.class ) .property( "numberOfHelpers", FIELD ) .constraint( ConstraintDef.create(MinDef.class).value( 1 ) ); The use of ConstraintDef class as a single entry point for constraint creations unifies how generic and "normal" constraints are created. --Kevin On lundi 2 mai 2011 at 06:03, Hardy Ferentschik wrote: Hi, > > Great summary Gunnar :-) > I also thought about the API for quite some time and could not find > a solution keeping the current "grouping" and the single invocation chain > w/o introducing cases for invalid usages. > Initially I thought about keeping these inconsistencies for the sake > of keeping the current API and throw an exception at runtime, but looking > at your suggestions I think we can offer a solution which is correct w/o > loosing much of the fluent API. > > I like the last version in this gist best - > https://gist.github.com/940438 : > > > ConstraintMapping mapping = new ConstraintMapping(); > mapping.type( Marathon.class ) > .constraint( ConstraintDef.createGeneric( MarathonConstraint.class ) > .param( "minRunner", 1 ) ) > .property( "name", METHOD ) > .constraint( ConstraintDef.create(SizeDef.class).message( "name > too short" ).min( 3 ) ) > .constraint( ConstraintDef.create(NotNullDef.class ) > .property( "numberOfHelpers", FIELD ) > .constraint( ConstraintDef.create(MinDef.class).value( 1 ) ); > > > > Another question is whether we should enforce an order within the > > constraint definitions for one type (e.g. class-level -> properties -> > > method 1 parameters -> method 1 return value -> method 2 ...) or allow > > an arbitrary order here. Personally I don't see the need for such an > > order (we don't require one implementation-wise, and users could > > adhere to one by convention if they want to), but Hardy and Kevin feel > > different about this :) > > I still like the idea, especially since it also differentiates between > standard > Bean Validation validation and the method level validation extension. > > --Hardy > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] thanks contributors
Hi, I'm not sure to be in the best position to suggest something because I'm a contributor :) Hibernate could have it's own nobles like Arquillian (http://www.jboss.org/arquillian/nobles) and each "Hibernate noble" could have a virtual price on his JBoss Community Account (click on one noble to see an example). WDYT? --Kevin Le lundi 27 juin 2011 à 11:28, Sanne Grinovero a écrit : > +1 > Not only to motivate people in contributing, but also to stress yet > again the message that it's not just "us" developing it, but it's > still welcome for everybody to "scratch their own itch" by improving > it. I often experience reasoning about "that something the JBoss > people are paid to do.." (and then complain for something not being > fixed). > > Cheers, > Sanne > > 2011/6/27 Hardy Ferentschik (mailto:ha...@hibernate.org)>: > > On Mon, 27 Jun 2011 11:06:34 +0200, Strong Liu > (mailto:st...@hibernate.org)> wrote: > > > > > i'd prefer to list people who signed CLA and provided patch(es), no > > > matter the size of patch. > > > > Seems to be a reasonable criteria. > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org (mailto:hibernate-dev@lists.jboss.org) > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] MethodLevel Constraints for method level validations
+1 Good idea!! --Kevin Le 8 juil. 2011 à 16:03, Emmanuel Bernard a écrit : > Do you think we should support the following? > > @DateInOrder > void bookHotel(@NotNull @Valid Customer customer, Date from, Date to); > > ie like we have properly level and class level constraints, we could get > method level constraints receiving all the parameters and raising constraints > violations if necessary. > > Emmanuel > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
