repoinit module naming + exported classes (was: [VOTE] Release o.a.s.repoinit.parser 1.0.0 and o.a.s.repoinit.oak.jcr 1.0.0)

[Bertrand Delacretaz <bd...@apache.org>]

Hi Oliver,

Thanks for your feedback!

On Thu, Jun 23, 2016 at 11:38 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> ...o.a.s.repoinit.oak.jcr should not contain oak but jackrabbit in its name (no
> Oak API used)...

I was not planning to test that module with Jackrabbit, hence the -oak
naming suffix, to avoid setting wrong expectations.

Does that work for you, or do you need it for Jackrabbit?

> ...Why are JcrRepoInitOpVisitor and RepositoryInitializer public? Shouldn't they
> live in impl (internal) also?...

You're right, I overlooked this. That warrants a new release to avoid
future backwards compatibility issues

> ...The package webconsole and resources seem to be obsolete and should be
> removed...

Good catch, thanks! I'll clean that up.

-Bertrand

Re: repoinit module naming + exported classes (was: [VOTE] Release o.a.s.repoinit.parser 1.0.0 and o.a.s.repoinit.oak.jcr 1.0.0)

[Oliver Lietz <ap...@oliverlietz.de>]

On Friday 24 June 2016 14:16:30 Bertrand Delacretaz wrote:
> Hi Oliver,

Hi Bertrand,

> Thanks for your feedback!
> 
> On Thu, Jun 23, 2016 at 11:38 AM, Oliver Lietz <ap...@oliverlietz.de> 
wrote:
> > ...o.a.s.repoinit.oak.jcr should not contain oak but jackrabbit in its
> > name (no Oak API used)...
> 
> I was not planning to test that module with Jackrabbit, hence the -oak
> naming suffix, to avoid setting wrong expectations.
> 
> Does that work for you, or do you need it for Jackrabbit?

it will not work with the (latest) Jackrabbit implementation:
UserManager#createSystemUser(String, String):User is not _yet_ implemented.

So I get your point (and we already stated to not support Jackrabbit impl any 
longer anyway) and we could rename the module later if it will work on 
Jackrabbit ever. As we keep JCR stuff under o.a.s.jcr an alternative name is 
o.a.s.jcr.repoinit (instead of grouping both modules under repoinit). Keeping 
the API clean (next point) is much more important though.

Regards,
O.

> > ...Why are JcrRepoInitOpVisitor and RepositoryInitializer public?
> > Shouldn't they live in impl (internal) also?...
> 
> You're right, I overlooked this. That warrants a new release to avoid
> future backwards compatibility issues
> 
> > ...The package webconsole and resources seem to be obsolete and should be
> > removed...
> 
> Good catch, thanks! I'll clean that up.
> 
> -Bertrand