Grzegorz Kossakowski skrev:
Hi folks,
I've tried refactored SSF (1.1.0-SNAPSHOT version) and it looks very
good to me. I'm thinking about releasing first milestone of this module
(along with cocoon-jnet) but I've been struck by a little mess in
packages we have in SSF and cocoon-jnet.
Let's have a look at SSF, we have following packages:
o.a.c.callstack.*
o.a.c.servletscope.*
o.a.c.servletservice.*
The reason that I used a separate top level package for the
o.a.c.callstack was that I had some idea about using it as some kind of
generic call stack for the site map engine (and move it to an own
module). That would have required some refactoring that I never felt
motivated enough to pursue.
I don't know (or remember if I was responsible ;) ) about the
o.a.c.servletscope package.
As o.a.c.callstack.* probably isn't useful outside the context of
servlet services and only used in the implementation it might be safe to
move it to o.a.c.servletservice.callstack.*
Now cocoon-jnet:
o.a.c.jnet.*
o.a.excalibur.sourceresolve.jnet.*
This brings us to couple of questions:
1. Do we want to have a policy to have only one base package (e.g.
o.a.c.servletservice.*) per one module (artifact, JAR, you name it)?
That is preferable. But it is not necessary. If a module already
contains several "top level" packages that people are using, it might
not be worthwhile to introduce back incompatibility just for the sake of
minor elegance.
2. What OSGi folks can say about this situation? I remember that there
was some requirement to have clean package structure in order to run in
OSGi environment easily but I'm not expert in this area.
The requirement for making OSGi use possible is the opposite way around.
Two modules cannot use the same package. If two modules (bundles) add
different classes to the same package just the classes from one of the
module will be available in the OSGi framework.
An example of this problem is the package o.a.c.generation that is
populated with interfaces and implementations in numerous modules.
But neither cocoon-jnet nor SSF has any such problems AFAIK.
3. Why cocoon-jnet has excalibur-specific classes at all? I thought that
we agreed we are not going to support Sources as URLs and only focus on
new functionality. Then o.a.excalibur.sourceresolve.jnet.* should be
removed right?
Don't know.
/Daniel
