Hi all,

Chris Custine and David Jencks have been advising the removal of the
configuration beans to
directly wire up components in the server.  I think they're right after
seeing just how many problems
the present configuration bean setup causes.  Also this will not happen
immediately if it does in
one shot.  The progression will be gradual.

However doing this has a huge impact and I want everyone to be aware of
them.  First and foremost
the way users embed the server will change.  The server.xml file will
completely change as well so
this may disappoint our users who have been using 1.5.x releases since they
are more stable than
1.0.x even though 1.5.x is labeled as experimental.

So it is obvious from a technical standpoint that this must be done.  The
remaining question is when.
Should we just get 2.0 out ASAP so users have something and start
immediately on a 2.5?  So this
is a question that our users and team must answer.  If yes then we need to
figure out what to stuff
into 2.0 before it goes out.  We can even start 2.5 in a separate branch
before 2.0 is out the door if
people want to just go hog wild with these changes yet brace our users from
them.

Thoughts?

Alex

[ Post a follow-up to this message ]

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> Hi all,
>
> Chris Custine and David Jencks have been advising the removal of the
> configuration beans to
> directly wire up components in the server.  I think they're right after
> seeing just how many problems
> the present configuration bean setup causes.  Also this will not happen
> immediately if it does in
> one shot.  The progression will be gradual.
>
> However doing this has a huge impact and I want everyone to be aware of
> them.  First and foremost
> the way users embed the server will change.  The server.xml file will
> completely change as well so
> this may disappoint our users who have been using 1.5.x releases since
> they are more stable than
> 1.0.x even though 1.5.x is labeled as experimental.
>
> So it is obvious from a technical standpoint that this must be done.  The
> remaining question is when.
> Should we just get 2.0 out ASAP so users have something and start
> immediately on a 2.5?  So this
> is a question that our users and team must answer.  If yes then we need to
> figure out what to stuff
> into 2.0 before it goes out.  We can even start 2.5 in a separate branch
> before 2.0 is out the door if
> people want to just go hog wild with these changes yet brace our users
> from them.


I dislike the idea of maintaining three different branches of the server. I
suggest making this change before releasing 2.0 and writing a complete
"what's changed?" guide.

Thoughts?
>
> Alex
>
>
>
>
>


--
Ersin Er
http://www.ersin-er.name

[ Post a follow-up to this message ]

Yep this is an option too.  Emmanuel has some ideas as well such as writing
translators from old server.xml to
new one.  But I'm not keen on this.

Our problem is we are treating 1.5 branch as if it were a stable branch and
not using it for hard core experimental
work anymore since we're driving users towards it since it just blows
1.0away.  This puts us into the dilemma of
dealing with the woes of users.

I guess we can just say hey this is an experimental branch that you have to
deal with changes to.  WDYT?

Alex

On 9/25/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.o
rg> wrote: 
>
>
> I dislike the idea of maintaining three different branches of the server.
> I suggest making this change before releasing 2.0 and writing a complete
> "what's changed?" guide.
>
> Thoughts? 
>
>
> --
> Ersin Er
> http://www.ersin-er.name

[ Post a follow-up to this message ]

My POV is a little more inclining toward users than experimentations.

I would agree with what Ersin said : if we have to do it, do it before 2.0.

Remember that we will have to provide migration tools for 1.0 -> 2.0
version anyway, data and conf, so if we change the conf only once, we
will save us some energy.

Consider also that we may move to OSGi, so if we inject the new conf
in 2.0, we will have another conf for 3.0 ! I don't see how possibly
we can inject a OSGi compatible conf into 2.0...

For those reasons, I would say : keep 2.0 conf as is, and do
experimentations in a branch.

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> Yep this is an option too.  Emmanuel has some ideas as well such as writi=
ng
> translators from old server.xml to
> new one.  But I'm not keen on this.
>
> Our problem is we are treating 1.5 branch as if it were a stable branch a=
nd
> not using it for hard core experimental
> work anymore since we're driving users towards it since it just blows 1.0
> away.  This puts us into the dilemma of
> dealing with the woes of users.
>
> I guess we can just say hey this is an experimental branch that you have =
to
> deal with changes to.  WDYT?
>
> Alex
>
>
> On 9/25/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wr
ote: 
> configuration beans to 
er[vbcol=seagreen]
> seeing just how many problems 
en[vbcol=seagreen]
> immediately if it does in 
of[vbcol=seagreen]
> them.  First and foremost 
> completely change as well so 
e[vbcol=seagreen]
> they are more stable than 
> The remaining question is when. 
> immediately on a 2.5?  So this 
ed[vbcol=seagreen]
> to figure out what to stuff 
nch[vbcol=seagreen]
> before 2.0 is out the door if 
s[vbcol=seagreen]
> from them. 
r.[vbcol=seagreen]
> I suggest making this change before releasing 2.0 and writing a complete
> "what's changed?" guide. 
>
>


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com

[ Post a follow-up to this message ]

On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbc
ol=seagreen]
>
> For those reasons, I would say : keep 2.0 conf as is, and do
> experimentations in a branch.[/vbcol]


So we're not going to be too free to experiment from now on in 1.5 branch?
This sort of
breaks with our general policy on branches yet it's appealing in many other
ways.  It's
just a matter of trade offs.  It's more important in this case for us to
just make a decision.

Either option is fine with me since both choices take relatively the same
time and energy.
I started this thread to see what people are thinking about it and it sounds
as though there
is a split.  Perhaps we just need a vote and go with it.

Alex

[ Post a follow-up to this message ]

See, this is something that I have never liked about the stable / unstable
release categorization...  How can we ever claim to have a stable
2.0release without some limitation of changes on the unstable
1.5 at some point?

My preference is to begin limiting major changes to 1.5.x for the sake of
stabilizing it to be the 2.0 stable release, and at that point we EOL 1.0.
We start the major refactorings in 2.5 based on the 2.0 or a late
1.5release.  I think anything else is just too complicated for us to
manage
properly.

Thanks,
Chris

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
>
> On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gma
ne.org> wrote: 
>
>
> So we're not going to be too free to experiment from now on in 1.5branch? 
 This sort of
> breaks with our general policy on branches yet it's appealing in many
> other ways.  It's
> just a matter of trade offs.  It's more important in this case for us to
> just make a decision.
>
> Either option is fine with me since both choices take relatively the same
> time and energy.
> I started this thread to see what people are thinking about it and it
> sounds as though there
> is a split.  Perhaps we just need a vote and go with it.
>
> Alex
>
>

[ Post a follow-up to this message ]

On 9/25/07, Chris Custine <ccustine-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> See, this is something that I have never liked about the stable / unstable
> release categorization...  How can we ever claim to have a stable 2.0relea
se without some limitation of changes on the unstable
> 1.5 at some point?


Yes this is rigid but sometimes for good reasons for server products.  But I
can debate this with my self all day long. I too have your concerns.  I just
don't have a better option right now.  I know now is not the time to rehash
this topic again since you did not seem to want to but perhaps we can reopen
this conversation again. There's got to be a better way out there.  We'll
find it probably.

My preference is to begin limiting major changes to 1.5.x for the sake of
> stabilizing it to be the 2.0 stable release, and at that point we EOL 1.0.
> We start the major refactorings in 2.5 based on the 2.0 or a late 1.5relea
se.  I think anything else is just too complicated for us to manage
> properly.
>

Thanks for the feedback.  I kicked off a vote on this.

Alex

[ Post a follow-up to this message ]

I didn't say that we should not experiment in branch, but that we
should not merge the branch in 2.0, otherwise we will have too many
configuration change.

When 2.0 will be out, we may then merge the branch with trunk, or
discard the branch.

Branching to experiment this new configuration is like if we
anticipate the 2.5 trunk, and I have nothing againt that.

On 9/25/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gma
ne.org> wrote: 
>
> So we're not going to be too free to experiment from now on in 1.5 branch=
?
> This sort of
> breaks with our general policy on branches yet it's appealing in many oth=
er
> ways.  It's
> just a matter of trade offs.  It's more important in this case for us to
> just make a decision.
>
> Either option is fine with me since both choices take relatively the same
> time and energy.
> I started this thread to see what people are thinking about it and it sou=
nds
> as though there
> is a split.  Perhaps we just need a vote and go with it.
>
> Alex
>
>


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com

[ Post a follow-up to this message ]

We need a Release Schedule/Roadmap for 2.0 right now.

On 9/25/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> I didn't say that we should not experiment in branch, but that we
> should not merge the branch in 2.0, otherwise we will have too many
> configuration change.
>
> When 2.0 will be out, we may then merge the branch with trunk, or
> discard the branch.
>
> Branching to experiment this new configuration is like if we
> anticipate the 2.5 trunk, and I have nothing againt that.
>
> On 9/25/07, Alex Karasulu <akarasulu@apache.org> wrote: 
> other 
> same 
> sounds 
>
>
> --
> Regards,
> Cordialement,
> Emmanuel LĂ©charny
> www.iktek.com
>



-- 
Ersin Er
http://www.ersin-er.name

[ Post a follow-up to this message ]

ok

I will try to push it on the list, gathering the spare informations we
have all over. this will be a draft, anyone of us can push some ideas
of features.

On 9/25/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> We need a Release Schedule/Roadmap for 2.0 right now.
>
>
> On 9/25/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gma
ne.org> wrote: 
> branch? 
> other 
to[vbcol=seagreen] 
> same 
> sounds 
>
>
>
> --
>
> Ersin Er
> http://www.ersin-er.name


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com

[ Post a follow-up to this message ]