Re: [Opensymphony-developers] Re: [Webwork-devel] [Fwd: WebWork - OpenSymphony]

[Hani S. <ha...@fo...>]

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