You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Scott O'Bryan <da...@gmail.com> on 2009/02/03 23:53:29 UTC
[TRINIDAD] Portlet API and Portlet Bridge API Dependencies
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.
Do people agree with this or am I off base? Any questions with how this
works?
Scott
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Felix Roethenbacher <fr...@apache.org>.
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 <da...@gmail.com>
>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Scott O'Bryan <da...@gmail.com>.
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.
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.
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 <da...@gmail.com>
>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Felix Roethenbacher <fr...@apache.org>.
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 <da...@gmail.com>
>> 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
>>>
>>>
>>
>>
>>
>>
>
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Scott O'Bryan <da...@gmail.com>.
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 <da...@gmail.com> 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
>>
>>
>
>
>
>
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Scott O'Bryan <da...@gmail.com>.
I guess the base bug TRINIDAD-1276 has a link to all the other bugs
where the discussion has popped up.
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 <da...@gmail.com>
>> 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
>>>
>>>
>>
>>
>>
>>
>
>
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Scott O'Bryan <da...@gmail.com>.
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 <da...@gmail.com> 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
>>
>>
>
>
>
>
Re: [TRINIDAD] Portlet API and Portlet Bridge API Dependencies
Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Feb 3, 2009 at 11:53 PM, Scott O'Bryan <da...@gmail.com> 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
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf