[hibernate-dev] [HV] Implementing method validation (was "HV-562")

[Gunnar Morling]

Am 10.05.2012 15:01 schrieb "Hardy Ferentschik" <hardy at 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