myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Date Wed, 04 Feb 2009 16:58:43 GMT
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.  :)


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