You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@gmail.com> on 2004/09/27 22:08:55 UTC

Compromise: Code Transfer

> I know I don't contribute much to the project. I am merely a user 
> that began using Avalon recently. I hope to become a contributor 
> to the project, but for now, I'm not. So, it's probably not really
> my place to make any comments here.

Wrong. Unless you speak, how can anyone listen to you?

I'll start with a brief overview of Avalon's history, as much for
David's benefit as for my argument. (OK, David, here's some context
for you):

At the beginning (for our purposes, although the history goes further
back than this) we had Avalon Framework (the classes in
org.apache.avalon.framework.*) plus some other code. That code
included Excalibur, which is a package of components and component
managers - utility classes and a toolkit for building applications
with avalon. It also included Phoenix, which is roughly the same type
of application - an application server - that the standalone,
command-line-launched Merlin is today. I'm not saying they are
equivalent, but they play similar roles.

This was all before Merlin was created.

Some projects used Phoenix and Framework, some used Excalibur and
Framework. For examples of the former, see james.apache.org, for
example of the latter, see cocoon.apache.org.

Fast forward a bit, and a guy named Stephen McConnell creates Merlin.

The purpose of this is to show you that Avalon is much bigger and used
more wider used than Merlin. Merlin isn't all of Avalon, and Merlin
users are a *minority* of all Avalon users. Finally, when you say that
"What has impressed me most about Steve is that he is really concerned
with the project's users" you pretty much hit the nail on the head in
one important aspect that you are not even aware of yourself. And
that's what this discussion is all about.

Merlin is a path that diverges from the path chosen by those of us in
the "old guard" - the bunch of people dependent on Cocoon and other
pre-Merlin architectures.

Now for my personal thoughts: I think that your equating of "Merlin
User" with "Avalon User" precisely captures the problem I have. It is
the thought that what is good for Merlin is good for Avalon, and if
you non-Merliners don't get that, then tough. I think that the support
and concern that has been given to those of us who don't share
Stephen's vision has been abysmal, even though we have done concession
after concession, in order to enable the vision of Avalon Planet.

                                       -oOo-

Now for the compromise:

You want to evolve Merlin into Avalon Planet. I want a stable
Framework 4.x. My suggestion is this:

 + Framework 4.x moves to excalibur.apache.org. No package renames or
class renames.

 + You bump Framework to 5.0.

You can replace 4.x and 5.0 with some other version numbers, maybe
4.2.x and 4.5 or what have you.

This gives you 100% flexibility to do whatever you want. To "just get
on with it". It gives me (and I think Berin as well) the stability we
need to drop out of Avalon completely, and stop wasting our and your
time.

How about it?

/LS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Compromise: Code Transfer

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 29 September 2004 01:23, Leo Sutic wrote:

> So, are we good go to for a PMC vote on this, to get the formalities done?

Nice try. :o)  
I wish I could help...

Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Compromise: Code Transfer

Posted by Leo Sutic <le...@gmail.com>.
On Tue, 28 Sep 2004 19:45:09 +0800, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Tuesday 28 September 2004 19:06, Leo Sutic wrote:
> 
> > Excalibur (and I) will take care of 4.x. We'll support it. It has a
> > huge installed base, and we're extremely wary of rocking the boat the
> > slightest (read: in case of having to save the world we might call a
> > vote).
(...) 
> Meaning, I have personally no problem with AF in Excalibur and Merlin use it
> as it is, and how it may or may not evolve.
> 
> The same goes for LogKit.

So, are we good go to for a PMC vote on this, to get the formalities done?

/LS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Compromise: Code Transfer

Posted by Leif Mortenson <le...@tanukisoftware.com>.
Niclas Hedhman wrote:

>The same goes for LogKit. Personally, I won't use it in production 
>installations, and would like to transfer the technology to where I think it 
>belongs, the Logging project. I would also suggest that those who do 
>understand, use and evolves it further to follow as committers to the 
>codebase over there, and possibly be an asset in the upcoming unification 
>logging API that Ceki is slowly looking into.
>  
>
I would actually prefer to have LogKit transferred to Excalibur as 
well.   I like it much more
than Log4j and would actually prefer to keep it alive as its own tool.   
That should not
preclude a merging of features into Log4j.

Cheers,
Leif


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Compromise: Code Transfer

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 28 September 2004 19:06, Leo Sutic wrote:

> Excalibur (and I) will take care of 4.x. We'll support it. It has a
> huge installed base, and we're extremely wary of rocking the boat the
> slightest (read: in case of having to save the world we might call a
> vote). 

I am not at all foreign to the concept that AF is not evolved here at all, and 
actually thinks it is a genuinely good idea (besides the naming vs home 
aspect feels awkward).
Meaning, I have personally no problem with AF in Excalibur and Merlin use it 
as it is, and how it may or may not evolve.

The same goes for LogKit. Personally, I won't use it in production 
installations, and would like to transfer the technology to where I think it 
belongs, the Logging project. I would also suggest that those who do 
understand, use and evolves it further to follow as committers to the 
codebase over there, and possibly be an asset in the upcoming unification 
logging API that Ceki is slowly looking into.

Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Compromise: Code Transfer

Posted by Leo Sutic <le...@gmail.com>.
On Mon, 27 Sep 2004 18:04:49 -0400, Noel J. Bergman <no...@devtech.com> wrote:
> Leo Sutic wrote:
> > Merlin is a path that diverges from the path chosen by
> > those of us in the "old guard" - the bunch of people
> > dependent on Cocoon and other pre-Merlin architectures.
> 
> > You want to evolve Merlin into Avalon Planet. I want a stable
> > Framework 4.x.
> 
> >  + Framework 4.x moves to excalibur.apache.org. No package
> >    renames or class renames.
> 
> >  + You bump Framework to 5.0.
> 
> According to Niclas, there are no anticipated changes to Framework.  But if
> we need to do so, we can easily branch Framework.

Framework isn't just the interfaces, it's implementations as well.
There are no anticipated changes to the interfaces, but we must always
anticipate changes to the implementations due to bugfixes etc.

It is easy to say that we can branch framework, but there are issues
to be worked out - version numbers and so on. I want to do that *now*,
so that I won't have to when I really need to fix framework in some
way. I have time for this discussion now, but I may not later.

That is, branch now, and save later blood sweat and tears.

Or, since I don't view it as branching - call it legacy support.
Branching implies that AF4 will keep evolving. It probably won't. All
container/component exploration appears to be in the field of
constructor / bean-style injection - not in frameworks like Avalon.

Excalibur (and I) will take care of 4.x. We'll support it. It has a
huge installed base, and we're extremely wary of rocking the boat the
slightest (read: in case of having to save the world we might call a
vote). Meanwhile, you can start AF5 and do whatever you want to pursue
your dreams. Keep it backwards compatible, if you want to. But you
don't have to.

/LS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


RE: Compromise: Code Transfer

Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo Sutic wrote:
> Merlin is a path that diverges from the path chosen by
> those of us in the "old guard" - the bunch of people
> dependent on Cocoon and other pre-Merlin architectures.

> You want to evolve Merlin into Avalon Planet. I want a stable
> Framework 4.x.

>  + Framework 4.x moves to excalibur.apache.org. No package
>    renames or class renames.

>  + You bump Framework to 5.0.

According to Niclas, there are no anticipated changes to Framework.  But if
we need to do so, we can easily branch Framework.

What about other aspects of "Avalon Classic"?  Cornerstone, et al?  Who is
going to maintain those?  Exalibur or Avalon?  And are you suggesting that
Merlin stay in Avalon, rather than Metro?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org