+1 to avoiding myriads of jar files some of the commons projects take this to the extreme - all of a sudden you have 500 dependencies, half of which are very small jar files in any case. it just makes it incredibly hard for new developers (and those of us who don't speak binary as a native tongue like some of you crazy guys).
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Cannon-Brookes Sent: Friday, 31 January 2003 8:01 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Partition XWork [Was: Re: XWork flux] 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%20State > ment > > 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 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
