Scott/David, Thanks for the clarification.
> > I was describing how to develop portlet applications and resources, > and pointing out that J2 separates portal from portlet application, > something J1 did not. Right. Even from what little I know now, decoupling Portal and Portlet development/deployment seems like a very nice feature in J2. > > The goal is to develop resources separate from the portal, and to > deploy and undeploy them separately. > From what I understand, what Scott is describing is how to setup an > environment for developing components to use inside of J2. > This can be used by more advanced users to create a customized portal Ok... the line between Portal and Portlet development is still a little blurry for me, (no doubt due to my limited understanding at this point). So, editing things like SimpleLayoutHeader.jsp or adding a customized component would seem to require a portal image/merge. Is the intention that PSML resources be deployable in the future, (or are they now)? The reason I ask is that it seems that the PSML defines the decorations/layouts used within the Portal, (i.e. the layout-decorator, portlet-decorator, and decorator attributes in defaults/fragment tags). It seems that one would want to deploy portlets and decorations/layouts and then deploy a PSML update to use them, no? At the risk of partly answering my own question, I have to assume that the Customizer would eventually allow all of the PSML to be managed. If that is true then, would PSML generally be considered data? That might explain why some would like to be saving PSML in the database. Others might want to configure the PSML simply as files because it is primarily fixed in their scenarios. As things stand today, should I assume that PSML development/deployment should be done with the maven plugin merge as outlined by Scott? Just feeling around in the dark guys.. thanks for the patience! Randy Watler
