Daniel Fagerstrom pisze:
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.
Ok, that was me who introduced this one. ;-)
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.*
Agreed. Will do this shortly.
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.
Yep, but if we introduce back incompatibility for some other reason I think we should take the
opportunity to clean up packages as well.
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.
I see. Thanks for clarifying.
--
Grzegorz Kossakowski
