You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by David Sean Taylor <da...@bluesunrise.com> on 2004/03/01 20:06:49 UTC
Re: Clarification on Container Services
On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>> But all in all the conversion is going well, we are almost there.
>>
>>
> This is a pretty radical step - it is probably going to mean
> significant changes to the container API, and if we deceided to go
> ahead with it we should (probably?) wait until we have it stable
> before putting a release out.
>
I agree we should release 1.0 of Pluto from portals.apache.org first.
This can be a 1.1 direction.
Re: Clarification on Container Services
Posted by Serge Huber <sh...@jahia.com>.
At 08:52 AM 3/2/2004, you wrote:
>David Sean Taylor wrote:
>>On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>>
>>>>But all in all the conversion is going well, we are almost there.
>>>>
>>>This is a pretty radical step - it is probably going to mean significant
>>>changes to the container API, and if we deceided to go ahead with it we
>>>should (probably?) wait until we have it stable before putting a release out.
>>I agree we should release 1.0 of Pluto from portals.apache.org first.
>>This can be a 1.1 direction.
>>
>
>I agree with this. Let's try to get a 1.0 release out and look into using
>IoC in more detail before changing anything. I would like to have discuss
>and prototype these kind of fundamenal changes first before deciding on
>them. IoC really looks interesting, so I think it is definitely worth
>looking into that.
+1.
Regards,
Serge...
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
RE: Clarification on Container Services
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David H. DeWolf wrote:
> Are you suggesting that the IoC version of Pluto would not
> need to be backwards compatible with a 1.0 release? I know
> there's been a lot of discussions on other lists about
> commons-collections not maintaining binary compatibility
> (through deprecation) with it's most recent release. I
> wouldn't want to make the same mistake. Granted, a commons
> library is significantly different than a container, but a
> switch without binary compatibility would require any portals
> using the pluto container to re-integrate from the ground up.
>
I'm not suggesting but implying :) Of course, we should try
to make it as compatible as possible, but switching from the
current approach to IoC might be very hard to do if you
also try to be compatible. I might be wrong.
So, I guess (just a guess!) that an IoC version would be a
2.0 version that might not be compatible.
But we shouldn't discuss this now :) This might give the wrong
impression to our users.
Carsten
Re: Clarification on Container Services
Posted by "David H. DeWolf" <dd...@apache.org>.
Carsten Ziegeler wrote:
> David H. DeWolf wrote:
>
>>>I agree with this. Let's try to get a 1.0 release out and look into
>>>using IoC in more detail before changing anything. I would like to
>>>have discuss and prototype these kind of fundamenal changes first
>>>before deciding on them. IoC really looks interesting, so I
>>
>>think it
>>
>>>is definitely worth looking into that.
>>>
>>
>>Part of me agrees that it's best to get a 1.0 release out
>>before taking on a "rewrite". On the other hand, a rewrite
>>will *significantly* change the API. I would hate to have a
>>1.0 release put out just for the sake of timing and then have
>>to support a significantly different API through deprecation
>>just so we're backwards compatible.
>>
>>No matter what we choose. . .
>>
>>I propose that we setup a "contrib" or "sandbox" folder in
>>cvs so that we have a place to track proposals and eventually
>>prototypes for an IoC based pluto.
>>
>
> I really would love to have a IoC based pluto (I integrate it into
> Cocoon and Cocoon uses Avalon, so that would be a perfect fit).
> And I also think a sandbox would be good,
>
> BUT: we are still in incubation and I think our first priority should
> be to get out off incubation. I think if we focus on a release now -
> and I think there isn't much to do for it anyway - then do the
> release we can get out of incubation with that and can then more
> easily do what we think is best.
Agreed, getting out of incubation should be a priority. To do this, I
would think that we should come up with a specific roadmap. What are
the things that need to be done before a release?
>
> We would have to maintain the 1.0 branch then, but I think that
> shouldn't be to hard as well and we could start a new version in
> our sandbox.
Are you suggesting that the IoC version of Pluto would not need to be
backwards compatible with a 1.0 release? I know there's been a lot of
discussions on other lists about commons-collections not maintaining
binary compatibility (through deprecation) with it's most recent
release. I wouldn't want to make the same mistake. Granted, a commons
library is significantly different than a container, but a switch
without binary compatibility would require any portals using the pluto
container to re-integrate from the ground up.
>
> WDYT?
>
> Carsten
>
>
RE: Clarification on Container Services
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David H. DeWolf wrote:
> > I agree with this. Let's try to get a 1.0 release out and look into
> > using IoC in more detail before changing anything. I would like to
> > have discuss and prototype these kind of fundamenal changes first
> > before deciding on them. IoC really looks interesting, so I
> think it
> > is definitely worth looking into that.
> >
>
> Part of me agrees that it's best to get a 1.0 release out
> before taking on a "rewrite". On the other hand, a rewrite
> will *significantly* change the API. I would hate to have a
> 1.0 release put out just for the sake of timing and then have
> to support a significantly different API through deprecation
> just so we're backwards compatible.
>
> No matter what we choose. . .
>
> I propose that we setup a "contrib" or "sandbox" folder in
> cvs so that we have a place to track proposals and eventually
> prototypes for an IoC based pluto.
>
I really would love to have a IoC based pluto (I integrate it into
Cocoon and Cocoon uses Avalon, so that would be a perfect fit).
And I also think a sandbox would be good,
BUT: we are still in incubation and I think our first priority should
be to get out off incubation. I think if we focus on a release now -
and I think there isn't much to do for it anyway - then do the
release we can get out of incubation with that and can then more
easily do what we think is best.
We would have to maintain the 1.0 branch then, but I think that
shouldn't be to hard as well and we could start a new version in
our sandbox.
WDYT?
Carsten
Re: Clarification on Container Services
Posted by "David H. DeWolf" <dd...@apache.org>.
Stefan Hepper wrote:
> David Sean Taylor wrote:
>
>>
>> On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>>
>>>> But all in all the conversion is going well, we are almost there.
>>>>
>>>>
>>> This is a pretty radical step - it is probably going to mean
>>> significant changes to the container API, and if we deceided to go
>>> ahead with it we should (probably?) wait until we have it stable
>>> before putting a release out.
>>>
>> I agree we should release 1.0 of Pluto from portals.apache.org first.
>> This can be a 1.1 direction.
>>
>>
>>
>
> I agree with this. Let's try to get a 1.0 release out and look into
> using IoC in more detail before changing anything. I would like to have
> discuss and prototype these kind of fundamenal changes first before
> deciding on them. IoC really looks interesting, so I think it is
> definitely worth looking into that.
>
Part of me agrees that it's best to get a 1.0 release out before taking
on a "rewrite". On the other hand, a rewrite will *significantly*
change the API. I would hate to have a 1.0 release put out just for the
sake of timing and then have to support a significantly different API
through deprecation just so we're backwards compatible.
No matter what we choose. . .
I propose that we setup a "contrib" or "sandbox" folder in cvs so that
we have a place to track proposals and eventually prototypes for an IoC
based pluto.
> Stefan
>
Re: Clarification on Container Services
Posted by Stefan Hepper <st...@hursley.ibm.com>.
David Sean Taylor wrote:
>
> On Friday, February 27, 2004, at 05:48 PM, Nick Lothian wrote:
>
>>> But all in all the conversion is going well, we are almost there.
>>>
>>>
>> This is a pretty radical step - it is probably going to mean
>> significant changes to the container API, and if we deceided to go
>> ahead with it we should (probably?) wait until we have it stable
>> before putting a release out.
>>
> I agree we should release 1.0 of Pluto from portals.apache.org first.
> This can be a 1.1 direction.
>
>
>
I agree with this. Let's try to get a 1.0 release out and look into
using IoC in more detail before changing anything. I would like to have
discuss and prototype these kind of fundamenal changes first before
deciding on them. IoC really looks interesting, so I think it is
definitely worth looking into that.
Stefan