I've commited mc-integration into trunk.
Once kernel is released I have to commit packager changes into trunk, and
when packager is released (Beta03) the portal changes ...
Cheers,
- marko
On Fri, Dec 11, 2009 at 12:13 PM, Marko Strukelj
<marko.strukelj(a)gmail.com>wrote:
I think mc-integration is now ready for trunk.
I removed AOP support, and added support for externally configuring DI
injection points.
MC integration is loosely coupled into container module, which has no
additional build dependencies.
The pluggability classes are few, they are part of container module, and I
had no need to do any change on them for quite a while so they are stable.
I reorganized mc-integration implementation related modules under one
parent - mc-integration, and at the moment put it under its own versioning
cycle. This has some implications for the way release would be performed.
The way I organized things makes most sense to me.
- It is out of the way from the rest of the kernel, as it is not
'polluting' kernel-parent pom with its dependencies - it's got them in its
own mc-integration parent.
- Any bug-fixes can be released without releasing the kernel itself.
- Code can even be completely moved out of the kernel project into
gatein/components. It's really a jbossas specific add-on to exo-kernel so it
makes sense to move it out.
If we keep it as part of kernel I'll put back versioning to be in sync with
kernel version. I hope that otherwise the structure doesn't present problems
for current release procedure.
If we move mc-integration to gatein/components, then it is versioned
separately and released as any other module.
What do you think?
- marko