myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Roethenbacher <>
Subject Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Date Mon, 09 Feb 2009 01:30:37 GMT
Scott O'Bryan wrote:
> Hey Felix, thanks for chiming in.
> Quite possibly that would be a good suggestion.  I'm not sure I even 
> know the lifecycle of an "optional" dependency.  If it's avaialble 
> during compile time then absolutely, but my assumption was that 
> "optional" dependencies were based on whether the library was avaialble 
> or not.  It always needs to be available during compile time.

To my understanding a dependency marked as optional might or might not
be available at runtime. It's always available at compile time.
A dependency with scope 'provided' (the current scope of the
portlet-bridge and portlet dependencies) though will always be available
at runtime provided by runtime environment.

> BTW- Can you test the patch I submitted for TRINIDAD-1376 to make sure 
> it solves all of the related issues in your portlet environment?  I 
> think I fixed the issues you were having but I wanted to be sure before 
> committing.

Tested with Pluto and Websphere Portal. Please see my notes in JIRA.

Thanks for your efforts.

- Felix

> Scott
> Felix Roethenbacher wrote:
>> It totally makes sense to keep Trinidad free of (runtime) dependencies
>> on portlet-api and portlet-bridge-api. Sorry for my misunderstanding:
>> I thought it was ok to include dependencies on this API's after
>> Scott said he doesn't mind to have a dependency on the
>> portlet-bridge-api. I didn't get it that he only meant a
>> compile-time dependency and not a runtime dependency.
>> Should the dependencies on this API's be marked as optional in
>> the pom.xml to make this clear?
>> - Felix
>> Scott O'Bryan wrote:
>>> The most recent discussion about this was on TRINIDAD-1377 and some 
>>> of the connected bugs.  Felix has been very instrumental in helping 
>>> to diagnose and fix some of the portal bugs for Trinidad.  
>>> Unfortunately I had to reject or rewrite the majority of the 
>>> submitted packages because they added runtime dependencies on the 
>>> Portlet API and Portlet Bridge API's.
>>> To his credit, I don't think it's obvious that the Trinidad 
>>> dependencies on these jars were compile-time dependencies only which, 
>>> essentially, is what sparked this email.  That said, if the community 
>>> thinks that this is no longer an important feature, I do agree with 
>>> Felix that the code within Trinidad would become a LOT cleaner.  I 
>>> for one think allowing these api's to be optional during runtime is 
>>> important.  But I only get one vote.  :)
>>> Scott
>>> Matthias Wessendorf wrote:
>>>> On Tue, Feb 3, 2009 at 11:53 PM, Scott O'Bryan <>

>>>> wrote:
>>>>> Hey all,
>>>>> First off, I would like to thank the people recently who have shown an
>>>>> interrest in running Trindiad with Portlet environment.  I've had a 
>>>>> laundry
>>>>> list of things to do as of late and, in true community fashion, you 
>>>>> are
>>>>> helping me evolve Trinidad to comply with the latest bridge.  Yay!!
>>>>> I did, however, want to write a quick note and get some community 
>>>>> feedback
>>>>> on a misunderstanding that has arose lately about Trinidad's 
>>>>> dependency on
>>>>> the Portlet 1.0 API and the MyFaces Portlet Bridge.  The Portlet 
>>>>> and Portlet
>>>>> Bridge API's are included in Trinidad's POM files.  They are needed to
>>>>> compile the project, and this is unavoidable to a large extent 
>>>>> because we
>>>>> have tried to build in a portlet solution.  To date, however, 
>>>>> Trinidad's
>>>>> code is implemented in such a fashion that if it is deployed into an
>>>>> environment or an application WITHOUT these API's (like Tomcat or 
>>>>> Jetty),
>>>>> the code will run without getting a ClassNotFound exception.  
>>>>> Instead the
>>>>> Portlet usecases are simply ignored and no classes which contain 
>>>>> references
>>>>> to portlet objects (directly) are loaded.
>>>>> I believe we want to continue to make the existence of the Portlet and
>>>>> Portlet Bridge API's optional at runtime.  As a developer for 
>>>>> Oracle (whose
>>>>> current application solution uses Trinidad as a foundation), our 
>>>>> ide does
>>>>> not currently include the portal apis when you say you want a Trinidad
>>>>> project.  The Portal and portal bridge are included only if your 
>>>>> container
>>>>> supports a portal.  The last thing I want to do is force people who 
>>>>> have
>>>>> existing applications to have to include several new API's in their 
>>>>> webapps,
>>>>> especially because the Portlet Bridge code is still in beta and in 
>>>>> the near
>>>>> future I hope to have support for both Portlet 1.0 AND Portlet 2.0.
>>>> +1 on having these libs optional on RT side of things.
>>>> Was there any noise on this ? Can you point me to a specific thread ?
>>>> Why should I mess up with my Jetty, by adding (bogus) libs (->portlet)
>>>> to just run
>>>> a servlet-based application ?
>>>>> Do people agree with this or am I off base?  Any questions with how 
>>>>> this
>>>>> works?
>>>>> Scott

View raw message