Peter Donald wrote:
>
> 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.
No, I wasn't. You don't worry about logging issues for
'StringTokenizer', for example...
> >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 !
I wasn't serious there either.
However, if you've decided that you aren't going to participate in
Commons, or at least give advice and participate in these kinds of
discussions that you are *clearly* interested in, then I won't be
surprised if things aren't out-of-the-box compatible with Avalon.
This isn't supposed to be another monolithic cabal.
> >> ! 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...
What FUD? For a 3 day old project that just got approved and is working
to get code contributions and projects started, that is trying to smooth
out some wrinkles in an organization that is a slight departure from the
current Jakarta convention, you have been pretty vocal in declaring the
thing a total failure because of the lurking, dreaded 'standardisation'
issues, for example.
I imagine some of the 'components' will be real basic simple stuff, not
requiring a 'framework'. I mean, what kind of framework do you need
around collections classes?
Jason has been working hard on an improved Properties-like class
that is used in Velocity and Turbine, and we were talking about that as
a proposal. Need logging?
And yes, some stuff might be big enough where these concerns about the
framework issues *are* valid, and then we have to work that out. I
don't think it's right to just declare defeat and go home, though.
> >I wasn't suggesting that we should *standardize* on anything, but rather
> >*discuss* how something like this can be realized since it appears to be
> >an important issue if we want to succeed in our goal
>
> You mean discuss a strategy that components should conform to so as to
> interact with other frameworks? ... And if components don't implement this
> strategy (aka standard) do they go straight to jail without passing go and
> without collecting $200?
No. Let me see what I said exactly :
"My better judgement tells me to dare not suggest how getting a common
configuration pattern for the components might be realized, as I am sure
it will bring howls of derision and scorn regarding central control and
big brother.
However, this is a really good point and a discussion we should have in
Commons-land. Please come and join if interested."
I think all I said was that I noted that the issue is valid, and we
should discuss them in Commons-land. I think that you are reading too
much into this...
I don't want a large set of rules either...
> >which is sharable
> >components, and a place for cross-project collaboration.
>
> If you honestly wanted to achieve sharing you wouldn't have turned off so
> many projects.
How did we turn them off in 3 days of no activity? :) Yesterday, you
declared Commons off limits to everything under the sun, Jon believed
you, and now you claim it as reality?
Declare me to be a millionaire, please...
>
> >There seem to be *plenty* of things that are standardized and
> >successful. The java API, for example. (Can you imagine if we all had
> >to roll our own 'int'?) Household electricity. The alchoholic content
> >of beer...
>
> So you are after standardisation (aka framework) - I see. Glad we cleared
> that up.
Why do you define standardaisation == framework ? Is the line voltage
of house power a 'framework'?
And yes - some standardization and conformance is good. Of the top of
my head :
1) The primary language for development is Java, but not a requirement,
because I am sure there are pieces like the tomcat connectors for apache
et al that need some C/C++/X support.
2) When you release under the Commons project, have a complete jar of
the release available for download.
3) The components must conform to the charters set up by the Jakarta
project and the ASF. (Why else are we here?)
4) The code will be released under the Apache Software license. Ibid.
Disagree with any of this yet? Does any of these suggest a framwork
like Avalon is? (or isn't?) But it is Big Brother setting basic
standards...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
