portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [unsure] [RT] Cleaning up our packages
Date Tue, 03 Mar 2009 09:48:03 GMT
Hi Carsten,

First of all, I think all your proposed changes are fine by me.
But, I'd prefer if you can hold off these changes a few more days?

As you know I proposed some other major refactorings for Pluto 3 weeks ago, see:

I started working on the major part of these already, see PLUTO-529/530/531/532, and already
have a large part of those completed locally.
As a matter of fact, some of your recent changes I already had taken care of myself too ;)

Now, my changes will result in quite some SPI usage changes, and for instance I could remove
almost all the *Internal* interfaces (now only 
needing the Portlet 2.0 request/response interfaces itself), and no more "wrapping" or "blending"
of the portlet and servlet interfaces.

As such, I planned to commit my changes to a separate branch this week so everyone can review
the effect of all this, before I would merge 
it back into trunk.

I've encountered a small problem however: I broke my elbow this Sunday at a soccer game and
because of that I'm stuck with an immobilized 
left arm for the next 2 weeks :(
  I *can* and will continue working on this however, even if only with one hand, and still
plan to proceed with the above.
Randy Watler has indicated he wants to help me out with the remaining tasks (which still are
considerable), so we definitely should still be 
on track.

FYI: what I've done so far is abstracting every logic and interaction which is container/portal
specific in new SPI request/response 
"-Context" interfaces. The request/response implementations (now no longer implementing "Internal-")
all only deal with the Portlet 2.0 
*restrictions/requirements*, so ensure all validations, checks, and then (where applicable)
delegate to the "-Context" SPI.
As result, we'll have a clean, and *complete* Portlet 2.0 implementation layer to be used
by the portlet developers, and a complete 
pluggable SPI layer for processing the *already* validated input.

So far, I've almost completed the painstakingly implementation of the first layer (I now must
have read the 2.0 spec and javadoc at least 
100x), and have the second SPI layer defined but still no SPI impl. yet.
For the new SPI however we should be able to provide a new default/Pluto impl quickly enough
as most of that logic is either a simple 
delegate to the underlying servlet request/response objects or doesn't have a real impl like
cache handling (in the Pluto Driver case that is).
Only real impact will be for the Portal Driver PortletURLProviderImpl and EventProviderImpl
instances, but still it will be mostly 
moving/shuffling existing code/behavior, not really a rewrite.

Anyway, as you can understand from the above, I'd rather wait with your proposed repackaging
changes until we've gone through the above 
transition, otherwise merging will become extremely difficult thereafter.

I've already had difficulty validating/merging your recent changes as the meat of those are
formatting changes only but with some real 
changes embedded. It would be nice if you can separate those 2 different types of changes
in individual commits?



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.
> Carsten

View raw message