Thread: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony]
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel
|
From: Victor S. <vsa...@ho...> - 2002-02-11 15:20:48
|
Hi: Being a developer in both projects I highly agree. I feel that closer integration between these two projects would be beneficial to everyone. One of the biggest obstacles a potential user has when building an application is finding all the right components to achieve the desired result. OpenSymphony has concentrated in making components to fulfill this need. Most of the OpenSymphony developers are already WebWork users, so this obviously says "Yes, the two together make a great combo". Some additional benefits I perceive from the integration: - Allows users to quickly build applications using a set of components that have been throughly tested. The capability of making production type applications in prototype-speed is unbeatable! (OSCache / Sitemesh) - Bridges some of the gap for WebWork EJB development. (OSCore) - Provides the basis for a highly extensible user/role auth system. - Makes the WebWork/Opensymphony more a complete platform, instead of some tools! - The merging of all the great minds that work on both projects.!! --- Issues: The only issue I have with this ... relevant to both webwork and opensymphony. To the view of a user, configuration of webwork and OS components is a pain in the ass. We need to write a "SINGLE" configuration factory and minimize the use of configuration files to only one or two.... Example: actions.xml views.properties sitemesh.xml decorators.xml oscache.properties osuser.xml blabla.conf blabl.xml, some stuff in <init-param> .... This all could be replaced with : os.xml then we could have a <include> tag in there to include other files... ... I'd really like to make life easier for the average developer... /V >From: Rickard <ri...@mi...> >To: webwork-devel <web...@li...> >Subject: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 15:25:58 +0100 > >WebWorkers, > >I just got this from OpenSymphony. It's an interesting proposal, but I'd >like to hear your input whether you think it's good or not. What are the >pro's and con's? > >regards, > Rickard > >ps. Those of you who are already involved with OS, please state this >when voicing your opinion on this. > >-- >Rickard Öberg >Author of "Mastering RMI" >Chief Architect, TheServerSide.com > The Middleware Company - We Build Experts! ><< WebWork-OpenSymphony >> _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Victor S. <vsa...@ho...> - 2002-02-11 15:28:02
|
>You mean SiteMesh ;-) Yes, those are good, along with OSCache. There are >a few not-so-good too, but the overall quality is ok. > > If this merge happens, FormTags will probably be archived. TransformTags should be kept, as it is very useful. The other production components are the kick-ass ones :) /V _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. |
|
From: <ch...@ch...> - 2002-02-11 16:05:53
|
sorry about all the CCs... my webmail client is having fits... As Velocity/Webwork user and an OpenSymphony developer, my personal goal is to help make OS components more velocity friendly. I have been using sitemesh with WW/Velocity for a couple weeks now (and before that a "sitemesh lite" from Victor S.) and it works great for me.. OSUser is another component that I find quite valuable which is view agnostic. I think adding WW to OS will help make all projects involved better. Dan On Mon, 11 February 2002, Dave Bryson wrote: > > On Monday 11 February 2002 08:25 am, you wrote: > > I just got this from OpenSymphony. It's an interesting proposal, but I'd > > like to hear your input whether you think it's good or not. What are the > > pro's and con's? > > It seems like some of the key components of OpenSymphony ( OSCache and > Sitemesh ) are slanted towards JSP. Can these components be used with > Velocity or would the merge kill Velocity support? > > One of the main reasons I moved to WebWork was it's simplicity and > few dependencies on external libraries. I fear a merge would evolve towards > bloat - causing an eventual dependency creep between OpenSymphony and WebWork. > > IMO, WebWork is best served by itself. > > dave > -- > Dave Bryson > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Victor S. <vsa...@ho...> - 2002-02-11 18:10:54
|
Hi Dave: I have written the following items for Velocity/WebWork: 1. Sitemesh #decorate directive. 2. OScache #cache directive 3. Made a better Webwork/Velocity Servlet just for your information :) ... it wouldn't be a kill as I don't use JSP anymore, but JSP is useful to a lot of people... WebWork is agnostic and a lot of OpenSymphony too... It's been designed like that. Cheers, /V >From: Dave Bryson <db...@in...> >To: Rickard <ri...@mi...>, >"web...@li..." <web...@li...> >Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 09:33:45 -0600 > >On Monday 11 February 2002 08:25 am, you wrote: > > I just got this from OpenSymphony. It's an interesting proposal, but I'd > > like to hear your input whether you think it's good or not. What are the > > pro's and con's? > >It seems like some of the key components of OpenSymphony ( OSCache and >Sitemesh ) are slanted towards JSP. Can these components be used with >Velocity or would the merge kill Velocity support? > >One of the main reasons I moved to WebWork was it's simplicity and >few dependencies on external libraries. I fear a merge would evolve >towards >bloat - causing an eventual dependency creep between OpenSymphony and >WebWork. > >IMO, WebWork is best served by itself. > >dave >-- >Dave Bryson > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Dave B. <db...@in...> - 2002-02-11 18:56:20
|
On Monday 11 February 2002 12:10 pm, you wrote: > Hi Dave: > > I have written the following items for Velocity/WebWork: > > 1. Sitemesh #decorate directive. > 2. OScache #cache directive > 3. Made a better Webwork/Velocity Servlet > > just for your information :) ... it wouldn't be a kill as I don't use JSP > anymore, but JSP is useful to a lot of people... I need to take a closer look at some of opensymphony's components ( some much technology... so little time! ). I'm glad to hear others are you using Velocity. Thanks, dave -- Dave Bryson |
|
From: <ma...@sm...> - 2002-02-11 19:27:08
|
If the merge was done right, there could be obvious benefits - developers, users, code resuse, etc. The challenges I see is that there is overlap between the two projects which is confusing and I'm concerned that WW will get lost amongst the other modules. Ideally, the merge would require some refactoring. For instance, WW would utilize modules from OpenSymphony; i.e., BeanUtil, etc. This would definitely require refactoring but would be of great benefit to users and developers. We would need uniform documentation, best practices, better examples, etc. If we just merge as is now, I say no. It only brings confusion to most developers. The more advanced developers will mix and match on their own anyway. -Matt On Mon, 11 February 2002, Rickard wrote: > > WebWorkers, > > I just got this from OpenSymphony. It's an interesting proposal, but I'd > like to hear your input whether you think it's good or not. What are the > pro's and con's? > > regards, > Rickard > > ps. Those of you who are already involved with OS, please state this > when voicing your opinion on this. > > -- > Rickard Öberg > Author of "Mastering RMI" > Chief Architect, TheServerSide.com > The Middleware Company - We Build Experts! |
|
From: Mike Cannon-B. <mi...@at...> - 2002-02-12 04:13:27
|
OK - I've kept a little quiet on this to try to let other people get their views out as I'm obviously very biased here (being the OS founder, OS core developer and a long time WW user/enthusiast). I've got a lot of thoughts covering a lot of different topics, so please bear with my extended ramble :) OpenSymphony was formed on a number of philosophies - Open Source is the best way to evolve great components - OPEN - component based s/w design is the way of the future - components should work well by themselves (ie few depenencies as poss.) - BUT their synergy should improve when connected together - in SYMPHONY! (hence the project name :)) I think one of the reasons that webwork is so well used by the core developers (who all share these core beliefs) is that webwork itself is a beautiful, modular component, that follows all the rules. (Incidentally IMHO this is why Apache's Jakarta has so many problems - thei= r components are too interdependent, the focus is not as much on quality of components are assimilation of new ones. Hence the fact that the best parts - Lucene, Log4J, Velocity - were developed outside the project) On the merger I have to say that I'm in favour in principal as I feel it would benefit both projects greatly for the reasons postulated by various others already.=20 My requirements would be very similar to Matt's (I'm glad he brought them u= p first): 1) it's a merger not an assimilation - I'd like webwork to be one of the 4 or 5 core components of the platform talked about by Victor. - I think given the people involved this is unlikely to happen, but I don't want WW to be 'dumped' or at all neglected because of it. - This is what happens to too many of the Apache projects I feel - people treat Jakarta as a dumping ground for code they are sick of maintaining, or they feel 'assimilated' and the progress slows. (I don't expect this to happen at all :) but I just thought I'd make the point to make sure) 2) documentation and releases - the WW documentation has come along in leaps and bounds recently (HUGE congratulations to those involved) - this is one area the OS group could learn from, the techniques and technologies used. - releases - I can never make this point enough, and it's one area where Apache wins - WE DON'T MAKE ENOUGH RELEASES (either of us). While core developers and enthusiasts will download the latest code from CVS, the larg= e majority of developers only use downloadable builds. They don't care if it'= s broken/beta, they just want to use and follow development. (for other references see linux projects which are released very often, things like 0.0.1! :)) 3) refactoring - this is something that's going to take more thought, but I think all the components could be refactored to work better together (ie as Matt and Victor said - sharing common code for things like configuration, bean referencing, caching etc) - needs thought from both sides IMHO on how this is best achieved, but ther= e does seem to be tangible synergy here The OS website is about to undergo a major redesign to make more prominent the good components, and 'archive' the old, unused code - but here's a summary of the 4 main components: OSCORE=20 - The one hierarchical core module (a little like the Jakarta Commons excep= t not a dumping ground) - The most used module here is the PropertySet module, which provides for generic typed attribute storage in various providers (eg EJB, XML, Memory, JDBC etc) and utilities for transferring between them. - The Sequence generator is a high/low sequence creator only really useful in an EJB environment - should be refactored out of the core IMHO - The other utility classes are useful for their respective areas (eg Strin= g manipulation, reflection, XML APIs etc) - this is one area where stuff like BeanUtil/BeanUtils (!) etc could be refactored and merged nicely =20 OSUSER - This is perhaps the most useful module to all J2EE developers - It provides a generic user management API that operates on any app server= . Storage providers (at the moment Memory, EJB and Castor - File, JDBC to be done) are separated from authentication providers (tieing into app servers like Orion, Resin, JBoss etc) which are also separate from app server adapters (which operate backwards - tieing app server into OSUser). - Overcomes one of the blockers to true J2EE portability - As we're already seeing from JIRA (http://www.atlassian.com/beta/jira) this is EXTREMELY useful. JIRA is written ontop of OSUser for user mgt, and already it runs on JBoss, Orion and almost on Weblogic. And people can stor= e their users in LDAP, EJBs, direct JDBC etc - separate from their app server choice! - Potentially something that needs to be replicated for Transaction management / obtaining (there seems to be no generic way to obtain a TX within an app server?) OSCACHE - Started as a post processed JSP caching system, it's now a much more flexible generic object caching system that's got very widespread use - Definitely the most popular and one of the oldest components - written up in JavaWorld etc, thousands of downloads etc. - Something else I feel we could integrate very easily (if you use JSPs or Velocity, it's great for speed) SITEMESH - Presentation system that follows the GoF decorator pattern, separates presentation from simple content at the page and panel/portlet level - Requires Servlet 2.3 - Second most used OS component - I use it on every project and it's already got some WW integration bits done by Victor Adding WebWork would mean the entire 'suite' covered core component structure, control flow, caching, presentation and user management. Seems t= o fit quite nicely?=20 Ok, well that's my piece - if you read this far it means it can't have been that boring :) I'm not sure how to progress further - I canvassed 5 of 6 OS core developers yesterday and all were in favour from our end so the ball i= s in your court I guess? -mike PS If anyone has questions and wants to ask off list, feel free - mi...@at... PPS If the decision is to merge, I'd suggest AFTER webwork 1.0 - no great reason to refactor already working code - release early, release often! PPPS And I'd suggest a 'slow' merge - common website initially, slow code cross pollination, thought exchange etc. On 12/2/02 6:27 AM, "ma...@sm..." (ma...@sm...) penned the words: > If the merge was done right, there could be obvious benefits - developers= , > users, code resuse, etc. The challenges I see is that there is overlap be= tween > the two projects which is confusing and I'm concerned that WW will get lo= st > amongst the other modules. Ideally, the merge would require some refactor= ing. > For instance, WW would utilize modules from OpenSymphony; i.e., BeanUtil,= etc. > This would definitely require refactoring but would be of great benefit t= o > users and developers. We would need uniform documentation, best practices= , > better examples, etc. >=20 > If we just merge as is now, I say no. It only brings confusion to most > developers. The more advanced developers will mix and match on their own > anyway. >=20 > -Matt >=20 > On Mon, 11 February 2002, Rickard wrote: >=20 >>=20 >> WebWorkers, >>=20 >> I just got this from OpenSymphony. It's an interesting proposal, but I'd >> like to hear your input whether you think it's good or not. What are the >> pro's and con's? >>=20 >> regards, >> Rickard >>=20 >> ps. Those of you who are already involved with OS, please state this >> when voicing your opinion on this. >>=20 >> --=20 >> Rickard =D6berg >> Author of "Mastering RMI" >> Chief Architect, TheServerSide.com >> The Middleware Company - We Build Experts! >=20 > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Hani S. <ha...@fo...> - 2002-02-12 11:07:30
|
I'm another one of the os developers and for what it's worth, here are my thoughts! I currently do NOT use webwork, but I do use many os components. I actually have many of them in production environments, so my main concern in the cas= e of this merge is backward compatibility. I'm unable (well, not in a 'serious' sense) to track a codebase in a production environment that's in constant flux, which is the impression I've had of ww. HOWEVER, this is probably different now, as ww gets more docs and the frantic development pace slows down. This is not meant as a negative comment in any way, it's just an observatio= n based on hearing various people grumble as they update ww, and say that blahblah now no longer works and so on. However, I am actually in favour of the merge, since knowing the people involved, it sounds like it'll be done 'right'. A slow gradual merge, with clearly defined dependency points. It'd also be nice if at least initially, the dependency is optional (eg, I don't mind having to have webwork.jar for compile purposes, but I do not want to suddenly have to drop it in a production box), and if we could slowly work our way to a solid release tha= t way. So I'm with Matt below, no to merge as is right now, but a big resounding yes to beginning work to ease into merging. Some refactoring, clean up, and so on, then a merge a month or two down the line, when both projects have had enough time and thought put into the whole thing that the idea no longe= r elicits a 'woah!' Hani On 11/2/02 9:42 pm, "Mike Cannon-Brookes" <mi...@at...> wrote: > OK - I've kept a little quiet on this to try to let other people get thei= r > views out as I'm obviously very biased here (being the OS founder, OS cor= e > developer and a long time WW user/enthusiast). >=20 > I've got a lot of thoughts covering a lot of different topics, so please > bear with my extended ramble :) >=20 > OpenSymphony was formed on a number of philosophies > - Open Source is the best way to evolve great components - OPEN > - component based s/w design is the way of the future > - components should work well by themselves (ie few depenencies as poss.) > - BUT their synergy should improve when connected together - in SYMPHONY! > (hence the project name :)) >=20 > I think one of the reasons that webwork is so well used by the core > developers (who all share these core beliefs) is that webwork itself is a > beautiful, modular component, that follows all the rules. >=20 > (Incidentally IMHO this is why Apache's Jakarta has so many problems - th= eir > components are too interdependent, the focus is not as much on quality of > components are assimilation of new ones. Hence the fact that the best par= ts > - Lucene, Log4J, Velocity - were developed outside the project) >=20 > On the merger I have to say that I'm in favour in principal as I feel it > would benefit both projects greatly for the reasons postulated by various > others already.=20 >=20 > My requirements would be very similar to Matt's (I'm glad he brought them= up > first): >=20 > 1) it's a merger not an assimilation > - I'd like webwork to be one of the 4 or 5 core components of the platfor= m > talked about by Victor. > - I think given the people involved this is unlikely to happen, but I don= 't > want WW to be 'dumped' or at all neglected because of it. > - This is what happens to too many of the Apache projects I feel - people > treat Jakarta as a dumping ground for code they are sick of maintaining, = or > they feel 'assimilated' and the progress slows. > (I don't expect this to happen at all :) but I just thought I'd make the > point to make sure) >=20 > 2) documentation and releases > - the WW documentation has come along in leaps and bounds recently (HUGE > congratulations to those involved) - this is one area the OS group could > learn from, the techniques and technologies used. > - releases - I can never make this point enough, and it's one area where > Apache wins - WE DON'T MAKE ENOUGH RELEASES (either of us). While core > developers and enthusiasts will download the latest code from CVS, the la= rge > majority of developers only use downloadable builds. They don't care if i= t's > broken/beta, they just want to use and follow development. > (for other references see linux projects which are released very often, > things like 0.0.1! :)) >=20 > 3) refactoring > - this is something that's going to take more thought, but I think all th= e > components could be refactored to work better together (ie as Matt and > Victor said - sharing common code for things like configuration, bean > referencing, caching etc) > - needs thought from both sides IMHO on how this is best achieved, but th= ere > does seem to be tangible synergy here >=20 >=20 > The OS website is about to undergo a major redesign to make more prominen= t > the good components, and 'archive' the old, unused code - but here's a > summary of the 4 main components: >=20 > OSCORE=20 > - The one hierarchical core module (a little like the Jakarta Commons exc= ept > not a dumping ground) > - The most used module here is the PropertySet module, which provides for > generic typed attribute storage in various providers (eg EJB, XML, Memory= , > JDBC etc) and utilities for transferring between them. > - The Sequence generator is a high/low sequence creator only really usefu= l > in an EJB environment - should be refactored out of the core IMHO > - The other utility classes are useful for their respective areas (eg Str= ing > manipulation, reflection, XML APIs etc) - this is one area where stuff li= ke > BeanUtil/BeanUtils (!) etc could be refactored and merged nicely >=20 > OSUSER > - This is perhaps the most useful module to all J2EE developers > - It provides a generic user management API that operates on any app serv= er. > Storage providers (at the moment Memory, EJB and Castor - File, JDBC to b= e > done) are separated from authentication providers (tieing into app server= s > like Orion, Resin, JBoss etc) which are also separate from app server > adapters (which operate backwards - tieing app server into OSUser). > - Overcomes one of the blockers to true J2EE portability > - As we're already seeing from JIRA (http://www.atlassian.com/beta/jira) > this is EXTREMELY useful. JIRA is written ontop of OSUser for user mgt, a= nd > already it runs on JBoss, Orion and almost on Weblogic. And people can st= ore > their users in LDAP, EJBs, direct JDBC etc - separate from their app serv= er > choice! > - Potentially something that needs to be replicated for Transaction > management / obtaining (there seems to be no generic way to obtain a TX > within an app server?) >=20 > OSCACHE > - Started as a post processed JSP caching system, it's now a much more > flexible generic object caching system that's got very widespread use > - Definitely the most popular and one of the oldest components - written = up > in JavaWorld etc, thousands of downloads etc. > - Something else I feel we could integrate very easily (if you use JSPs o= r > Velocity, it's great for speed) >=20 > SITEMESH > - Presentation system that follows the GoF decorator pattern, separates > presentation from simple content at the page and panel/portlet level > - Requires Servlet 2.3 > - Second most used OS component > - I use it on every project and it's already got some WW integration bits > done by Victor >=20 >=20 > Adding WebWork would mean the entire 'suite' covered core component > structure, control flow, caching, presentation and user management. Seems= to > fit quite nicely? >=20 >=20 > Ok, well that's my piece - if you read this far it means it can't have be= en > that boring :) I'm not sure how to progress further - I canvassed 5 of 6 = OS > core developers yesterday and all were in favour from our end so the ball= is > in your court I guess? >=20 > -mike >=20 > PS If anyone has questions and wants to ask off list, feel free - > mi...@at... > PPS If the decision is to merge, I'd suggest AFTER webwork 1.0 - no great > reason to refactor already working code - release early, release often! > PPPS And I'd suggest a 'slow' merge - common website initially, slow code > cross pollination, thought exchange etc. >=20 > On 12/2/02 6:27 AM, "ma...@sm..." (ma...@sm...) penned the > words: >=20 >> If the merge was done right, there could be obvious benefits - developer= s, >> users, code resuse, etc. The challenges I see is that there is overlap >> between >> the two projects which is confusing and I'm concerned that WW will get l= ost >> amongst the other modules. Ideally, the merge would require some refacto= ring. >> For instance, WW would utilize modules from OpenSymphony; i.e., BeanUtil= , >> etc. >> This would definitely require refactoring but would be of great benefit = to >> users and developers. We would need uniform documentation, best practice= s, >> better examples, etc. >>=20 >> If we just merge as is now, I say no. It only brings confusion to most >> developers. The more advanced developers will mix and match on their own >> anyway. >>=20 >> -Matt >>=20 >> On Mon, 11 February 2002, Rickard wrote: >>=20 >>>=20 >>> WebWorkers, >>>=20 >>> I just got this from OpenSymphony. It's an interesting proposal, but I'= d >>> like to hear your input whether you think it's good or not. What are th= e >>> pro's and con's? >>>=20 >>> regards, >>> Rickard >>>=20 >>> ps. Those of you who are already involved with OS, please state this >>> when voicing your opinion on this. >>>=20 >>> --=20 >>> Rickard =D6berg >>> Author of "Mastering RMI" >>> Chief Architect, TheServerSide.com >>> The Middleware Company - We Build Experts! >>=20 >> _______________________________________________ >> Webwork-devel mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/webwork-devel >=20 >=20 > _______________________________________________ > Opensymphony-developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers |
|
From: <Jim...@do...> - 2002-02-11 21:02:07
|
I feel that WebWork is synergistic with many technologies, such as Velocity, OSCache, JSP, etc. I also tend to think of "core" WebWork consisting of the ServletDispatcher and patterns built upon the ActionFactory. The JSP tag libraries to me are a secondary "value-added" technology that is not intregral to WebWork. Much the same way that Velocity is a "value-add". I think the decision to further integrate OSxxx would depend on where the integration point is. If it is outside the true core of WebWork (the dispatcher), then I see it as a simple "value-add", and not important to the "merging" discussion from a technical vantage point. I haven't looked at the OSxxx technology, so I'm not sure where this integration point is. From a community and exposure standpoint, I wonder who would be helping whom more here. It really doesn't matter since there is good will involved and the control of either project isn't in question. I'm not recommending this, but if you wanted to extend your user base, it would be far more "profitable" to team with the Apache group and the Velocity sub-project. It's a kick-ass development environment when combined with WebWork, and I get the feeling that its development community is far greater than OS and WebWork combined. There are a lot of whack personalities over there, though. jim |
|
From: Toby H. <tob...@ho...> - 2002-02-11 23:53:38
|
OK, This is probably out of line, as I am just a lurker and user of webwork, but I would have similar concerns...small groups achieve more faster, and if you look at WW as providing a core service with value-added features then there is not that compelling an argument to 'merge'...the major issue i would see is loss of control. from my point of view (as a fairly new convert), WW is good because it is small, cohesive and relatively easy to learn...the core package is elegant and the value-added features are good for particular re That said, closer ties are always a good thing, however, and there are features of OS that are definitely worth integrating with WW. Close relationships will help get these features sooner and assist in adapting to changes in either codebase as they evolve. cheers, toby >From: Jim...@do... >To: webwork-devel <web...@li...> >Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 16:01:59 -0500 > >I feel that WebWork is synergistic with many technologies, such as >Velocity, OSCache, JSP, etc. > >I also tend to think of "core" WebWork consisting of the ServletDispatcher >and patterns built upon the ActionFactory. The JSP tag libraries to me are >a secondary "value-added" technology that is not intregral to WebWork. >Much the same way that Velocity is a "value-add". > >I think the decision to further integrate OSxxx would depend on where the >integration point is. If it is outside the true core of WebWork (the >dispatcher), then I see it as a simple "value-add", and not important to >the "merging" discussion from a technical vantage point. I haven't looked >at the OSxxx technology, so I'm not sure where this integration point is. > > >From a community and exposure standpoint, I wonder who would be helping >whom more here. It really doesn't matter since there is good will involved >and the control of either project isn't in question. I'm not recommending >this, but if you wanted to extend your user base, it would be far more >"profitable" to team with the Apache group and the Velocity sub-project. >It's a kick-ass development environment when combined with WebWork, and I >get the feeling that its development community is far greater than OS and >WebWork combined. There are a lot of whack personalities over there, >though. > >jim > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Toby H. <tob...@ho...> - 2002-02-11 23:53:43
|
OK, This is probably out of line, as I am just a lurker and user of webwork, but I would have similar concerns...small groups achieve more faster, and if you look at WW as providing a core service with value-added features then there is not that compelling an argument to 'merge'...the major issue i would see is loss of control. from my point of view (as a fairly new convert), WW is good because it is small, cohesive and relatively easy to learn...the core package is elegant and the value-added features are good for particular re That said, closer ties are always a good thing, however, and there are features of OS that are definitely worth integrating with WW. Close relationships will help get these features sooner and assist in adapting to changes in either codebase as they evolve. cheers, toby >From: Jim...@do... >To: webwork-devel <web...@li...> >Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 16:01:59 -0500 > >I feel that WebWork is synergistic with many technologies, such as >Velocity, OSCache, JSP, etc. > >I also tend to think of "core" WebWork consisting of the ServletDispatcher >and patterns built upon the ActionFactory. The JSP tag libraries to me are >a secondary "value-added" technology that is not intregral to WebWork. >Much the same way that Velocity is a "value-add". > >I think the decision to further integrate OSxxx would depend on where the >integration point is. If it is outside the true core of WebWork (the >dispatcher), then I see it as a simple "value-add", and not important to >the "merging" discussion from a technical vantage point. I haven't looked >at the OSxxx technology, so I'm not sure where this integration point is. > > >From a community and exposure standpoint, I wonder who would be helping >whom more here. It really doesn't matter since there is good will involved >and the control of either project isn't in question. I'm not recommending >this, but if you wanted to extend your user base, it would be far more >"profitable" to team with the Apache group and the Velocity sub-project. >It's a kick-ass development environment when combined with WebWork, and I >get the feeling that its development community is far greater than OS and >WebWork combined. There are a lot of whack personalities over there, >though. > >jim > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Toby H. <tob...@ho...> - 2002-02-11 23:53:43
|
OK, This is probably out of line, as I am just a lurker and user of webwork, but I would have similar concerns...small groups achieve more faster, and if you look at WW as providing a core service with value-added features then there is not that compelling an argument to 'merge'...the major issue i would see is loss of control. from my point of view (as a fairly new convert), WW is good because it is small, cohesive and relatively easy to learn...the core package is elegant and the value-added features are good for particular re That said, closer ties are always a good thing, however, and there are features of OS that are definitely worth integrating with WW. Close relationships will help get these features sooner and assist in adapting to changes in either codebase as they evolve. cheers, toby >From: Jim...@do... >To: webwork-devel <web...@li...> >Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 16:01:59 -0500 > >I feel that WebWork is synergistic with many technologies, such as >Velocity, OSCache, JSP, etc. > >I also tend to think of "core" WebWork consisting of the ServletDispatcher >and patterns built upon the ActionFactory. The JSP tag libraries to me are >a secondary "value-added" technology that is not intregral to WebWork. >Much the same way that Velocity is a "value-add". > >I think the decision to further integrate OSxxx would depend on where the >integration point is. If it is outside the true core of WebWork (the >dispatcher), then I see it as a simple "value-add", and not important to >the "merging" discussion from a technical vantage point. I haven't looked >at the OSxxx technology, so I'm not sure where this integration point is. > > >From a community and exposure standpoint, I wonder who would be helping >whom more here. It really doesn't matter since there is good will involved >and the control of either project isn't in question. I'm not recommending >this, but if you wanted to extend your user base, it would be far more >"profitable" to team with the Apache group and the Velocity sub-project. >It's a kick-ass development environment when combined with WebWork, and I >get the feeling that its development community is far greater than OS and >WebWork combined. There are a lot of whack personalities over there, >though. > >jim > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel > _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Toby H. <tob...@ho...> - 2002-02-12 00:05:08
|
OK, This is probably out of line, as I am just a lurker and user of webwork, but I would have similar concerns...small groups achieve more faster, and if you look at WW as providing a core service with value-added features then there is not that compelling an argument to 'merge'...the major issue i would see is loss of control. from my point of view (as a fairly new convert), WW is good because it is small, cohesive and relatively easy to learn...the core package is elegant and the value-added features are good for particular re That said, closer ties are always a good thing, however, and there are features of OS that are definitely worth integrating with WW. Close relationships will help get these features sooner and assist in adapting to changes in either codebase as they evolve. cheers, toby >From: Jim...@do... >To: webwork-devel <web...@li...> >Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 16:01:59 -0500 > >I feel that WebWork is synergistic with many technologies, such as >Velocity, OSCache, JSP, etc. > >I also tend to think of "core" WebWork consisting of the ServletDispatcher >and patterns built upon the ActionFactory. The JSP tag libraries to me are >a secondary "value-added" technology that is not intregral to WebWork. >Much the same way that Velocity is a "value-add". > >I think the decision to further integrate OSxxx would depend on where the >integration point is. If it is outside the true core of WebWork (the >dispatcher), then I see it as a simple "value-add", and not important to >the "merging" discussion from a technical vantage point. I haven't looked >at the OSxxx technology, so I'm not sure where this integration point is. > > >From a community and exposure standpoint, I wonder who would be helping >whom more here. It really doesn't matter since there is good will involved >and the control of either project isn't in question. I'm not recommending >this, but if you wanted to extend your user base, it would be far more >"profitable" to team with the Apache group and the Velocity sub-project. >It's a kick-ass development environment when combined with WebWork, and I >get the feeling that its development community is far greater than OS and >WebWork combined. There are a lot of whack personalities over there, >though. > >jim > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
|
From: Toby H. <tob...@ho...> - 2002-02-12 00:14:34
|
sorry everyone, not only did i provide an audacious opinion i have no real right to share, but i did it 4 times! and it wasn't even complete. bloody hotmail client. that will learn me toby >From: "Toby Hede" <tob...@ho...> >Reply-To: tob...@in... >To: web...@li... >Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >Date: Mon, 11 Feb 2002 23:53:24 +0000 > >OK, > >This is probably out of line, as I am just a lurker and user of webwork, >but >I would have similar concerns...small groups achieve more faster, and if >you >look at WW as providing a core service with value-added features then there >is not that compelling an argument to 'merge'...the major issue i would see >is loss of control. > >from my point of view (as a fairly new convert), WW is good because it is >small, cohesive and relatively easy to learn...the core package is elegant >and the value-added features are good for particular re > >That said, closer ties are always a good thing, however, and there are >features of OS that are definitely worth integrating with WW. Close >relationships will help get these features sooner and assist in adapting to >changes in either codebase as they evolve. > > > >cheers, >toby > > > > > >>From: Jim...@do... >>To: webwork-devel <web...@li...> >>Subject: Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony] >>Date: Mon, 11 Feb 2002 16:01:59 -0500 >> >>I feel that WebWork is synergistic with many technologies, such as >>Velocity, OSCache, JSP, etc. >> >>I also tend to think of "core" WebWork consisting of the ServletDispatcher >>and patterns built upon the ActionFactory. The JSP tag libraries to me are >>a secondary "value-added" technology that is not intregral to WebWork. >>Much the same way that Velocity is a "value-add". >> >>I think the decision to further integrate OSxxx would depend on where the >>integration point is. If it is outside the true core of WebWork (the >>dispatcher), then I see it as a simple "value-add", and not important to >>the "merging" discussion from a technical vantage point. I haven't looked >>at the OSxxx technology, so I'm not sure where this integration point is. >> >> >From a community and exposure standpoint, I wonder who would be helping >>whom more here. It really doesn't matter since there is good will involved >>and the control of either project isn't in question. I'm not recommending >>this, but if you wanted to extend your user base, it would be far more >>"profitable" to team with the Apache group and the Velocity sub-project. >>It's a kick-ass development environment when combined with WebWork, and I >>get the feeling that its development community is far greater than OS and >>WebWork combined. There are a lot of whack personalities over there, >>though. >> >>jim >> >>_______________________________________________ >>Webwork-devel mailing list >>Web...@li... >>https://lists.sourceforge.net/lists/listinfo/webwork-devel >> > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > >_______________________________________________ >Webwork-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webwork-devel > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X