You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/05/04 15:35:16 UTC
The Opposite of Incubator
Hi,
At Avalon we have a small problem.
Phoenix has ceased to be actively developed, and an external fork has occurred
driven by the previous Phoenix developers, called Loom at CodeHaus, and users
who needs help with Phoenix are directed to the Loom project.
Now, what do we do with the Phoenix codebase in ASF??
GUMP makes this apparent. When changes are made in CVS in projects that
Phoenix depends on, we will receive Nags. These are of three types;
1. Temporary and will disappear by themself.
2. Incompatible change in other project, by mistake or un-awareness.
3. Permanent Incompatible change. 1.0 -> 2.0
By upgrading Phoenix to these changes, seems fairly meaningless.
Killing the Gump descriptor seems like the most logical thing to do, but that
would affect projects that depends on it (or other similar cases), James in
this case, I think.
Should there be a notion of "Compost", "Graveyard" or "Retirement Home" for
projects that has outlived their community?
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: The Opposite of Incubator
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 04 May 2004 22:04, Stefano Mazzocchi wrote:
> JServ is, for example, in dead from a community point of view, yet many
> people use it in production. JServ is now located at archive.apache.org.
I am one of them :o) (Great product - right size!)
> If the avalon project feels like discontinuing phoenix, I think you just
> require a PMC vote and then require infrastructure to seal the CVS
> repository and put it in the archive.
Thanks for the pointer...
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: The Opposite of Incubator
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> Hi,
>
> At Avalon we have a small problem.
>
> Phoenix has ceased to be actively developed, and an external fork has occurred
> driven by the previous Phoenix developers, called Loom at CodeHaus, and users
> who needs help with Phoenix are directed to the Loom project.
>
> Now, what do we do with the Phoenix codebase in ASF??
>
> GUMP makes this apparent. When changes are made in CVS in projects that
> Phoenix depends on, we will receive Nags. These are of three types;
> 1. Temporary and will disappear by themself.
> 2. Incompatible change in other project, by mistake or un-awareness.
> 3. Permanent Incompatible change. 1.0 -> 2.0
>
> By upgrading Phoenix to these changes, seems fairly meaningless.
>
> Killing the Gump descriptor seems like the most logical thing to do, but that
> would affect projects that depends on it (or other similar cases), James in
> this case, I think.
>
> Should there be a notion of "Compost", "Graveyard" or "Retirement Home" for
> projects that has outlived their community?
There was a lot of discussion about this at the time of the incubator's
birth. It was suggested that anything related to 'death' was a bad idea.
JServ is, for example, in dead from a community point of view, yet many
people use it in production. JServ is now located at archive.apache.org.
If the avalon project feels like discontinuing phoenix, I think you just
require a PMC vote and then require infrastructure to seal the CVS
repository and put it in the archive.
--
Stefano.
Re: The Opposite of Incubator
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 05 May 2004 05:43, Stephen McConnell wrote:
> Phoenix loads applications in their own classloader - i.e. the version
> used by Phoenix should not impact the version of something used in
> James. I.e. James can build against X provided by Gump.
Well,,,
Any Classloader will delegate classloading to its parent before trying to load
the class itself. I doubt that all classloaders used by Phoenix are not
ancestor of any application classloaders (impossible be definition).
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: The Opposite of Incubator
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 05 May 2004 00:37, Stefan Bodewig wrote:
>
>>On Tue, 4 May 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
>>
>>>Assuming that Phoenix goes into archive, what do we do for James
>>>(and others)? There are a few:
>>
>>Turn phoenix into an installed package.
>>
>>
>>>Things below Phoenix are still developing, and can (have?) break
>>>Phoenix. As such, we can't even package Phoenix & expect success for
>>>James and such.
>>
>>Why not? Phoenix will never change.
>
>
> Part of the problem (may) be;
>
> Phoenix depends on X.
> James also depends on X.
>
> X changes so it breaks Phoenix, but Phoenix comes with its own older version
> of X, so "it doesn't change".
> What happens for James, since it will need to compile against either the X in
> Phoenix or X provided by Gump.
Phoenix loads applications in their own classloader - i.e. the version
used by Phoenix should not impact the version of something used in
James. I.e. James can build against X provided by Gump.
Stephen.
> Niclas
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: The Opposite of Incubator
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 5 May 2004, Niclas Hedhman <ni...@hedhman.org> wrote:
> Part of the problem (may) be;
>
> Phoenix depends on X.
> James also depends on X.
Yes, MX4J is the first candidate, I see.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: The Opposite of Incubator
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 05 May 2004 00:37, Stefan Bodewig wrote:
> On Tue, 4 May 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
> > Assuming that Phoenix goes into archive, what do we do for James
> > (and others)? There are a few:
>
> Turn phoenix into an installed package.
>
> > Things below Phoenix are still developing, and can (have?) break
> > Phoenix. As such, we can't even package Phoenix & expect success for
> > James and such.
>
> Why not? Phoenix will never change.
Part of the problem (may) be;
Phoenix depends on X.
James also depends on X.
X changes so it breaks Phoenix, but Phoenix comes with its own older version
of X, so "it doesn't change".
What happens for James, since it will need to compile against either the X in
Phoenix or X provided by Gump.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: The Opposite of Incubator
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 4 May 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:
> Assuming that Phoenix goes into archive, what do we do for James
> (and others)? There are a few:
Turn phoenix into an installed package.
> Things below Phoenix are still developing, and can (have?) break
> Phoenix. As such, we can't even package Phoenix & expect success for
> James and such.
Why not? Phoenix will never change.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: The Opposite of Incubator
Posted by Stephen McConnell <mc...@apache.org>.
Adam R. B. Jack wrote:
> Niclas wrote this (on community, and found archive). Bringing it here for
> continuation:
>
> [...]
>
>>Now, what do we do with the Phoenix codebase in ASF??
>>
>>GUMP makes this apparent. When changes are made in CVS in projects that
>>Phoenix depends on, we will receive Nags. These are of three types;
>>1. Temporary and will disappear by themself.
>>2. Incompatible change in other project, by mistake or un-awareness.
>>3. Permanent Incompatible change. 1.0 -> 2.0
>>
>>By upgrading Phoenix to these changes, seems fairly meaningless.
>>
>>Killing the Gump descriptor seems like the most logical thing to do, but
>
> that
>
>>would affect projects that depends on it (or other similar cases), James
>
> in
>
>>this case, I think.
>
>
> Assuming that Phoenix goes into archive, what do we do for James (and
> others)? There are a few:
>
>
> http://lsd.student.utwente.nl/gump/avalon-phoenix/avalon-phoenix/details.html#Project+Dependees
>
> Things below Phoenix are still developing, and can (have?) break Phoenix. As
> such, we can't even package Phoenix & expect success for James and such.
>
> Any thoughts on how we deal with this?
We can setup a gump build that handles:
(a) compilation of james against all latest dependencies
independently of phoenix (because james compile does
not require phoenix)
(b) testcase execution using merlin unit and the gump
generated james artifacts
To do this we would need to cleanup the build procedures in james head
and think about the unit test strategy - but getting james up and
running ready for a test will not be a problem. Based on my own tests
there is one problematic source in the james codebase which is a legacy
wrapper that deals with a deprecated interface in the excalibur threads
package. The wrapper needs to be removed (or at least updated to assume
that the deprecated class may no longer be available). Aside from that
it should all work fine.
Stephen.
> regards
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: The Opposite of Incubator
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
Niclas wrote this (on community, and found archive). Bringing it here for
continuation:
[...]
> Now, what do we do with the Phoenix codebase in ASF??
>
> GUMP makes this apparent. When changes are made in CVS in projects that
> Phoenix depends on, we will receive Nags. These are of three types;
> 1. Temporary and will disappear by themself.
> 2. Incompatible change in other project, by mistake or un-awareness.
> 3. Permanent Incompatible change. 1.0 -> 2.0
>
> By upgrading Phoenix to these changes, seems fairly meaningless.
>
> Killing the Gump descriptor seems like the most logical thing to do, but
that
> would affect projects that depends on it (or other similar cases), James
in
> this case, I think.
Assuming that Phoenix goes into archive, what do we do for James (and
others)? There are a few:
http://lsd.student.utwente.nl/gump/avalon-phoenix/avalon-phoenix/details.html#Project+Dependees
Things below Phoenix are still developing, and can (have?) break Phoenix. As
such, we can't even package Phoenix & expect success for James and such.
Any thoughts on how we deal with this?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org