there are further clarifications to do:
- trunk now will be released as 2.2.0-Beta01 and then versioned 2.2.0-Beta02-SNAPSHOT
- 2.1.x maintenance branch is created from 2.1.1-GA tag release
consequently (GTNPC-24, GTNPC-25, GTNPC-9, GTNPC-13) that are currently assigned to the
2.1.2-GA won't resolve for this but will instead resolve for 2.2.0-Beta1 release.
those JIRA don't seem required for the maintenance branch.
On Aug 13, 2010, at 6:08 PM, Matthew Wringe wrote:
On Fri, 2010-08-13 at 17:27 +0200, Julien Viet wrote:
> You mean jira setup?
Yes,the jira setup and doing the release of 2.2.0 alpha/beta, I assume
only the lead has these permissions (if not, just give me the ok and I
will try to do it).
>
> Le 13 août 2010 à 17:04, Matthew Wringe <mwringe(a)redhat.com> a écrit :
>
>> Ok, the patch and test cases have been committed to pc head, the tests
>> are all passing in hudson. I think everything should be good on my end
>> for a pc 2.2.0 alpha/beta.
>> I guess the pc lead would have to do the 2.2.0 setup.
>>
>> On Fri, 2010-08-13 at 09:12 -0400, Matthew Wringe wrote:
>>> On Thu, 2010-08-12 at 23:33 +0200, Julien Viet wrote:
>>>> N/p with me, however I have 3 concerns:
>>>>
>>>> - the next version of PC won't be a minor release so it should be
>>>> changed to 2.2 beta and the jira accordingly (changing portlet invoker
>>>> interface is not maintenance)
>>> - good point
>>>
>>>> - need of extensive testing for these new methods
>>> The lastest patch contains tests which should be sufficient, I will look
>>> over them again to see if there is something else which could be added.
>>>
>>>> - name methods exportPortlet and importPortlet (no Context appended)
>>> yes, the newer patch I submitted already made this change
>>>
>>>> Le 12 août 2010 à 23:15, Matthew Wringe <mwringe(a)redhat.com> a
écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> In order to get the WSRP 2.0 import/export features working we need
to
>>>>> make a few changes to the PortletInvoker to help with this
import/export
>>>>> functionality.
>>>>> The current invoker doesn't allow for retrieval of portlet state
(the
>>>>> invoker can store it locally) or allow for the retrieval of the
actual
>>>>> portlet ID from a cloned portlet context.
>>>>> Since each invoker stores this data independently, we need methods
added
>>>>> to the portlet invoker to expose them.
>>>>>
>>>>> I have created a jira for this task
>>>>> (
https://jira.jboss.org/browse/GTNPC-26) with a patch and test
cases.
>>>>>
>>>>> Right now we are using snapshots of the PC component in the WSRP
trunk
>>>>> which is causing test failures for anyone who is not building PC
with
>>>>> the patches locally.
>>>>> Is there any objection to committing the patch from GTNPC-26 in PC
and
>>>>> creating a new PC alpha or beta release?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Matt Wringe
>>>>>
>>>>> _______________________________________________
>>>>> gatein-dev mailing list
>>>>> gatein-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>
>>