3:31 a.m.
Am 10.05.2012 15:01 schrieb "Hardy Ferentschik" <hardy(a)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
6:13 a.m.
New subject: [HV] Implementing method validation (was "HV-562")
On May 11, 2012, at 9:31 AM, Gunnar Morling wrote:
> 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.
Fair enough. I don't think that there will be many other things coming up while we fix
HV-571, but it is probably better to have this branch until all tests pass again. HV-571
has highest priority atm.
I pushed my HV-571 branch to https://github.com/hibernate/hibernate-validator/tree/HV-571.
We can share this branch for the work
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.?
In ORM we have https://github.com/hibernate/hibernate-orm/tree/metamodel for the metamodel
work. So we do the same thing there.
+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?
+1 That was our plan to begin with and also one of the reason why we have a version jump
from 4 to 5 now.
--Hardy
4460
days inactive
4460
days old
1 comments
2 participants
participants (2)
-
Gunnar Morling -
Hardy Ferentschik