Nicola Ken Barozzi wrote:
And the dependency is very minimal. It's just a dependency against the
avalon framework api version 4.1.5 - a released version. There is no need in following the development of Avalon.
The issue is not so technical as it's of indipendence from something that, in the good and the bad, has not helped Cocoon be built by Gump for ages now.
avalon-framework very rarely doesn't get built by gump. It's the ECM dependency that's causing the ripples, and the big set of dependencies ECM has itself.
Since it seems ECM is being put into the freezer anyway, just be pragmatic and make the gump build of cocoon depend on an installed package or some jars in cvs. It's not like ECM has changed a lot over the last 2 years.
(...)
I just read up on this thread when someone pointed me at it. What I don't understand is what you think will be so difficult. By now there's half a dozen examples of containers and/or microkernels out there that can be easily made to run your typical avalon-style cocoon component.
Just to drive that point home, here's some tests from my own pet project:
http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/platform/container-integration/src/test/org/jicarilla/container/test/integration/avalon/
if I can figure out how to do this all on my own, surely the cocoon community will have no trouble whatsoever attaining interoperability between "new-style" and "old-style" blocks you need.
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ Component Community -- http://componentplanet.org/ Component Glue -- http://jicarilla.org/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
