Right - I agree. This sounds like a ridiculous idea really. I don't want to have to update 7 (!!) CVS modules and build 7 JARs just to use webwork.
What does having JSP support in the JAR if you don't use JSP give you? Maybe 10k extra in your app? You'll manage :) -mike On 31/1/03 4:18 AM, "Jason Carreira" ([EMAIL PROTECTED]) penned the words: > See > > http://www.opensymphony.com:8668/space/XWork+1.0+Mission+Statement > > And > > http://www.opensymphony.com:8668/space/WebWork%202.0%20Mission%20Statement > > Basically, Xwork is going to be the core generic command pattern > implementation. Webwork 2.0 is going to be an MVC framework tailored for the > web and built on Xwork 1.0. > > So the real question here is whether it makes sense to partition Webwork 2.0 > into: > > Webwork-core > Webwork-el > Webwork-jsp > Webwork-velocity > Webwork-xslt > Webwork-jasperreports > Webwork-freemarket > > There may be later extensions to Xwork as well (JMSWork?, MailWork?). > > Personally, I think Webwork is small enough to stand as one module with all of > the view types included. > >> -----Original Message----- >> From: Philipp Meier [mailto:[EMAIL PROTECTED]] >> Sent: Thursday, January 30, 2003 12:02 PM >> To: [EMAIL PROTECTED] >> Subject: [OS-webwork] Partition XWork [Was: Re: XWork flux] >> >> >> On Thu, Jan 30, 2003 at 07:37:45AM -0800, Jason Carreira wrote: >> >>> Oh, other than the ThreadLocal thing, there are also remaining >>> questions about Ognl and whether we can plug in our EL, or >> whether it >>> should be undertaken to re-architect our existing EL for >> performance. >> >> I want to propose to partition the xwork in several >> (independent) modules. Because I e.g. do not use jsp or >> velicity, and because I do not contribute to the development, >> it would be nice to seperate them from the core stuff. It >> makes sense to me to have the following cvs modules: >> >> * xwork (or xwork-core) >> * xwork-web (ServletDispatcher and FilterDispatcher and so on.) >> * xwork-view-el (used by jsp and velocity) >> * xwork-view-jsp >> * xwork-view-velocity >> * xwork-view-xslt >> * xwork-view-freemarker >> * xwork-jms (Dispatcher and helpers for JMS) >> * xwork-mail (Dispatcher and helpers for Mail) >> >> Does this make sense? I see xwork growing and growing and >> becoming more and more confusing. On the other hand, size >> does matter and we must consider that every view type needs >> it's supporting libraries. >> >> My €0.02, >> -billy. >> >> -- >> Meisterbohne Söflinger Straße 100 Tel: >> +49-731-399 499-0 >> eLösungen 89077 Ulm Fax: >> +49-731-399 499-9 >> > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
