Thanks for the clarification, thing is that we may need mongo model in
alpha 2 too because of liveoak.
So for now I did not made any big refactoring and movement of existing
manager classes. I just introduced new module "model/tests" and moved
just existing model related unit tests (basically everything except
EmailSenderTest) from "services" module to this one. Then I configured
model/jpa and model/mongo modules to use tests from this one. So
currently all these model unit tests are always executed during build of
particular model implementation (ie. building model/jpa runs all tests
with "jpa" model implementation and building model/mongo runs all tests
with "mongo" model implementation).
So only thing moved to different location are those unit tests classes.
Is this acceptable change for Alpha 2?
With this change, if you decide to enable/disable some model
implementation, you will need just comment/uncomment one line in
model/pom.xml and that's it. Side-effect of this is that many
test-scoped dependencies from "services" module are not needed anymore
(especially hibernate and H2, which were needed for "jpa" model)
Testsuite is executed just with JPA model by default, there is separate
profile for running it with mongo, which is used only if you add
-Dkeycloak.model=mongo .
Hope to send PR with mongo model later today or early tomorrow with this
change introduced.
Thanks,
Marek
On 10.2.2014 23:50, Bill Burke wrote:
On 2/10/2014 4:51 PM, Marek Posolda wrote:
> I prefer 1 but it's more work and more required changes of current
> project structure. wdyt?
>
I agree. I thought that was the plan even before this email. That we
needed restructuring of the codebase to separate JAX-RS code from
business logic, from model logic. That we needed more comprehensive
testing.
Minimally, to do this work we have to wait until after Alpha 2 (end of
this week). But my preference is that there is no refactoring work at
all until we're done with core feature implementations or unless a
feature needs the refactoring. I just don't want merge conflicts
distracting people from feature work. Stan took awhile to merge his
keycloak subsystem because our code was a moving target. I've had
delays before because of merge conflicts as well.
My thought is that we will have a few more Alphas every 2-3 weeks.
Going into Beta will mean that our major features have been
implemented and we'll then start focusing on test coverage,
refactoring, cleaning up code, documentation, and polishing the project.
But, Stian can be the tie-breaker here if he wants this refactoring to
happen sooner rather than later. I'll go with what he wants.