Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-22 Thread Matthias Wessendorf
On Thu, May 22, 2008 at 4:59 AM, Scott O'Bryan [EMAIL PROTECTED] wrote: Right. I'm for #3... And lets face it. The EASIEST way to run the demo is to download the tag and in the demo directory type mvn jetty:run.. +1 on that. If they contain doesn't ship what it should... why should we fix

[Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Paul Spencer
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Scott O'Bryan
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Scott O'Bryan
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Paul Spencer
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Scott O'Bryan
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:

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Andrew Robinson
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Scott O'Bryan
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Paul Spencer
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

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Scott O'Bryan
Right. I'm for #3... And lets face it. The EASIEST way to run the demo is to download the tag and in the demo directory type mvn jetty:run.. Hey Paul, do you want to contribute the documentation via the website or wiki? Scott Paul Spencer wrote: Scott and Andrew, The goal is to make it

Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?

2008-05-21 Thread Scott O'Bryan
Hey Paul, can you do me a favor and JIRA up this improvement? It'll allow us to track the patches for this enhancement. For what it's worth, I *DO* think what you're trying to do has merit, I'm just not a big fan of making binary distributions for every possible container, especially when