Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of paulmcmahan@gmail.com
 designates 209.85.132.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=MGtnfY5ZdrhDiEGmrnzxjBQ/1xDPB2c6pJks7kdnPt4zjVwElFd+IPrDZ2Iss4GynbDNgAEZjkktbqVtyRuM1Hyaa9fi9CNHW3CcX9pne9Y2aQuJn4sigP+tqi1wMkTCCtZj/B90l3CXfBiMDMvlCqU5eZZHFIbudbtaTkReWgs=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <c278ac970710310852g2914fc24k262dab8cc228117c@mail.gmail.com>
References: <20071026035204.948C21A9832@eris.apache.org>
 <4721D18E.4010403@apache.org>
 <9D48A8DA-02BC-4D1C-920E-94D451BEFDA8@gmail.com>
 <B83DBCCE-2FD5-4976-9A1D-B58F8EB0933E@yahoo.com>
 <B17FEBEE-600B-47FF-9007-234871FF72D0@gmail.com>
 <47234374.2060407@apache.org>
 <0953B268-6D0A-4AD1-8411-8D5E1395C124@yahoo.com>
 <7CD55758-8184-4390-AFF9-B5F5CD80332C@gmail.com>
 <c278ac970710310852g2914fc24k262dab8cc228117c@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EC18C775-9387-4E1F-BA3A-31DEB5B772CF@gmail.com>
Content-Transfer-Encoding: 7bit
From: Paul McMahan <paulmcmahan@gmail.com>
Subject: Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Date: Wed, 31 Oct 2007 12:22:14 -0400
To: dev@geronimo.apache.org


On Oct 31, 2007, at 11:52 AM, Prasad Kashyap wrote:

> On 10/29/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
>> On Oct 27, 2007, at 11:32 AM, David Jencks wrote:
>>
>>>>> The admin console needs to be lightweight and portable so it is
>>>>> based on Pluto.  The Jetspeed MBE (as currently designed) would
>>>>> interfere with the deployment of admin console extensions.
>>>>> Adding something to the Geronimo plan to activate the Jetspeed
>>>>> MBE instead of just looking for a WEB-INF/portlet.xml sounds like
>>>>> a reasonable solution.   Let's pursue that approach.
>>>>
>>>> +1 as I see many situations where the Pluto Admin Console will
>>>> still be used even when Jetspeed or Liferay are installed.
>>>
>>> I haven't looked into exactly how the admin console plugins get
>>> added to the admin console but if they are geronimo plugins they
>>> have already gone through the deployment process and there is no
>>> chance for the jetspeed MBE to see them as the deployment machinery
>>> is not activated at all when a plugin is installed.
>>
>> I see your point.   Limiting portal apps to installation via plugin
>> would offer an advantage that developers can pick the appropriate
>> MBEs at build time, giving them & us (the MBE provider) fine grained
>> control over every step in the deployment process.
>
> Isn't that a serious limitation ? We are forcing all portlet app
> developers to use maven and c-m-p. Most 3rd party developers would
> just want to build and deploy a portlet war and an associated geronimo
> plan. If the geronimo plan conveyed which portal and MBE to use, we
> don't have to have this limitation.

Yes, I also think it is a serious limitation and I agree with your  
position that portlet apps should also be deployable as WARs.    
Technically speaking, though, requiring portlet apps to be  
predeployed via car-maven-plugin is an option that has some merit  
(such as the careful selection of MBEs as described by David) and  
IIUC the approach that was being advocated.

>> While using MBEs has proven to be a very successful approach for
>> deploying services and enterprise apps in Geronimo I am concerned
>> that the lack of any standardization or a specification for deploying
>> portal apps could make this difficult and fragile in the case of
>> portlets.  My observation has been that deployment into most portals
>> (Liferay, Pluto, uPortal, and even Jetspeed itself) is based on the
>> concept that the developer creates a standard WAR and uses the
>> Portal's runtime or build-time utility for preprocessing it.   Then
>> the portal deploys the preprocessed WAR using the app server's
>> standard deployment mechanism, or relies on the end user to do this.
>> Can/should deployment of portlet into Geronimo be an extension of
>> that process?  I have been inclined to follow that approach so far
>> but there may be disadvantages I haven't thought of.
>
> If the portal's runtime or built-time utility is preprocessing the WAR
> and deploying it to an appserver, then isn't the onus on them to
> deploy it accordingly for the appropriate appserver they support ? The
> portal can continue to have their own deployment mechanism while we
> can have ours, say in the form of plugins. This two-pronged approach
> should fill all gaps and cover all types of users.

Yes, again I think that we are in agreement.  IMHO the portal vendor  
should continue to be responsible for providing the end user  
interface for preprocessing the WAR (if necessary), and then handling  
deployment of the WAR into the app server or prompting the user to do  
it.   This approach allows the portal's existing build-time and  
runtime deployment utilities to continue working as usual when the  
portal is running in Geronimo.  But this is a major decision that  
will have long term effects wrt portal integration in Geronimo, so  
let's continue to look for feedback and direction on this matter.


Best wishes,
Paul