> At 08:33 23/3/01 -0500, Geir Magnusson Jr. wrote:
>>> >However, this is a really good point and a discussion we should have in
>>> >Commons-land. Please come and join if interested.
>>>
>>> yes and after that you really should standardize on logging. Oh and then
>>> standardize on lifecycle because thats important too.
>>
>>Not really sure a bean utility library/component will need lifecycle and
>>logging, nor configuration for that matter
>
> I am not even sure how to answer this? I am not sure if you are serious or
> not.
>
>>A Database Connection Pool is another story, but we can look a the
>>17,000 or so implementations already in Jakarta and find the best
>>practice, and then punt and use log4j :)
>
> Adopt log4j, block avalon/james/cocoon from using component and presumably
> taglib/struts when they adopt the J2EE standard. Way to achieve sharing !
>
>>> ! How long do you think before my final prediction bears true? If already
>>> you are talking about "standardisation" when that was explicitly one of the
>>> non-goals then ...
>>
>>With this kind of FUD, you should have been in software marketing :)
>
> Whats the FUD about it? One of the non-goals was to not devolve into a
> framework. For any semi-complex problem domain you need some support
> (unless you invent your own for that component). And if you have 50
> components with 50 different sets of internal frameworks then...
>
I'm not getting into this formative discussion. I just want to point
something that came to mind while reading it:
The iCalendar module, that originally was a part of jetspeed code base,
is currently orphan. While it is a reasonable size component, it looks
like a good part of commons, if I understood correctly the discussion:
- most of it is a collection of classes implementing the different vCal
entities.
- I don't know from memory if it is designed a bean, but it could be
made into one easily.
- No control, no log: just new ICal(), new VToDo, ...
- marshal will write a VCALENDAR into a writer
- There is a mechanism for db persistence, though
You can contact with Jeff Pricket about it, if you are interested in
helping finishing it.
I'm lobbying for this project because, even if I don't have currently
the time to get involved, I feel that such a set of objects and
underlying webapp will be crucial for jetspeed, and possibly turbine and
cocoon, to survive in a corporate environment (is this our goal? :) )
Think something like ASP portal, or intranet collaborative tasks. I'm
not aware of any Open vCalendar implementation.
Disclaimer: I'm just plugging my lines. I will not go into discussion
on which is the better strategy to deal with modules, etc. I see valid
points in both (7?) sides of the discussion. :)
Hope the input is useful.
Regards,
Santiago Gala
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
