Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
...
blockx + core - the real block
+ webapp - required webapp part like configuration etc.)
+ samples - the samples
Factoring out the samples is good but I don't understand the split into
core and samples, care to explain?
Sure, core is perhaps a misleading nome, it's the java code, or perhaps
we have like Ralph suggested:
blockx - api
- impl
- test
- webapp
- samples
While I agree in principle we must understand that this will create
around 250 blocks, which require very regular structure and scripted
update and maintainance operations. While we might get problems with
circular dependencies, that must be solved with split in api and impl
when we split core I don't think there are any such problems for the
current blocks. So we can take one step at a time.
Also we should take, at least to some degree, take real blocks and OSGi
into account.In OSGi bundles you describe what is the api by exporting
the api packages in the manifest. Non exported packages are then
implici´tely regarded as implementation. For unit tests I'm not certain
what is the best solution, if one put the test into a separate bundle,
the implementation bundle must export all packages that are tested. So
probably it is better to put the unit tests in the implementation
bundle, it can still be in a separtate directory hierarchy and jar if we
want to. For the webapp stuff, I assume that you mean such things that
we are going to put in COB-INF/block.xml.
Now, we don't have to take all future requirements into account, it is
of course better to do something that works now and modify it when
needed. My main message, I guess, is that we shouldn't do splits like
the one suggested above, until we know that we need it.
Splitting up the current code base into a structure like this is just
moving directories and files. So that's really easy.
I think we should then write a little m2 plugin that deploys a block
into a build webapp:
- jars are copied to WEB-INF/lib
- configuration to WEB-INF/xconf
- other resources are copied as well
- new sitemap components are added to the main sitemap
Can't this be handled by wildcard inclusion from component
configurations in some catalog, so that we get rid of the snippet
insertions.
Currently we only need patching the main sitemap and the web.xml - we
can't do anything about web.xml for some stuff. 2.2 can read it's
configuration from property files instead of parameters in web.xml, so
we can remove most from web.xml.
We can use wildcard inclusion in the main sitemap as well.
Good.
Anyway, if we split up the core into several parts,
this will break the Ant build script. Of course we could now change the
ant script as well, but that's imho
to much energy put at the wrong place.
What about starting to get the blocks compiling with m2 before starting
to split the core, then we minimaize the time when not the complete
Cocoon compile.
I think compiling a block with m2 is not a problem at all, just define a
pom with all dependencies and invoke "m2 install" :) Now, it would be
great if someone would start adding poms with dependencies to the blocks...
Ok, get the message ;)
Some thinking and planning is IMO needed though. We allready have all
(or most) dependency info for blocks in gump.xml. Keeping a global
gump.xml and block local POMs in synch doesn't sound like that much fun.
So, could we move the block parts of the global gump.xml into the
blocks, so that we have the POMs and gump.xml at the same place. Or
better, can we generate the gump.xml from the POMs. Or even better, is
there some integration between gump and Maven, so that Gump can use the
POMs?
/Daniel
