Re: registry construction api (again...)

[Knut Wannheden <kn...@gmail.com>]

Hi Achim,

On 10/31/06, Achim Hügen <ac...@gmx.de> wrote:
>
> The 2.0 branch now contains a stable implementation
> of hivemind that bases on a registry construction api.
> It compiles, it builds, all test of all modules run successful.
> I was able to port tapestry 4.1 to this version (and run the workbench
> example)
> with about 15 minutes of work (not talking about the 6 hours struggling
> with maven 2) and 30 lines of code changes.
> So it should to be backward compatible for a lot of applications.
>

I think the main theme for backward compatibility is keeping the XML
module descriptors backward compatible. I believe this should be
fairly simple and from what I understand (since all tests run) your
HiveMind 2.0 branch already satisfies this.

> I would like to propose my implementation of the registry construction api
> as foundation for hivemind 2.0. It's not exactly what Knut suggested on
> the wiki but very similar (we should discuss details in a separate thread).
>

I will take a closer look at it and post a message with any comments /
questions I have.

> On top of the registry construction api I've implemented support for
> annotated
> modules (http://wiki.apache.org/jakarta-hivemind/AnnotationSupport).
> The implementation is quite basic for now but was very simple,
> which I see as proof of concept for the registry construction api.
>

Excellent! Can you point us to some examples of how it's used?

> IMHO we shouldn't implement the API for 1.2. I suspect it won't get 100%
> backward compatible at all and I personally are a little bit tired of
> these conversion work. I invested about 150 hours in the API and in
> the moment I'm quite eager on doing new stuff (annotations, generics!).
> And of course there is a lot of documentation that still needs to be done.
> I don't see a lot of use cases for the direct use of the API. I expect
> anybody who is willing to use the API to switch to 2.0.
>

If we can keep HiveMind 2.0 backward compatible (definition follows)
then I agree that we don't need a 1.2 release with the registry
construction API. But if we're going to introduce other bigger
backwards incompatible changes to HiveMind 2.0 (such as requiring a
Java 1.5 JRE) then I'd opt for also implementing the registry
construction API for HiveMind 1.2.

IMO backwards compatibility should be defined as supporting any
currently (HiveMind 1.1) supported XML module descriptors. This
includes:

 - support for custom service and interceptor implementation factories
 - compatibility with any of the user code Java classes (e.g. service
interfaces and service implementation classes) referenced from the XML
module descriptor
 - maintaining support for all public service and interceptor
implementation factories exposed by HiveMind modules
 - maintaining support for contributions (using schemas) made to
public configuration points exposed by HiveMind modules

On the other hand I don't think we necessarily need to remain
backwards compatible in other areas. E.g. usages of the
RegistryBuilder and ModuleDescriptorProvider classes.

What do you think?

> Possible road map for 2.0:
>
> 2.0 M1 (End of November)
> - Stable version of the construction API (agreed on by the core developers)
> - Annotated modules API preview
> - small migration guide for beta testers
>
> 2.0 M2 (December)
> - Stable version of annotated modules API
> - documentation for registry construction API
> - documentation for annotated modules
> - redesigned interceptor support, commons proxy?
>
> 2.0 RC 1 (January)
> - complete documentation
> - Merge of changes from 1.2 branch
>
> 2.1
> - More advanced annotation stuff like annotations for injection in
> arbitrary classes (InjectService, InjectConfiguration ...), parameter
> injection etc.
> - Spring module support
>
> What do you think?
>

Sounds good. Although somewhat tight ;-)

Achim, before I dig too deep into your code it would be great if you
could give a more detailed overview of what changes you've made in the
branch. For instance I remember seeing new concepts like a constructor
for configuration containers and "natures". Is there more? Can you
provide some details on that?

Regards,

--knut