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

[Mike Cannon-B. <mi...@at...>]

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