Carsten Ziegeler wrote:
Upayavira wrote:
Yup. I'm game. But we need some kind of interim build process don't we?
Hmm, perhaps - my idea is still that if we start separating it, people
will provide an interim build or even better start a real blocks build
system.
A "real blocks build system" is IMO M2 with an OSGi bundle plugin. There
is ongoing work on such a thing on Felix-dev. For the moment we are more
designers than implementers ;) so the progress is rather slow, help
would be appriciated. In the longer term there could be more to the
block build system, but M2 with OSGi bundle support is enough to get going.
...
Also, gump.xml refers to all blocks. Presumably we could have
http://svn.apache.org/repos/asf/cocoon/blocks/gump.xml which points to
all of the gump.xml's for each of our blocks - somewhere we'll have to
tell Gump what we do.
Don't know much about Gump, but if gump is able to use m2 poms, it could
just use them for building all the blocks and we wouldn't need any
gump.xml anymore.
Yes, the Gump process should be driven from POMs. Either by a M2 plugin
that creates gump.xml as in M1 or preferably by making Gump use M2 POMs
directly. Continous integration is a must and will be even more
important when we start to consider the blocks as separate projects.
--- o0o ---
My number one priority is integrating the OSGi stuff with Sylvain's OSGi
aware component handling and the sitemap block functionality I
implemented before. So I will not be able to do more than discussing the
two above points for the nearest future. Both the M2 OSGi bundle plugin
and M2/Gump integration are very important steps on our way towards real
block. So for anyone who can find some spare cycles there is a great
chance to get us much closer to real blocks :)
/Daniel
