Scott and Andrew,
The goal is to make it easy for a user to get the demo up and running
with minimal frustration. Since I am not currently working in a J2EE
environment, my desire to quickly get the demo running in order to test
the 1.2.8 release did not include a J2EE server. I dropped the war in
an available Tomcat server and then had to determine why the demo failed
to run. After determining the I need a JSTL jar, I was able to test the
release.
I make the following suggested solutions, in order of preference:
1) "distribute" a non-J2EE Demo and Blank either in the existing Example
distribution or in an non-J2EE distribution.
2) Add installation instruction that include instructions for J2EE and
non-J2EE environments. The instructions, including any required jars,
should be included in the .zip/.tar.gz file.
3) Add instructions on building a non-J2EE environment from the source.
What ever solution is chosen, the instructions should also be on the
Demo's web page[1].
Paul Spencer
[1]http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html
Scott O'Bryan wrote:
Andrew,
Yeah, that's what I proposed. Paul wants us to "distribute" the
non-j2ee version with our examples...
Scott
Andrew Robinson wrote:
We can relatively easily create a tomcat profile that could be used to
deploy onto tomcat by changing the dependency scope from to provided
to compile right?
Just as we have the jetty profile and the jetty plugin registered, we
can do the same for tomcat I think.
The drawback of course is maintaining the poms for different servers
-Andrew
On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan <[EMAIL PROTECTED]>
wrote:
Well documentation is easy. I'm just not excited about having to
maintain
two trees or wasting a lot of spacing building multiple versions of a
demo
application when all someone has to do is look at the pre-req's and make
sure it's available in their environment.
Scott
Paul Spencer wrote:
Scott,
Well I sort of assumed that people wanting configurations outside
of the
standard supported J2EE configuration would compile the branch
themselves.
And this is document where :)
http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html
http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html
I am of the opinion that a demo/example should run as distributed
and the
installation should be intuitive. In this case the distribution is
build
for a J2EE environment, but it is not obvious to anyone installing it.
Paul Spencer
Scott O'Bryan wrote:
Well I sort of assumed that people wanting configurations outside
of the
standard supported J2EE configuration would compile the branch
themselves.
Scott
Paul Spencer wrote:
Scott,
If the Demo includes JSTL, will it work on a J2EE server?
( I suspect the server will/should complain when 2 copies/version of
JSTL exists )
If not then when should distribute :
A) J2EE version and non-J2EE version of Example.zip/tar.gz
or
B) Example.zip/tar.gz containing a J2EE and non-J2EE version of
trinidad-demo.war and trinidad-blank.war
Paul Spencer
Scott O'Bryan wrote:
IMO this isn't necessary. We already control whether we deploy the
myfaces jars using a profile. Can't we add a profile which
includes the
JSTL jars in the demo when it's built? Also, it should be easy
enough to
add them to tomcat as a shared library as well.
Scott
Paul Spencer wrote:
The current Trinidad demo will not work in a non-J2EE container,
i.e.
Tomcat 6.0, because it does not contain the JSTL jar. Should we
add a
non-J2EE demo to the distribution?
I would say yes because it simplifies the process of getting the
demo
running in an not-J2EE environment.
Paul Spencer
