You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2004/05/04 18:24:13 UTC
Re: The Opposite of Incubator
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
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