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 <[email protected]>
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
