You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Elliot Metsger <em...@jhu.edu> on 2007/11/30 05:49:56 UTC
1.1.5 release
There are four unresolved issues for a 1.1.5 release, so I can commit
cycles to get a 1.1.5 out the door.
In order to minimize the impact on the 286 work, I won't apply any fixes
to trunk - but I will create a duplicate issue so we don't have a
regression when the next release (be it a 1.2 or 286) happens.
Sorry I've just been mega-busy lately.
E
Eric Dalquist wrote:
> Craig,
>
> I created https://issues.apache.org/jira/browse/PLUTO-448 for the issue.
> Just out of curiosity is there any plan for a 1.1.5 release? I realize
> from you earlier post that you're really swamped and don't want to be
> adding to that. I would be able to provide time to help with a 1.1.5
> release if that would help. My concern here is we will be releasing
> uPortal on Pluto 1.1 and it would be nice to be on a released version of
> Pluto instead of a 1.1.5-SNAPSHOT.
>
> Thank you,
> -Eric
>
> CDoremus@hannaford.com wrote:
>> Thanks, Eric, for your heads up on this issue. Can you create a Jira
>> issue?
>> A patch would also be very helpful.
>>
>> Off the top of my head. I suggest that we initialize the
>> PortletDD.expirationCache field to some non-valid value (< -1), rather
>> than
>> its current initial value of zero. It's probably best to make this
>> value a
>> public constant. (called EXPIRATION_CACHE_UNSET), and put it in the
>> org.apache.pluto.Constants class in the pluto-container module. Do you --
>> or anyone else -- have any other ideas?
>>
>> BTW, -- for those who don't know -- Pluto does not implement expiration
>> caching as it is an optional service.
>>
>> TIA
>> /Craig
>>
>>
>>
>>
>> Eric
>> Dalquist
>> <eric.dalquist@do
>>
>> it.wisc.edu> To
>>
>> pluto-user@portals.apache.org 11/18/2007
>> 06:44 cc
>> PM
>>
>> Subject PortletDD &
>> getExpirationCache Please respond
>> to
>> pluto-user@portal
>>
>> s.apache.org
>>
>>
>>
>>
>>
>>
>>
>> I'm working on updating the uPortal trunk to use Pluto 1.1 and have a
>> question about PortletDD.getExpirationCache()
>>
>> At PLT.18.1 line 23 the spec says that if a portlet does not set an
>> expiration cache value in portlet.xml the corresponding request property
>> should be ignored. Since PortletDD.getExpirationCache() retuns an int
>> how can I tell if it was set or not?
>>
>> Thanks,
>> -Eric
>>
>>
Re: 1.1.5 release
Posted by Elliot Metsger <em...@jhu.edu>.
Oh wow more stuff popped up :-) 11 issues now!
Great stuff - if there are maintenance type issues that don't have a
1.1.5 "Fix-for" that you'd like to see in 1.1.5 please do update your
Jira issues (as some already have)
Thanks a lot,
Elliot
Elliot Metsger wrote:
> There are four unresolved issues for a 1.1.5 release, so I can commit
> cycles to get a 1.1.5 out the door.
>
> In order to minimize the impact on the 286 work, I won't apply any fixes
> to trunk - but I will create a duplicate issue so we don't have a
> regression when the next release (be it a 1.2 or 286) happens.
>
> Sorry I've just been mega-busy lately.
>
> E
>
> Eric Dalquist wrote:
>> Craig,
>>
>> I created https://issues.apache.org/jira/browse/PLUTO-448 for the
>> issue. Just out of curiosity is there any plan for a 1.1.5 release? I
>> realize from you earlier post that you're really swamped and don't
>> want to be adding to that. I would be able to provide time to help
>> with a 1.1.5 release if that would help. My concern here is we will be
>> releasing uPortal on Pluto 1.1 and it would be nice to be on a
>> released version of Pluto instead of a 1.1.5-SNAPSHOT.
>>
>> Thank you,
>> -Eric
>>
>> CDoremus@hannaford.com wrote:
>>> Thanks, Eric, for your heads up on this issue. Can you create a Jira
>>> issue?
>>> A patch would also be very helpful.
>>>
>>> Off the top of my head. I suggest that we initialize the
>>> PortletDD.expirationCache field to some non-valid value (< -1),
>>> rather than
>>> its current initial value of zero. It's probably best to make this
>>> value a
>>> public constant. (called EXPIRATION_CACHE_UNSET), and put it in the
>>> org.apache.pluto.Constants class in the pluto-container module. Do
>>> you --
>>> or anyone else -- have any other ideas?
>>>
>>> BTW, -- for those who don't know -- Pluto does not implement expiration
>>> caching as it is an optional service.
>>>
>>> TIA
>>> /Craig
>>>
>>>
>>>
>>>
>>> Eric
>>> Dalquist
>>> <eric.dalquist@do
>>>
>>> it.wisc.edu> To
>>>
>>> pluto-user@portals.apache.org 11/18/2007
>>> 06:44 cc
>>> PM
>>>
>>> Subject PortletDD &
>>> getExpirationCache Please respond
>>> to
>>> pluto-user@portal
>>>
>>> s.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'm working on updating the uPortal trunk to use Pluto 1.1 and have a
>>> question about PortletDD.getExpirationCache()
>>>
>>> At PLT.18.1 line 23 the spec says that if a portlet does not set an
>>> expiration cache value in portlet.xml the corresponding request property
>>> should be ignored. Since PortletDD.getExpirationCache() retuns an int
>>> how can I tell if it was set or not?
>>>
>>> Thanks,
>>> -Eric
>>>
>>>