Hi Carsten, others,
Following up on the initial email from Carsten, see further below.
While the new Pluto refactoring isn't finished yet, part of that involves adding new interfaces and implementations, so it is good to
discuss the package restructuring now to determine the best place for these new implementations.
So far, I've more or less followed the "old" convention where to put the new
interfaces (esp. the -Context interfaces).
I gave your proposal below some more thought and I definitely like it in
general!
Browsing to the current (trunk) packages we have now I was thinking about the
following (mostly in line with your proposal):
container-api:
- o.a.p
leave as is
- o.a.p.core
rename to o.a.p.driver
move NullPortlet as inner class to PortletServlet
- o.a.p.services
move PortletAppDescriptorServices to o.a.p.spi
move ContainerServices to o.a.p
move PlutoServices to o.a.p.driver (side-by-side PortletServlet)
- o.a.p.om.portlet
leave as is
- o.a.p.internal
rename Internal* to Container* (I really don't like the "Internal" prefix)
move * to o.a.p
- o.a.p.spi.optional
move * to o.a.p.spi
the distinction between spi and spi.optional (while somewhat useful
configuration wise) really is too artificial technical wise imo.
container (impl):
- o.a.p
move PortletContainerFactory to o.a.p.driver.impl
- o.a.p.core
move the following to new package o.a.p.impl
ContainerInvocation* (note: I've some ideas to completely get rid of
these all together)
PlutoContainerServices
PortletContainerImpl
move all the others to either
- o.a.p.driver.impl (those which really are used only by/for a
standalone/pure embedded driver)
- o.a.p.spi.impl (those which are of more generic usage and/or embedding
in a larger portal)
drop package o.a.p.core
- o.a.p.descriptors.portlet, o.a.p.descriptors.portlet10
rename these to o.a.p.om.portlet.impl and o.a.p.om.portlet10.impl
- o.a.p.descriptors.services.jaxb
move PortletAppDescriptorServiceImpl to o.a.p.spi.impl
- o.a.p.internal.impl
move * to o.a.p.impl
- o.a.p.util
move to o.a.p.impl.util
WDYT?
To anticipate the above, I'm going to create and commit (skeleton) request/response -ContextImpl classes in a new container/o.a.p.spi.impl
package now.
Ate
Carsten Ziegeler wrote:
Hi,
I'm currently trying to add portlet support to Apache Sling by using our
2.0 implementation.
One thing that strikes me is the use of packages in the various modules.
In order to have a clear separation and to easily support OSGi (where
there's no package overlap between modules), I think we should change
the following:
container-api:
- The api currently contains packages like core and internal which do
not sound like api packages. The "internal" stuff (request/response
impl) are used in the spi, so I think we should move it to the spi package.
- "core" contains the NullPortlet and the PortletServlet. The
NullPortlet is only used inside the PortletServlet, so we should make
this an inner class and not expose it. The PortletServlet could move to
a different package, something like "servlet".
container:
- The container should not use the org.apache.pluto package. We should
move the PortletContainerFactory class to the core or the util package
- Core contains the o.a.p.util package which is already taken by the
pluto-utils (which makes sense), so we shoud move this to another package.
- To have the best separation possible, we could move all container
stuff (impl) to o.a.p.container.*, but maybe this change is too much?
If noone objects, I'll do the obvious changes.
WDYT?
Carsten
