You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/12/27 13:56:27 UTC
Avalon Components (Re: Our site is too big)
Berin Loritsch wrote:
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
[...]
> If you are looking at consolidating everything down into both:
>
> avalon
> avalon-sandbox
>
> then I am +1.
ok, same here.
> We should look at moving each project to a final resting place.
> If that is in "avalon", great. If it is in "apache-commons" or
> "jakarta-commons", great. If it is kept, great.
>
> We just need to look at the things piece by piece.
Yes, I agree.
I think that we should now decide where to put the Avalon components, if
in Apache Commons or Avalon Components.
I'm mildly in favor for avalon-components, where to put cornerstone and
excalibur components, and give access to all projects that have a
representative in our PMC (as discussed for outer-avalon people in the
PMC).
For example, now James has patched the cornerstone code to fix it for
them (and they did the right thing). It would have been easier for them
to be able to access a common repository of components for Avalon projects.
Same problem for Cocoon components in excalibur, that were once in the
Cocoon codebase.
Practically, it would mean that we have a Avalon Components subproject,
with the same committers of Avalon plus others from external project
that use our components (rules to be defined)
The CVS module would be avalon-components, and it would keep what now
are excalibur and cornerstone components, and the new components in
Avalon 5 when they come.
Or simply decide to open to these committers excalibur and cornerstone
CVS, as legacy code of the components project.
> Having the site shaped up on the new avalon CVS repo makes alot
> of sense.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Components (Re: Our site is too big)
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
> I think that we should now decide where to put the Avalon components,
> if in Apache Commons or Avalon Components.
>
> I'm mildly in favor for avalon-components, where to put cornerstone
> and excalibur components, and give access to all projects that have a
> representative in our PMC (as discussed for outer-avalon people in the
> PMC).
It is my understanding that the notion of an avalon-components is out of
scope of the Avalon Project.
RESOLVED, that the Avalon PMC be and hereby is responsible
for the creation and maintenance of software related to
component and service management, based on software licensed
to the Foundation;
Resolution of the conflict between this position and the existing
Cornerstone and Apps CVS is addressed under the resolution:
RESOLVED, that the initial Avalon PMC be and hereby is tasked
with the migration and rationalization of the Jakarta PMC
Avalon subproject;
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Components (Re: Our site is too big)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>> I think that we should now decide where to put the Avalon components,
>> if in Apache Commons or Avalon Components.
>
>
> I'm (still) strongly in favour of a _common_ repository for _common_
> components, in that all of Jakarta Commons, and Apache Commons, and
> Avalon Commons, and Turbine Commons, and <whatever> Commons is the same
> common repository. It Just Makes Sense(tm).
>
> CVS access is not the issue (if it works @ apache as it works for me at
> work, it is the simple editing of one file). What we need is community
> unification (to the extend feasible).
Yes, this last sentence is a very important point.
<mumble>
My "fear" is that moving these in Apache Commons now is going to
destabilize the community.
Now that I write it, it seems probably silly... it could do the opposite.
I was always pro-common-common, but now I have a bit of fear in
"relinquishing control" of the components.
</mumble>
Ok, we have explored a bit the possibility of having an Apache Avalon
Components project.
What would you guys think about the real possibility of moving our
components to Apache Commons?
The proposal would be the same, but under the Avalon Commons project:
"
I think it is important to separate container/framework and
components. I also think that we should use Scratchpad/Components
like Jakarta Commons. I.e.: Any Apache committer should have
Karma for the Scratchpad CVS. The ones actively maintaining
the component code shoul be granted karma to Component.
* That means that *anyone* can do scratchpad stuff.
* It also means that someone who is maintaining components is not
necessarily an Avalon committer.
* It also means that not just *anyone* can alter the released
components--they have to demonstrate the ability to maintain it.
"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Components (Re: Our site is too big)
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
> I think that we should now decide where to put the Avalon components, if
> in Apache Commons or Avalon Components.
I'm (still) strongly in favour of a _common_ repository for _common_
components, in that all of Jakarta Commons, and Apache Commons, and
Avalon Commons, and Turbine Commons, and <whatever> Commons is the same
common repository. It Just Makes Sense(tm).
CVS access is not the issue (if it works @ apache as it works for me at
work, it is the simple editing of one file). What we need is community
unification (to the extend feasible).
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Components (Re: Our site is too big)
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>>
>>I am -100 on any CVS depot being called plainly 'avalon'.
>>Why? Our users (and sister-project
>>developers) have been confused as hell for years on what
>>Avalon is, and how it differentiates from
>>Framework and Phoenix.
>>
>>Pease...
>>
>>'Avalon' is just a site name now.
>>
>>
>
>
>Paul. We are narrowing what Avalon is. In A5, there will be
>one client spec (Framework), and one Container. There will
>also be the compliance test framework. It won't be that hard
>to explain what Avalon is because it will be much simpler.
>
>I don't want to be in the place where we have 9 CVS repos at
>the end of the day. The "phoenix"/"framework"/"Fortress"/etc.
>projects can have their own directory structure at the root
>of "avalon"--but please let's simplify.
>
>The trick is not to explain "Framework", "Excalibur", "Cornerstone"
>"Phoenix", "Site", "LogKit", "Apps", etc. That is too much.
>Only explain that Avalon = Container + Components.
>
>The reason everyone is "confused as hell" is because we have
>so much going on. Are we a tool supplier? Are we a component
>provider? Are we a set of containers? Are we a logging utility
>supplier?
>
>One of the reasons we have gotten into trouble in the past is that
>we have every one of those things going on. Avalon always has
>been and always will be centered on Component Oriented Programming,
>with a set of component and container contracts. That is what
>Avalon is. All the other stuff is cruft that muddied the waters.
>
>We added the Logging ToolKit because at the time there wasn't
>one available that support IOC. Log4J is out, and JDK logging,
>and they both function the same way. We have demonstrated that
>we can still provide loggers to the components, even if the
>underlying logging toolkit is not built that way. In the end,
>we really don't need to host LogKit anymore. Don't get me
>wrong, its a really nice logging toolkit, but now it only serves
>to dilute our "brand".
>
>We added our containers because components are fairly hard to use
>without them. The only problem is that we have several different
>containers. Again, we dilute our "brand" and our users are left
>guessing which one to use in their next project. They all are
>built on certain presumptions. Our new effort will try (to the
>best of its ability) to remove the need for many presumptions,
>and pull the best efforts from each of the container projects.
>
>We added utility code because we needed it for our projects. The
>utility code became useful in its own right, and really didn't
>need Avalon to function. Instead of placing those utilities in
>a project designed for them, we maintained them here. Now, noone
>can tell what Excalibur is meant to be.
>
>The problem is that we have allowed ourselves to grow unchecked.
>We need to learn to look outside ourselves to see if someone
>else is solving problems we have in our core project which is
>the component/container relationship (ref implementation and
>client code). if we develop the code and donate it to other
>projects that is fine. We haven't diluted what makes Avalon
>what it is.
>
>People can understand that J2EE is a spec. That spec has a
>reference implementation, and there are alternatives in the
>marketplace. We need to position ourselves the same way with
>Avalon. It makes it *really* easy to explain, and it stops
>the confusion for most people.
>
>
+1
Well stated.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Components (Re: Our site is too big)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> I am -100 on any CVS depot being called plainly 'avalon'.
> Why? Our users (and sister-project
> developers) have been confused as hell for years on what
> Avalon is, and how it differentiates from
> Framework and Phoenix.
>
> Pease...
>
> 'Avalon' is just a site name now.
Paul. We are narrowing what Avalon is. In A5, there will be
one client spec (Framework), and one Container. There will
also be the compliance test framework. It won't be that hard
to explain what Avalon is because it will be much simpler.
I don't want to be in the place where we have 9 CVS repos at
the end of the day. The "phoenix"/"framework"/"Fortress"/etc.
projects can have their own directory structure at the root
of "avalon"--but please let's simplify.
The trick is not to explain "Framework", "Excalibur", "Cornerstone"
"Phoenix", "Site", "LogKit", "Apps", etc. That is too much.
Only explain that Avalon = Container + Components.
The reason everyone is "confused as hell" is because we have
so much going on. Are we a tool supplier? Are we a component
provider? Are we a set of containers? Are we a logging utility
supplier?
One of the reasons we have gotten into trouble in the past is that
we have every one of those things going on. Avalon always has
been and always will be centered on Component Oriented Programming,
with a set of component and container contracts. That is what
Avalon is. All the other stuff is cruft that muddied the waters.
We added the Logging ToolKit because at the time there wasn't
one available that support IOC. Log4J is out, and JDK logging,
and they both function the same way. We have demonstrated that
we can still provide loggers to the components, even if the
underlying logging toolkit is not built that way. In the end,
we really don't need to host LogKit anymore. Don't get me
wrong, its a really nice logging toolkit, but now it only serves
to dilute our "brand".
We added our containers because components are fairly hard to use
without them. The only problem is that we have several different
containers. Again, we dilute our "brand" and our users are left
guessing which one to use in their next project. They all are
built on certain presumptions. Our new effort will try (to the
best of its ability) to remove the need for many presumptions,
and pull the best efforts from each of the container projects.
We added utility code because we needed it for our projects. The
utility code became useful in its own right, and really didn't
need Avalon to function. Instead of placing those utilities in
a project designed for them, we maintained them here. Now, noone
can tell what Excalibur is meant to be.
The problem is that we have allowed ourselves to grow unchecked.
We need to learn to look outside ourselves to see if someone
else is solving problems we have in our core project which is
the component/container relationship (ref implementation and
client code). if we develop the code and donate it to other
projects that is fine. We haven't diluted what makes Avalon
what it is.
People can understand that J2EE is a spec. That spec has a
reference implementation, and there are alternatives in the
marketplace. We need to position ourselves the same way with
Avalon. It makes it *really* easy to explain, and it stops
the confusion for most people.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Components (Re: Our site is too big)
Posted by Paul Hammant <pa...@yahoo.com>.
Folks,
> > avalon
> > avalon-sandbox
> >
I am -100 on any CVS depot being called plainly 'avalon'. Why? Our users (and sister-project
developers) have been confused as hell for years on what Avalon is, and how it differentiates from
Framework and Phoenix.
Pease...
'Avalon' is just a site name now.
avalon-framework is where the framework is built
avalon-site (like jakarta) is where the site is built
avalon-phoenix is the new home for phoenix.
avalon-sandox is where experimental projects are homed.
avalon-xyz123 is where new projects are mounted.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Components (Re: Our site is too big)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> I think that we should now decide where to put the Avalon
> components, if
> in Apache Commons or Avalon Components.
>
> :P Careful now, we need to protect from feature creep
;-)
Yeah, you are :-P, but we both know how serious this is.
>>I'm mildly in favor for avalon-components, where to put
>>cornerstone and
>>excalibur components, and give access to all projects that have a
>>representative in our PMC (as discussed for outer-avalon
>>people in the
>>PMC).
>
> As long as avalon-components is designed to have a different
> set of CVS privs, then +1. If we are limiting it to Avalon
> developers, then -1. We should only use different CVS repositories
> when there are different permissions involved.
Yes, I totally agree.
> I think it is important to separate container/framework and
> components. I also think that we should use Scratchpad/Components
> like Jakarta Commons. I.e.: Any Apache committer should have
> Karma for the Scratchpad CVS. The ones actively maintaining
> the component code shoul be granted karma to Component.
>
> * That means that *anyone* can do scratchpad stuff.
> * It also means that someone who is maintaining components is not
> necessarily an Avalon committer.
> * It also means that not just *anyone* can alter the released
> components--they have to demonstrate the ability to maintain it.
> * Lastly, and most importantly, it means we have to be *really*
> careful about scope creep.
Very good summary. I agree totally.
> I think that Avalon Components should be *strictly* components.
> No containers, no utility code, just components. Scratchpad can
> be used as a breeding ground for new ideas--but it does not
> guarantee promotion to Avalon Components or Avalon proper.
Definately. I couldn't have said it better.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Components (Re: Our site is too big)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> I think that we should now decide where to put the Avalon
> components, if
> in Apache Commons or Avalon Components.
:P Careful now, we need to protect from feature creep
> I'm mildly in favor for avalon-components, where to put
> cornerstone and
> excalibur components, and give access to all projects that have a
> representative in our PMC (as discussed for outer-avalon
> people in the
> PMC).
As long as avalon-components is designed to have a different
set of CVS privs, then +1. If we are limiting it to Avalon
developers, then -1. We should only use different CVS repositories
when there are different permissions involved.
I think it is important to separate container/framework and
components. I also think that we should use Scratchpad/Components
like Jakarta Commons. I.e.: Any Apache committer should have
Karma for the Scratchpad CVS. The ones actively maintaining
the component code shoul be granted karma to Component.
* That means that *anyone* can do scratchpad stuff.
* It also means that someone who is maintaining components is not
necessarily an Avalon committer.
* It also means that not just *anyone* can alter the released
components--they have to demonstrate the ability to maintain it.
* Lastly, and most importantly, it means we have to be *really*
careful about scope creep.
I think that Avalon Components should be *strictly* components.
No containers, no utility code, just components. Scratchpad can
be used as a breeding ground for new ideas--but it does not
guarantee promotion to Avalon Components or Avalon proper.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>