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 H. DeWolf" <dd...@apache.org> on 2006/12/14 03:28:54 UTC
1.1.0 release (was Re: Moving toward a Pluto 1.1.0 release)
We are down to three remaining issues marked as needed for 1.1.0. I'd
like your comments as to whether you think they should hold up the
release or not.
Current Open Issues:
-----------------------
1) Update version numbers via maven (would be nice, but I may bump it to
1.1.1). Elliot, please comment.
2) Unique window ids per PLACEMENT (not per page). Have we ever
supported this?
3) PortalURLParser. Avoid putting extra ? and & in urls. Not needed,
but shouldn't be too hard to accomplish. Anyone want to pick it up? I
will only after #2 is taken care of.
I would like to target it's release within the next week. If you have
any other issues which you feel are critical for this release, please
let me know. Otherwise, we'll postpone the rest to 1.1.1 or 1.2.0
(depending on if it breaks backwards compatibility or not).
David
CDoremus@hannaford.com wrote:
>
> Thank you, David, for working through all the Jira issues you have for
> the past few days. It seems that Pluto 1.1 GA is in our sights.
>
> But, from a users standpoint, I'm not sure if releasing Pluto 1.1
> without page layout or preferences persistence is such a good thing. It
> seems to be a step back from Pluto 1.0.1 which has both of those
> features. Again, I'm thinking about our users, who seem to largely use
> Pluto for portlet development. Imagine having to reset your page layout
> and preferences every time you have to restart the server while you are
> developing a portlet. That would be a real drag. They might not think
> the upgrade is worth it.
>
> It might be too late to do a simple preference persistence
> implementation (file based?) for Pluto 1.1 GA, but we might want to
> shoot for some sort of file persistence of the page layout stuff you
> created which simplifies the publishing process. We also need to make
> sure the maven and ant deployments work too (see PLUTO-257).
>
> Finally, we should look at the remaining outstanding Jira issues.
> PLUTO-234 particularly troubles me since it is the only testsuite test
> that fails. I will try to look at this and others as time allows.
>
> That's all I can think of right now. Please add your thoughts on this
> issue.
> /Craig
Re: 1.1.0 release (was Re: Moving toward a Pluto 1.1.0 release)
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> We are down to three remaining issues marked as needed for 1.1.0. I'd
> like your comments as to whether you think they should hold up the
> release or not.
>
> Current Open Issues:
> -----------------------
> 1) Update version numbers via maven (would be nice, but I may bump it to
> 1.1.1). Elliot, please comment.
Ok, I've committed changes for this issue
(https://issues.apache.org/jira/browse/PLUTO-259) in r487471 and 487478.
I was able to build the distribution binary and have the testsuite pass,
except for the security checks (which are not affected by these changes).
Properties that were in expectedResults.properties and
environment.properties have been added to the base pom.xml, and the
values are interpolated during the maven 2 lifecycle.
The dist-build.xml now requires '-Dpluto.version=<the version you are
building>'. For example:
ant -f dist-build.xml -Dpluto.version=1.1.0
(you get a kind error message if you forget pluto.version)
What is *not* done, and I don't think will be done for 1.1.0 is
automating the <pluto-portal-driver>/<version> element in
pluto-portal-driver-config.xml. If we want to have this done for 1.1.0
the file needs to be moved from its current location to
src/main/resources, and that would be disruptive (the code that reads
from the file would need to be updated). I'm open to ideas here too.
Let me know if this isn't satisfactory - I can work on improving this or
we could just forget it and revert them.
Elliot
>
> 2) Unique window ids per PLACEMENT (not per page). Have we ever
> supported this?
>
> 3) PortalURLParser. Avoid putting extra ? and & in urls. Not needed,
> but shouldn't be too hard to accomplish. Anyone want to pick it up? I
> will only after #2 is taken care of.
>
>
> I would like to target it's release within the next week. If you have
> any other issues which you feel are critical for this release, please
> let me know. Otherwise, we'll postpone the rest to 1.1.1 or 1.2.0
> (depending on if it breaks backwards compatibility or not).
>
>
> David
>
> CDoremus@hannaford.com wrote:
>>
>> Thank you, David, for working through all the Jira issues you have for
>> the past few days. It seems that Pluto 1.1 GA is in our sights.
>>
>> But, from a users standpoint, I'm not sure if releasing Pluto 1.1
>> without page layout or preferences persistence is such a good thing.
>> It seems to be a step back from Pluto 1.0.1 which has both of those
>> features. Again, I'm thinking about our users, who seem to largely use
>> Pluto for portlet development. Imagine having to reset your page
>> layout and preferences every time you have to restart the server while
>> you are developing a portlet. That would be a real drag. They might
>> not think the upgrade is worth it.
>>
>> It might be too late to do a simple preference persistence
>> implementation (file based?) for Pluto 1.1 GA, but we might want to
>> shoot for some sort of file persistence of the page layout stuff you
>> created which simplifies the publishing process. We also need to make
>> sure the maven and ant deployments work too (see PLUTO-257).
>>
>> Finally, we should look at the remaining outstanding Jira issues.
>> PLUTO-234 particularly troubles me since it is the only testsuite test
>> that fails. I will try to look at this and others as time allows.
>>
>> That's all I can think of right now. Please add your thoughts on this
>> issue.
>> /Craig
Re: 1.1.0 release (was Re: Moving toward a Pluto 1.1.0 release)
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> We are down to three remaining issues marked as needed for 1.1.0. I'd
> like your comments as to whether you think they should hold up the
> release or not.
>
> Current Open Issues:
> -----------------------
> 1) Update version numbers via maven (would be nice, but I may bump it to
> 1.1.1). Elliot, please comment.
Working on testing this now. I'm committing some of the code to trunk
tonight, and then immediately will attempt to test it by creating a
distribution, then running the pluto testsuite.
If my testing fails I will revert the changes in trunk tonight.
Elliot
>
>
> David
>
> CDoremus@hannaford.com wrote:
>>
>> Thank you, David, for working through all the Jira issues you have for
>> the past few days. It seems that Pluto 1.1 GA is in our sights.
>>
>> But, from a users standpoint, I'm not sure if releasing Pluto 1.1
>> without page layout or preferences persistence is such a good thing.
>> It seems to be a step back from Pluto 1.0.1 which has both of those
>> features. Again, I'm thinking about our users, who seem to largely use
>> Pluto for portlet development. Imagine having to reset your page
>> layout and preferences every time you have to restart the server while
>> you are developing a portlet. That would be a real drag. They might
>> not think the upgrade is worth it.
>>
>> It might be too late to do a simple preference persistence
>> implementation (file based?) for Pluto 1.1 GA, but we might want to
>> shoot for some sort of file persistence of the page layout stuff you
>> created which simplifies the publishing process. We also need to make
>> sure the maven and ant deployments work too (see PLUTO-257).
>>
>> Finally, we should look at the remaining outstanding Jira issues.
>> PLUTO-234 particularly troubles me since it is the only testsuite test
>> that fails. I will try to look at this and others as time allows.
>>
>> That's all I can think of right now. Please add your thoughts on this
>> issue.
>> /Craig
Re: 1.1.0 release (was Re: Moving toward a Pluto 1.1.0 release)
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
I think I fixed #3.
Before we can release, we have to solve the licencing/header problem
first. I just noticed that some of our files do not have a header at all
while others contain the old one. This has to be fixed before any release.
Carsten
David H. DeWolf wrote:
> We are down to three remaining issues marked as needed for 1.1.0. I'd
> like your comments as to whether you think they should hold up the
> release or not.
>
> Current Open Issues:
> -----------------------
> 1) Update version numbers via maven (would be nice, but I may bump it to
> 1.1.1). Elliot, please comment.
>
> 2) Unique window ids per PLACEMENT (not per page). Have we ever
> supported this?
>
> 3) PortalURLParser. Avoid putting extra ? and & in urls. Not needed,
> but shouldn't be too hard to accomplish. Anyone want to pick it up? I
> will only after #2 is taken care of.
>
>
> I would like to target it's release within the next week. If you have
> any other issues which you feel are critical for this release, please
> let me know. Otherwise, we'll postpone the rest to 1.1.1 or 1.2.0
> (depending on if it breaks backwards compatibility or not).
>
>
> David
>
> CDoremus@hannaford.com wrote:
>> Thank you, David, for working through all the Jira issues you have for
>> the past few days. It seems that Pluto 1.1 GA is in our sights.
>>
>> But, from a users standpoint, I'm not sure if releasing Pluto 1.1
>> without page layout or preferences persistence is such a good thing. It
>> seems to be a step back from Pluto 1.0.1 which has both of those
>> features. Again, I'm thinking about our users, who seem to largely use
>> Pluto for portlet development. Imagine having to reset your page layout
>> and preferences every time you have to restart the server while you are
>> developing a portlet. That would be a real drag. They might not think
>> the upgrade is worth it.
>>
>> It might be too late to do a simple preference persistence
>> implementation (file based?) for Pluto 1.1 GA, but we might want to
>> shoot for some sort of file persistence of the page layout stuff you
>> created which simplifies the publishing process. We also need to make
>> sure the maven and ant deployments work too (see PLUTO-257).
>>
>> Finally, we should look at the remaining outstanding Jira issues.
>> PLUTO-234 particularly troubles me since it is the only testsuite test
>> that fails. I will try to look at this and others as time allows.
>>
>> That's all I can think of right now. Please add your thoughts on this
>> issue.
>> /Craig
>
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/