You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Christopher Lenz <cm...@gmx.de> on 2002/04/18 11:47:51 UTC
release 1.1 ?
Hi folks,
I think this would be a good time to get v1.1.0 out of the door.
I'd just like to get the jstl-taglib synced with the struts-taglib by adding the
2 missing tags. I'll do that this weekend.
I haven't yet had sufficient time to look at the user-quota-support for
inclusion (sorry Jean-Philippe :P), although I think the switch from 1.0 to 1.1
would be better for the required minor API changes than a potential future
switch from 1.1.0 to 1.1.1.
Remy, can you take on the release process, being as routined as you are with
that ? :)
-chris
_______________________________________________
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Jean-Philippe Courson <co...@noos.fr>.
Christopher Lenz wrote:
> Am 18.04.2002 13:20:13, schrieb "Remy Maucherat" <re...@apache.org>:
>
>>>Hi folks,
>>>
>>>I think this would be a good time to get v1.1.0 out of the door.
>>>I'd just like to get the jstl-taglib synced with the struts-taglib by
>>
>>adding the
>>
>>>2 missing tags. I'll do that this weekend.
>>>
>>>I haven't yet had sufficient time to look at the user-quota-support for
>>>inclusion (sorry Jean-Philippe :P), although I think the switch from 1.0
>>
>>to 1.1
>>
>>>would be better for the required minor API changes than a potential future
>>>switch from 1.1.0 to 1.1.1.
>>
>>+1 for the release (but you should post a formal request for a vote on the
>>release when those patches are applied).
>
>
> Note that I didn't volunteer to commit/review the user-quota patches, as I'm a
> quite time-constrained atm (who isn't :P). Maybe I'll find some hours this
> weekend though.
If it could help you, I will send tomorrow an email with my patches
explaining in detail what they are doing to make the review/commit job
as fast and paintless as possible
Regards
JP
>>>Remy, can you take on the release process, being as routined as you are
>>
>>with
>>
>>>that ? :)
>>
>>No problem, I can do that :)
>>1.1.0 seems to be the maintenance path for 1.0.16, so I don't think it is
>>needed to create a branch this time, right ?
>
>
> Agreed.
>
> -chris
> _______________________________________________
> /=/ cmlenz at gmx.de
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Christopher Lenz <cm...@gmx.de>.
Am 18.04.2002 13:20:13, schrieb "Remy Maucherat" <re...@apache.org>:
>> Hi folks,
>>
>> I think this would be a good time to get v1.1.0 out of the door.
>> I'd just like to get the jstl-taglib synced with the struts-taglib by
>adding the
>> 2 missing tags. I'll do that this weekend.
>>
>> I haven't yet had sufficient time to look at the user-quota-support for
>> inclusion (sorry Jean-Philippe :P), although I think the switch from 1.0
>to 1.1
>> would be better for the required minor API changes than a potential future
>> switch from 1.1.0 to 1.1.1.
>
>+1 for the release (but you should post a formal request for a vote on the
>release when those patches are applied).
Note that I didn't volunteer to commit/review the user-quota patches, as I'm a
quite time-constrained atm (who isn't :P). Maybe I'll find some hours this
weekend though.
>> Remy, can you take on the release process, being as routined as you are
>with
>> that ? :)
>
>No problem, I can do that :)
>1.1.0 seems to be the maintenance path for 1.0.16, so I don't think it is
>needed to create a branch this time, right ?
Agreed.
-chris
_______________________________________________
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Remy Maucherat <re...@apache.org>.
> Hi folks,
>
> I think this would be a good time to get v1.1.0 out of the door.
> I'd just like to get the jstl-taglib synced with the struts-taglib by
adding the
> 2 missing tags. I'll do that this weekend.
>
> I haven't yet had sufficient time to look at the user-quota-support for
> inclusion (sorry Jean-Philippe :P), although I think the switch from 1.0
to 1.1
> would be better for the required minor API changes than a potential future
> switch from 1.1.0 to 1.1.1.
+1 for the release (but you should post a formal request for a vote on the
release when those patches are applied).
> Remy, can you take on the release process, being as routined as you are
with
> that ? :)
No problem, I can do that :)
1.1.0 seems to be the maintenance path for 1.0.16, so I don't think it is
needed to create a branch this time, right ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Jean-Philippe Courson <co...@noos.fr>.
Christopher Lenz wrote:
> Am 18.04.2002 13:46:34, schrieb Jean-Philippe Courson <co...@noos.fr>:
>
>
>>Christopher Lenz wrote:
>
> [..]
>
>>For me, inclusion of user-quota-support in particular doesn't matter,
>>but the ability to plug, configure and use smoothly Content-Interceptors
>>would be great.
>>
>>I explain myself : Slide's Content-Interceptors concept is great but,
>>for now, not very usable ; you can't add parameters to them, they can't
>>throw any exceptions and they lack some methods (like
>>postRemoveContent).
>>
>>I think that making these generic Content-Interceptors modifications
>>would be painless (I've already written them) and the patches are very
>>small and basic so they should not add bugs.
>>
>>What is your opinion on this ?
>
>
> Well, I agree with your opinions here, and I'll try to find the time to review
> and commit your patches asap.
>
>
>>Regards
>>
>>JP
>>
>>ps : for more informations on proposed modifications, please see
>> http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02876.html
>
>
> I've just re-read the discussion (which I didn't closely follow, originally).
>
> One point: IMHO ContentInterceptor should have been an interface from the start.
> As the mechanism obviously hasn't been used much (due to it's limited
> usability), why not make it an interface now if we're changing the API anyway ?
> And provide an abstract class AbstractContentInterceptor to ease implementation.
I agree with you and it's what Remy was suggested (see
http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02030.html)
JP
> Are there any good reasons ContentInterceptor isn't an interface ? Would the
> above be too much of a change ?
>
> -chris
> _______________________________________________
> /=/ cmlenz at gmx.de
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Jean-Philippe Courson <co...@noos.fr>.
Jean-Philippe Courson wrote:
> Christopher Lenz wrote:
>
>> Am 18.04.2002 16:30:59, schrieb Christopher Lenz <cm...@gmx.de>:
>>
>>> Am 18.04.2002 13:46:34, schrieb Jean-Philippe Courson <co...@noos.fr>:
>>
>>
>> [...]
>>
>>>> ps : for more informations on proposed modifications, please see
>>>> http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02876.html
>>>
>>>
>>> I've just re-read the discussion (which I didn't closely follow,
>>> originally).
>>>
>>> One point: IMHO ContentInterceptor should have been an interface from
>>> the start. As the mechanism obviously hasn't been used much (due to
>>> it's limited usability), why not make it an interface now if we're
>>> changing the API anyway ? And provide an abstract class
>>> AbstractContentInterceptor to ease implementation.
>>>
>>> Are there any good reasons ContentInterceptor isn't an interface ?
>>> Would the above be too much of a change ?
>>
>>
>>
>> ...and,
>>
>> [sorry but I hadn't been dealing with the whole ContentInterceptor API
>> before]
>>
>> if there is a preStoreContent(), why shouldn't there be
>> preRetrieveContent() and preRemoveContent() ? preRetrieveContent()
>> might not make sense, but there are probably use cases for
>> preRemoveContent(). Either way, the interface should be consistent and
>> have pre/post hooks for each event. Further, there are no hooks for
>> the fork/merge "events". Should those be added to ?
Fork/merge events trigger pre/postContentStore() calls.
jp
>>
>> We should try to get the API right if we're changing it anyway, IMHO.
>
>
> I agree
>
>> -chris
>> _______________________________________________
>> /=/ cmlenz at gmx.de
>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Jean-Philippe Courson <co...@noos.fr>.
Christopher Lenz wrote:
> Am 18.04.2002 16:30:59, schrieb Christopher Lenz <cm...@gmx.de>:
>
>>Am 18.04.2002 13:46:34, schrieb Jean-Philippe Courson <co...@noos.fr>:
>
> [...]
>
>>>ps : for more informations on proposed modifications, please see
>>> http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02876.html
>>
>>I've just re-read the discussion (which I didn't closely follow, originally).
>>
>>One point: IMHO ContentInterceptor should have been an interface from the
>>start. As the mechanism obviously hasn't been used much (due to it's limited
>>usability), why not make it an interface now if we're changing the API anyway ?
>>And provide an abstract class AbstractContentInterceptor to ease
>>implementation.
>>
>>Are there any good reasons ContentInterceptor isn't an interface ? Would the
>>above be too much of a change ?
>
>
> ...and,
>
> [sorry but I hadn't been dealing with the whole ContentInterceptor API before]
>
> if there is a preStoreContent(), why shouldn't there be preRetrieveContent() and
> preRemoveContent() ? preRetrieveContent() might not make sense, but there are
> probably use cases for preRemoveContent(). Either way, the interface should be
> consistent and have pre/post hooks for each event. Further, there are no hooks
> for the fork/merge "events". Should those be added to ?
>
> We should try to get the API right if we're changing it anyway, IMHO.
I agree
> -chris
> _______________________________________________
> /=/ cmlenz at gmx.de
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Christopher Lenz <cm...@gmx.de>.
Am 18.04.2002 16:30:59, schrieb Christopher Lenz <cm...@gmx.de>:
>Am 18.04.2002 13:46:34, schrieb Jean-Philippe Courson <co...@noos.fr>:
[...]
>>ps : for more informations on proposed modifications, please see
>> http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02876.html
>
>I've just re-read the discussion (which I didn't closely follow, originally).
>
>One point: IMHO ContentInterceptor should have been an interface from the
>start. As the mechanism obviously hasn't been used much (due to it's limited
>usability), why not make it an interface now if we're changing the API anyway ?
>And provide an abstract class AbstractContentInterceptor to ease
>implementation.
>
>Are there any good reasons ContentInterceptor isn't an interface ? Would the
>above be too much of a change ?
...and,
[sorry but I hadn't been dealing with the whole ContentInterceptor API before]
if there is a preStoreContent(), why shouldn't there be preRetrieveContent() and
preRemoveContent() ? preRetrieveContent() might not make sense, but there are
probably use cases for preRemoveContent(). Either way, the interface should be
consistent and have pre/post hooks for each event. Further, there are no hooks
for the fork/merge "events". Should those be added to ?
We should try to get the API right if we're changing it anyway, IMHO.
-chris
_______________________________________________
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Christopher Lenz <cm...@gmx.de>.
Am 18.04.2002 13:46:34, schrieb Jean-Philippe Courson <co...@noos.fr>:
>Christopher Lenz wrote:
[..]
>For me, inclusion of user-quota-support in particular doesn't matter,
>but the ability to plug, configure and use smoothly Content-Interceptors
>would be great.
>
>I explain myself : Slide's Content-Interceptors concept is great but,
>for now, not very usable ; you can't add parameters to them, they can't
>throw any exceptions and they lack some methods (like
>postRemoveContent).
>
>I think that making these generic Content-Interceptors modifications
>would be painless (I've already written them) and the patches are very
>small and basic so they should not add bugs.
>
>What is your opinion on this ?
Well, I agree with your opinions here, and I'll try to find the time to review
and commit your patches asap.
>Regards
>
>JP
>
>ps : for more informations on proposed modifications, please see
> http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02876.html
I've just re-read the discussion (which I didn't closely follow, originally).
One point: IMHO ContentInterceptor should have been an interface from the start.
As the mechanism obviously hasn't been used much (due to it's limited
usability), why not make it an interface now if we're changing the API anyway ?
And provide an abstract class AbstractContentInterceptor to ease implementation.
Are there any good reasons ContentInterceptor isn't an interface ? Would the
above be too much of a change ?
-chris
_______________________________________________
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: release 1.1 ?
Posted by Jean-Philippe Courson <co...@noos.fr>.
Christopher Lenz wrote:
> Hi folks,
>
> I think this would be a good time to get v1.1.0 out of the door.
> I'd just like to get the jstl-taglib synced with the struts-taglib by adding the
> 2 missing tags. I'll do that this weekend.
>
> I haven't yet had sufficient time to look at the user-quota-support for
> inclusion (sorry Jean-Philippe :P), although I think the switch from 1.0 to 1.1
> would be better for the required minor API changes than a potential future
> switch from 1.1.0 to 1.1.1.
>
> Remy, can you take on the release process, being as routined as you are with
> that ? :)
>
Hi Chris,
For me, inclusion of user-quota-support in particular doesn't matter,
but the ability to plug, configure and use smoothly Content-Interceptors
would be great.
I explain myself : Slide's Content-Interceptors concept is great but,
for now, not very usable ; you can't add parameters to them, they can't
throw any exceptions and they lack some methods (like
postRemoveContent).
I think that making these generic Content-Interceptors modifications
would be painless (I've already written them) and the patches are very
small and basic so they should not add bugs.
What is your opinion on this ?
Regards
JP
ps : for more informations on proposed modifications, please see
http://www.mail-archive.com/slide-dev@jakarta.apache.org/msg02876.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>