Am 10.05.2012 15:01 schrieb "Hardy Ferentschik" <ha...@hibernate.org>: > > > > nice post on the release, this should get started everyone with 4.3. > > And we can finally focus on HV 5 :) > > thanks :-) > > > > >>> I'm looking forward to implementing the new API, this should be > >>> fun :) I feel that it should be possible to split the work into > >>> independent chunks which we can tackle in parallel. > >> > >> That sounds good. In a first cut we might be able to just try to compile the latest BV SNAPSHOT and introduce the missing > >> methods by introducing placeholders. Once the existing build passes again we can already push a SNAPSHOT and start > >> filling in the gaps. > > > > I've created a branch for method validation [1], bumped the dependency > > to the BV API to 1.1.Alpha1 and applied the minimal changes required > > to get rid of any compilation errors (added > > UnsupportedOperationExceptions within the new methods). I've also > > added "TODO HV-571" markers everywhere, so we can't forget everything > > :) > > Awesome. I was planning to do this, but since you already got started … :-) > Personally I don't like working on branches. Instead I would like to continue working on master. > I took your branch and used the TestNG suite files to exclude the failing tests in > engine and tck-runner. Have a look at https://github.com/hferentschik/hibernate-validator/commits/HV-571
That looks good. Quite a number of tests which are concerned :) > > What do you think about pushing this to master. As we develop the missing features we just > re-enable things. So far we've always developed new features on individual branches (within our forked repos) and had them pulled into master afterwards. That way master was always relatively stable and had a good quality. This would change if we integrate individual changes of the method validation work into master. IMO this wouldn't be a problem per se, as long as we only work on HV-571. But we might get problems if we decide to work on further, unrelated issues in parallel. For instance we wouldn't recognize that such a change causes one of the tests disabled for HV-571 to fail. I think the new situation is that more than one person is working on the same feature. Have there been similar cases in Search etc.? How was it handled there? Personally I think a HV-571 feature branch in the master repo would be a good thing to integrate and stabilize our work, leaving the opportunity to work on other things as well, should that need arise. Also it shouldn't necessarily be more complex than pushing to master (at least as long as there isn't too much other traffic on master). > > > Regarding the actual implementation, I think there are two large > > blocks, which might be addressed in parallel: a) implementing the new > > validation methods and b) implementing the extensions to the meta data > > API (plus some other things such as changes to ConfigurationImpl > > etc.). > > +1 I could for example look into some some the metadata stuff. But in the end I would leave it > to you to take whatever you like. Sounds good to me, then I'll start with the validation methods. > I will then take the slack. Let's just > make sure we are in sync what we are doing. +1. I think I'll start tomorrow. Regarding the current proprietary API, I see no way we can keep it, as for instance there are methods in the BV API with same names but with different return types. So I think we should remove it completely. WDYT? > > --Hardy > --Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
