I hear your concerns David, so I'll start a thread on general?
My overall concern and itch I'm scratching is:
Right now assembly is performed manually by the developer (either by vi or by
Maven or Ant mechanisms), and this has a couple consequences:
1) Pluto-specific internals are exposed, and so Pluto container must (should?)
support older web.xml formats as the container evolves. The reality is that
right now this burden is being borne by the portlet developer when it should be
borne by the container (IMO).
2) Portlet wars are being packaged and distributed with pluto-specific
elements, reducing portability.
3) And then there is the headache that new portlet developers encounter: the idea of assembly - some manual steps taken during packaging - is foreign.
If Pluto isn't the place do to this that's cool with me, I believe
however that these are real issues to be addressed. So we can flesh
this out on general?
Elliot
David H. DeWolf wrote:
The last thing in the world I want to do is poo-poo the great progress
that has been made in our community lately. That said, while I think
these additions sounds great, the pmc (at least in the past) has been
fundamentally against the idea of expanding pluto beyond the container
scope. Between this addition, functionality recently added to the
administration portlets, etc. . ., I think pluto is becoming more and
more portal like. We need to remember our mission
(http://portals.apache.org/pluto/mission.html) is to first and foremost
to be a container.
Before we proceed, I'd like to make sure that we give the portals folks
that don't consistently monitor this list a chance to chime in to this
discussion. The PMC has recently been working very hard to bring our
communities together as the single project we are supposed to be. We
need to make sure that our efforts align with that of the pmc, jetspeed
,bridges, and wsrp4j communities.
If the decision is made to add this functionality, we need to make sure
it is factored in a way in which it does not confuse the portlet spec
RI. In other words, it should be in the portal (not container), and
clearly marked as optional. Given those conditions, I'm behind the
efforts and would like to help out.
David
Elliot Metsger wrote:
All,
I'd like to add hot deploy and auto assembly to Pluto. Acknowledging
that there may be a debate as to whether or not these are container
versus portal services, the goal is to make assembly and hot
deployment as easy as possible for portal implementors that use the
Pluto container. Hot deploy and auto-assembly would work out of the
box for users of Pluto portal.
Here are my high-level thoughts without going into too much detail -
please push back on them.
Add two optional container services: PortletAssembly and
PortletDeployment. Each service has a callback interface associated
with it: PortletAssemblyCallback and PortletDeploymentCallback.
The portal can provide full implementations PortletAssembly and
PortletDeployment if it wishes. However, most portals will choose to
provide implementations of the more simple callback interfaces.
If the portal provides its own implementation of the interfaces, the
container will use those. If the portal provides only the callbacks,
the container will use its default implementation of the
PortletAssembly and PortletDeployment interfaces, delegating to the
callbacks where appropriate. If callbacks are not provided by the
portal, then auto-assembly and hot-deploy will not be activated.
From a high level, how does this sound?
Implementation-wise I've been playing around. For the container to do
auto-assembly, it needs to have access to the Pluto assembly code in a
shared classloader.
I've had to extract the assembly code from pluto-util into its own
code module, and deploy the assembly code to shared. If you refactor
the assembly code to not use UtilityException (AssemblyException was
created and used instead), then the only dependencies added to shared
are the pluto-assembler jar and commons-io (If commons-io isn't
acceptable to load into shared, we can refactor it out). Since this
approach modifies the exceptions on existing Assembly interfaces, this
probably wouldn't make it into 1.1 for backwards compatibility reasons.
Thoughts?
Thanks,
Elliot
