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 <darkar...@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
