I think the proposal makes sense, but before we get into too many
details about how to reorganize the code I think it would be good to
make sure we agree on the general approach of how these 2 pieces of
functionality should interact with each other.
At a high level I would expect that each component (weblogger and
planet) should be packaged separately like you said, and neither
component should have any direct knowledge about the other. I think
this is pretty much expected for modularization.
At a slightly lower level I think that means that each component should
only have code/configs that know how to run itself. Meaning that they
can't share any db tables, they can't share any config files, and they
can't share any code (aside from explicit utils/interfaces which are
meant to be shared).
Now, getting to the specifics of how you broke things down in the
proposal. I would like to see a little more detail about what things
you think belong in the "core" module. You have quite a bit of stuff
listed under "core" which I'm not sure really works.
For example, you have all the user management listed under core, but I
don't think that weblogger and planet should have to share the same user
management code. what if someone wants to deploy both weblogger and
planet in the same database but not have them share users? that would
be impossible. You also have the properties manager shared, but I think
that's a bad idea because then both modules are sharing a single
properties table which goes against the modularization. *if* something
should be shared then it should be shared by providing a custom
hybridized implementation of an interface which knows how to interact
with both systems. i.e. a RollerPlanetUserManagerImpl or a
RollerPlanetPropertiesManagerImpl could be used in place of the default
PlanetUserManagerImpl and PlanetPropertiesManagerImpl to allow users
from the "weblogger" module to be shared with planet.
When I look at the src tree the only things that I think are truly core
and could be shared would be these things ...
business.runnable (general purpose interfaces for running tasks)
util (some generic utility classes)
util.cache (generic caching framework, CacheManager can't be shared)
and even though those things could be shared i'm not sure it's really
worth it to require sharing them rather than just duplicating the small
amount of code. one problem with sharing them is that then if you want
to modify something in core you could be forcing changes in both modules
when the change is really only need to benefit one of the modules.
at first glance i think it would be fine to simply take out all of the
planet specific classes and put them in their own module under the
org.apache.roller.planet package and just duplicate the small number of
classes which need it.
-- Allen
Dave Johnson wrote:
Looks like I may have a requirement to deploy Planet independently of
Roller (but with Roller's Planet UI and the Roller rendering/caching
system). And others on the list have also expressed interest in
modularity. So I've started to think again about how to break up the
Roller code based into core, weblogger and planet modules.
I updated the proposal with some of my latest thinking:
<http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Modular_Roller>
The proposal has a way to go, but comments and suggestions are welcome.
- Dave
