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 Ate Douma <at...@douma.nu> on 2008/11/01 02:38:52 UTC
[VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new Pluto
2.0.0-SNAPSHOT trunk
Finally,
The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT trunk.
After many, many refactoring iterations, we now reached a clean and stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
Pluto again in the Jetspeed-2 Portal (still under development in its own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
While there are plenty of features which need "improvement" and of course lots of other cleanup/fixing issues, we don't expect *major*
changes in the API/SPI further on.
There are also still a few minor TCK 2.0 issues open, but those result from earlier changes on the trunk before this refactoring.
The refactoring branch actually is already (again) more compliant than the trunk itself.
So, we regard this task, which was primarily targeted at getting Pluto embeddable again for other portals and Jetspeed specifically, now as
finished.
Once this vote passes, we propose to *save* the current trunk by moving it to a new branch called "pre-2.0-refactoring-trunk-move".
Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to trunk.
We'd like to ask all the active Apache Portals committers and other interested members of our community to review and cast your vote now!
With kind regards,
Ate Douma
David Taylor
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Vivek Kumar <fi...@gmail.com>.
+1
Good work done.
Ate Douma wrote:
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue PLUTO-481,
> see http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
> trunk.
>
> After many, many refactoring iterations, we now reached a clean and
> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
> Pluto again in the Jetspeed-2 Portal (still under development in its
> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need "improvement" and of
> course lots of other cleanup/fixing issues, we don't expect *major*
> changes in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but those result
> from earlier changes on the trunk before this refactoring.
> The refactoring branch actually is already (again) more compliant than
> the trunk itself.
>
> So, we regard this task, which was primarily targeted at getting Pluto
> embeddable again for other portals and Jetspeed specifically, now as
> finished.
>
> Once this vote passes, we propose to *save* the current trunk by
> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
> trunk.
>
> We'd like to ask all the active Apache Portals committers and other
> interested members of our community to review and cast your vote now!
>
>
>
> With kind regards,
>
> Ate Douma
> David Taylor
>
>
>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Eric Dalquist <er...@doit.wisc.edu>.
+1
The work done looks great. uPortal will be looking at moving from Pluto
1.1 to 2.0 in early 2009 and have always planned on using the
post-refactoring code.
-Eric
Ate Douma wrote:
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue PLUTO-481,
> see http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
> trunk.
>
> After many, many refactoring iterations, we now reached a clean and
> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
> Pluto again in the Jetspeed-2 Portal (still under development in its
> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need "improvement" and of
> course lots of other cleanup/fixing issues, we don't expect *major*
> changes in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but those result
> from earlier changes on the trunk before this refactoring.
> The refactoring branch actually is already (again) more compliant than
> the trunk itself.
>
> So, we regard this task, which was primarily targeted at getting Pluto
> embeddable again for other portals and Jetspeed specifically, now as
> finished.
>
> Once this vote passes, we propose to *save* the current trunk by
> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
> trunk.
>
> We'd like to ask all the active Apache Portals committers and other
> interested members of our community to review and cast your vote now!
>
>
>
> With kind regards,
>
> Ate Douma
> David Taylor
>
>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new Pluto 2.0.0-SNAPSHOT trunk
Posted by David Sean Taylor <da...@bluesunrise.com>.
+1
On Nov 3, 2008, at 8:34 AM, Dennis Dam wrote:
> +1
>
> Ate Douma wrote:
>> Finally,
>>
>> The 2.0-spi-refactoring branch which we started for issue
>> PLUTO-481, see http://issues.apache.org/jira/browse/PLUTO-481, is
>> in our view now ready to be voted upon for promotion as the new
>> Pluto 2.0.0-SNAPSHOT trunk.
>>
>> After many, many refactoring iterations, we now reached a clean and
>> stabile new Pluto 2.0 API and SPI interfaces which allows us to
>> embed Pluto again in the Jetspeed-2 Portal (still under development
>> in its own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>>
>> While there are plenty of features which need "improvement" and of
>> course lots of other cleanup/fixing issues, we don't expect *major*
>> changes in the API/SPI further on.
>> There are also still a few minor TCK 2.0 issues open, but those
>> result from earlier changes on the trunk before this refactoring.
>> The refactoring branch actually is already (again) more compliant
>> than the trunk itself.
>>
>> So, we regard this task, which was primarily targeted at getting
>> Pluto embeddable again for other portals and Jetspeed specifically,
>> now as finished.
>>
>> Once this vote passes, we propose to *save* the current trunk by
>> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
>> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
>> trunk.
>>
>> We'd like to ask all the active Apache Portals committers and other
>> interested members of our community to review and cast your vote now!
>>
>>
>>
>> With kind regards,
>>
>> Ate Douma
>> David Taylor
>>
>>
>>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Dennis Dam <d....@onehippo.com>.
+1
Ate Douma wrote:
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue PLUTO-481,
> see http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
> trunk.
>
> After many, many refactoring iterations, we now reached a clean and
> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
> Pluto again in the Jetspeed-2 Portal (still under development in its
> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need "improvement" and of
> course lots of other cleanup/fixing issues, we don't expect *major*
> changes in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but those result
> from earlier changes on the trunk before this refactoring.
> The refactoring branch actually is already (again) more compliant than
> the trunk itself.
>
> So, we regard this task, which was primarily targeted at getting Pluto
> embeddable again for other portals and Jetspeed specifically, now as
> finished.
>
> Once this vote passes, we propose to *save* the current trunk by
> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
> trunk.
>
> We'd like to ask all the active Apache Portals committers and other
> interested members of our community to review and cast your vote now!
>
>
>
> With kind regards,
>
> Ate Douma
> David Taylor
>
>
>
Re: [RESULTS][VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring
as the new Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
Eric Dalquist wrote:
> Since I haven't had a chance to really look yet, what is ccpp?
See: http://www.jcp.org/en/jsr/detail?id=188
Support for JSR-188 is now part of the Portlet API 2.0:
PLT.11.1.4.2 The CC/PP Request Attribute
Ate
>
> -Eric
>
Re: [RESULTS][VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as
the new Pluto 2.0.0-SNAPSHOT trunk
Posted by Eric Dalquist <er...@doit.wisc.edu>.
Since I haven't had a chance to really look yet, what is ccpp?
-Eric
Ate Douma wrote:
> Ate Douma wrote:
>> Seeing all the positive votes (+7 already, no negatives), all from
>> Portals committers,
>> I'm now calling this VOTE as accepted!
>>
>> As proposed, I will move the current trunk to a separate branch
>> called "pre-2.0-spi-refactoring-trunk-move"
>> and then promote the current 2.0-spi-refactoring branch by moving it
>> as the new trunk.
> Done!
>
> For everyone having build and installed Pluto 2.0.0-SNAPSHOT before
> using the "old" trunk, nothing has changed how to build or install
> Pluto, just use (as before):
>
> mvn install
> mvn pluto:install -DinstallDir=<target dir>
>
> What *has* changed dramatically though is how Pluto depends on shared
> dependencies, now only the following jars:
>
> ccpp-1.0.jar
> portlet-api-2.0.jar
> pluto-container-api-2.0.0-SNAPSHOT
> pluto-taglib-2.0.0-SNAPSHOT.jar
>
> are needed *and* expected in your shared classpath.
>
> This means that if you want to test deploy the new trunk using a
> previously used installation directory, make *sure* to remove *all*
> the old shared dependencies first, otherwise you'll end up with
> classloader conflicts.
>
> Regards,
>
> Ate
>
>>
>> Thanks for the support guys!
>>
>> Regards,
>>
>> Ate Douma
>>
>> Ate Douma wrote:
>>> Finally,
>>>
>>> The 2.0-spi-refactoring branch which we started for issue PLUTO-481,
>>> see http://issues.apache.org/jira/browse/PLUTO-481, is in our view
>>> now ready to be voted upon for promotion as the new Pluto
>>> 2.0.0-SNAPSHOT trunk.
>>>
>>> After many, many refactoring iterations, we now reached a clean and
>>> stabile new Pluto 2.0 API and SPI interfaces which allows us to
>>> embed Pluto again in the Jetspeed-2 Portal (still under development
>>> in its own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>>>
>>> While there are plenty of features which need "improvement" and of
>>> course lots of other cleanup/fixing issues, we don't expect *major*
>>> changes in the API/SPI further on.
>>> There are also still a few minor TCK 2.0 issues open, but those
>>> result from earlier changes on the trunk before this refactoring.
>>> The refactoring branch actually is already (again) more compliant
>>> than the trunk itself.
>>>
>>> So, we regard this task, which was primarily targeted at getting
>>> Pluto embeddable again for other portals and Jetspeed specifically,
>>> now as finished.
>>>
>>> Once this vote passes, we propose to *save* the current trunk by
>>> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
>>> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
>>> trunk.
>>>
>>> We'd like to ask all the active Apache Portals committers and other
>>> interested members of our community to review and cast your vote now!
>>>
>>>
>>>
>>> With kind regards,
>>>
>>> Ate Douma
>>> David Taylor
>>>
>>>
>>>
>>>
>>
>>
>
Re: [RESULTS][VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring
as the new Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
> Seeing all the positive votes (+7 already, no negatives), all from
> Portals committers,
> I'm now calling this VOTE as accepted!
>
> As proposed, I will move the current trunk to a separate branch called
> "pre-2.0-spi-refactoring-trunk-move"
> and then promote the current 2.0-spi-refactoring branch by moving it as
> the new trunk.
Done!
For everyone having build and installed Pluto 2.0.0-SNAPSHOT before using the "old" trunk, nothing has changed how to build or install
Pluto, just use (as before):
mvn install
mvn pluto:install -DinstallDir=<target dir>
What *has* changed dramatically though is how Pluto depends on shared dependencies, now only the following jars:
ccpp-1.0.jar
portlet-api-2.0.jar
pluto-container-api-2.0.0-SNAPSHOT
pluto-taglib-2.0.0-SNAPSHOT.jar
are needed *and* expected in your shared classpath.
This means that if you want to test deploy the new trunk using a previously used installation directory, make *sure* to remove *all* the old
shared dependencies first, otherwise you'll end up with classloader conflicts.
Regards,
Ate
>
> Thanks for the support guys!
>
> Regards,
>
> Ate Douma
>
> Ate Douma wrote:
>> Finally,
>>
>> The 2.0-spi-refactoring branch which we started for issue PLUTO-481,
>> see http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
>> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
>> trunk.
>>
>> After many, many refactoring iterations, we now reached a clean and
>> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
>> Pluto again in the Jetspeed-2 Portal (still under development in its
>> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>>
>> While there are plenty of features which need "improvement" and of
>> course lots of other cleanup/fixing issues, we don't expect *major*
>> changes in the API/SPI further on.
>> There are also still a few minor TCK 2.0 issues open, but those result
>> from earlier changes on the trunk before this refactoring.
>> The refactoring branch actually is already (again) more compliant than
>> the trunk itself.
>>
>> So, we regard this task, which was primarily targeted at getting Pluto
>> embeddable again for other portals and Jetspeed specifically, now as
>> finished.
>>
>> Once this vote passes, we propose to *save* the current trunk by
>> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
>> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
>> trunk.
>>
>> We'd like to ask all the active Apache Portals committers and other
>> interested members of our community to review and cast your vote now!
>>
>>
>>
>> With kind regards,
>>
>> Ate Douma
>> David Taylor
>>
>>
>>
>>
>
>
[RESULTS][VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as
the new Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
Seeing all the positive votes (+7 already, no negatives), all from Portals committers,
I'm now calling this VOTE as accepted!
As proposed, I will move the current trunk to a separate branch called "pre-2.0-spi-refactoring-trunk-move"
and then promote the current 2.0-spi-refactoring branch by moving it as the new trunk.
Thanks for the support guys!
Regards,
Ate Douma
Ate Douma wrote:
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see
> http://issues.apache.org/jira/browse/PLUTO-481, is in our view now ready
> to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT trunk.
>
> After many, many refactoring iterations, we now reached a clean and
> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
> Pluto again in the Jetspeed-2 Portal (still under development in its own
> jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need "improvement" and of
> course lots of other cleanup/fixing issues, we don't expect *major*
> changes in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but those result
> from earlier changes on the trunk before this refactoring.
> The refactoring branch actually is already (again) more compliant than
> the trunk itself.
>
> So, we regard this task, which was primarily targeted at getting Pluto
> embeddable again for other portals and Jetspeed specifically, now as
> finished.
>
> Once this vote passes, we propose to *save* the current trunk by moving
> it to a new branch called "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to trunk.
>
> We'd like to ask all the active Apache Portals committers and other
> interested members of our community to review and cast your vote now!
>
>
>
> With kind regards,
>
> Ate Douma
> David Taylor
>
>
>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see
> http://issues.apache.org/jira/browse/PLUTO-481, is in our view now ready
> to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT trunk.
>
> After many, many refactoring iterations, we now reached a clean and
> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
> Pluto again in the Jetspeed-2 Portal (still under development in its own
> jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need "improvement" and of
> course lots of other cleanup/fixing issues, we don't expect *major*
> changes in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but those result
> from earlier changes on the trunk before this refactoring.
> The refactoring branch actually is already (again) more compliant than
> the trunk itself.
>
> So, we regard this task, which was primarily targeted at getting Pluto
> embeddable again for other portals and Jetspeed specifically, now as
> finished.
>
> Once this vote passes, we propose to *save* the current trunk by moving
> it to a new branch called "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to trunk.
>
> We'd like to ask all the active Apache Portals committers and other
> interested members of our community to review and cast your vote now!
+1
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
CDoremus@hannaford.com wrote:
> +1 to promoting 2.0-spi-refactoring to trunk.
Thanks Craig.
>
> Thanks for doing the merges. I'm really looking forward to getting Pluto
> 2.0 out the door. However, due to a death in the family, I cannot offer
> much help right now.
Oh, I'm very sorry to hear about your loss.
My sincere condolences to you and your family.
And this is definitely not the time to think about or concern yourself with things like Pluto.
Just for your information, and others interested: while we would have loved to announce the release of Pluto 2.0 here at the ApacheCon,
we think it to be just a little too early for that yet.
In the next several weeks we will continue working hard on further integration with Jetspeed and probably ironing out some more issues
within both Jetspeed and Pluto. But as soon as we think Pluto to be ready as a complete and production quality implementation of JSR-286,
we'll have it put up for release right away. So maybe, and hopefully, you'll be able to help out a little or more with that then after all.
Kind regards,
Ate
> /Craig
> -----Ate Douma <at...@douma.nu> wrote: -----
>
> >To: pluto-dev@portals.apache.org
> >From: Ate Douma <at...@douma.nu>
> >Date: 11/02/2008 06:03PM
> >Subject: Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as
> >the new Pluto 2.0.0-SNAPSHOT trunk
> >
> >Ate Douma wrote:
> >> CDoremus@hannaford.com wrote:
> >>>
> >>> This seems to indicate that you will be replacing the trunk with
> >the
> >>> 2.0-refactoring branch rather than doing a merge. Is that true? If
> >so,
> >>> there are some things that were applied to the trunk since the
> >branch was
> >>> created that were not applied to the branch. Some of them are my
> >>> fault. For
> >>> instance, I added portlet-spec-2.0.css to the trunk (and
> >references in
> >>> JSP
> >>> page(s)), but not to the 2.0-refactoring branch. I will fix this
> >>> discrepancy, but there should be a diff done between trunk and the
> >branch
> >>> to see what the major differences are before the replacement is
> >done.
> >> Hi Graig,
> >>
> >> Yes. I'm proposing to replace the trunk (after saving it as a
> >branch
> >> itself) with the 2.0-spi-refactoring branch.
> >> While there has been some changes to the trunk, most of them are
> >already
> >> applied to the branch too.
> >> And as I'd like to keep track of the svn history of all the changes
> >made
> >> to the branch, merging in from the branch isn't the best way of
> >doing
> >> that (if not extremely error prone already).
> >>
> >> Of course, you are right we need to make sure the branch actually
> >is up
> >> to date with the trunk changes too.
> >> I was under the impression that to be the case already but after
> >your
> >> comment I did run a check and found a few which haven't been
> >applied.
> >> Besides the portlet-spec-2.0.css (r667292) you mentioned already I
> >found
> >> the following which should be the complete set of outstanding
> >changes to
> >> merge to the branch before we can replace trunk with it:
> >>
> >> http://svn.apache.org/viewvc?rev=657367&view=rev(merging in doc
> >> changes from 1.1.x branch)
> >> http://svn.apache.org/viewvc?rev=667292&view=rev(your
> >> portlet-spec-2.0.css)
> >> http://svn.apache.org/viewvc?rev=671123&view=rev(site xdoc
> >update)
> >> http://svn.apache.org/viewvc?rev=671124&view=rev(site xdoc
> >update)
> >> http://svn.apache.org/viewvc?rev=678338&view=rev(site xdoc
> >update)
> >> http://svn.apache.org/viewvc?rev=685023&view=rev(Add Eric
> >Dalquist to
> >> KEYS)
> >> http://svn.apache.org/viewvc?rev=685529&view=rev(site xdoc
> >update)
> >>
> >> As you see, this is mostly outstanding changes for the xdocs,
> >besides
> >> the portlet 2.0 css change which you will apply to the branch,
> >right?
> >> I'll take care of the other merges which should be easy enough :)
> >>
> >Craig and others,
> >
> >I've now merged *all* the above outstanding changes from trunk to the
> >2.0-spi-refactoring branch, including the portlet-spec-2.0.css
> >(r667292) as it was just one new file and a single line in the
> >pluto-default-themes.jsp.
> >
> >I also threw in the Porlet 2.0 API javadocs (coming from the official
> >JSR-286 download) to be made available online, just like the 1.0 API
> >
> >javadocs. (note: svn eol-style property caused me some problems with
> >the commit, having me do it in several steps).
> >
> >AFAIK, the 2.0-spi-refactoring branch is now fully in sync with the
> >trunk.
> >
> >Regards,
> >
> >Ate
> >
> >>>
> >>> This comment does not diminish my high opinion of the the work you
> >have
> >>> done on the 2.0-refactoring branch. Pluto will be a much better
> >>> product for
> >>> having your contributions added to it. Thank you!
> >>
> >> Thank you for you support too Graig!
> >> I gather this mean +1 from you (after the above merges are done),
> >right?
> >>
> >> Regards,
> >>
> >> Ate
> >>
> >>> /Craig
> >>>
> >>> Ate Douma <at...@douma.nu> wrote on 10/31/2008 09:38:52 PM:
> >>>
> >>>> Finally,
> >>>>
> >>>> The 2.0-spi-refactoring branch which we started for issue
> >PLUTO-481, see
> >>>> http://issues.apache.org/jira/browse/PLUTO-481, is in our view
> >now
> >>>> ready to be voted upon for promotion as the new Pluto
> >2.0.0-SNAPSHOT
> >>> trunk.
> >>>> After many, many refactoring iterations, we now reached a clean
> >and
> >>>> stabile new Pluto 2.0 API and SPI interfaces which allows us to
> >embed
> >>>> Pluto again in the Jetspeed-2 Portal (still under development in
> >its
> >>>> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
> >>>>
> >>>> While there are plenty of features which need "improvement" and
> >of
> >>>> course lots of other cleanup/fixing issues, we don't expect
> >*major*
> >>>> changes in the API/SPI further on.
> >>>> There are also still a few minor TCK 2.0 issues open, but those
> >>>> result from earlier changes on the trunk before this
> >refactoring.
> >>>> The refactoring branch actually is already (again) more
> >compliant
> >>>> than the trunk itself.
> >>>>
> >>>> So, we regard this task, which was primarily targeted at getting
> >>>> Pluto embeddable again for other portals and Jetspeed
> >specifically, now
> >>> as
> >>>> finished.
> >>>>
> >>>> Once this vote passes, we propose to *save* the current trunk by
> >>>> moving it to a new branch called
> >"pre-2.0-refactoring-trunk-move".
> >>>> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted
> >to
> >>> trunk.
> >>>> We'd like to ask all the active Apache Portals committers and
> >other
> >>>> interested members of our community to review and cast your vote
> >now!
> >>>>
> >>>>
> >>>>
> >>>> With kind regards,
> >>>>
> >>>> Ate Douma
> >>>> David Taylor
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
> CDoremus@hannaford.com wrote:
>>
>> This seems to indicate that you will be replacing the trunk with the
>> 2.0-refactoring branch rather than doing a merge. Is that true? If so,
>> there are some things that were applied to the trunk since the branch was
>> created that were not applied to the branch. Some of them are my
>> fault. For
>> instance, I added portlet-spec-2.0.css to the trunk (and references in
>> JSP
>> page(s)), but not to the 2.0-refactoring branch. I will fix this
>> discrepancy, but there should be a diff done between trunk and the branch
>> to see what the major differences are before the replacement is done.
> Hi Graig,
>
> Yes. I'm proposing to replace the trunk (after saving it as a branch
> itself) with the 2.0-spi-refactoring branch.
> While there has been some changes to the trunk, most of them are already
> applied to the branch too.
> And as I'd like to keep track of the svn history of all the changes made
> to the branch, merging in from the branch isn't the best way of doing
> that (if not extremely error prone already).
>
> Of course, you are right we need to make sure the branch actually is up
> to date with the trunk changes too.
> I was under the impression that to be the case already but after your
> comment I did run a check and found a few which haven't been applied.
> Besides the portlet-spec-2.0.css (r667292) you mentioned already I found
> the following which should be the complete set of outstanding changes to
> merge to the branch before we can replace trunk with it:
>
> http://svn.apache.org/viewvc?rev=657367&view=rev (merging in doc
> changes from 1.1.x branch)
> http://svn.apache.org/viewvc?rev=667292&view=rev (your
> portlet-spec-2.0.css)
> http://svn.apache.org/viewvc?rev=671123&view=rev (site xdoc update)
> http://svn.apache.org/viewvc?rev=671124&view=rev (site xdoc update)
> http://svn.apache.org/viewvc?rev=678338&view=rev (site xdoc update)
> http://svn.apache.org/viewvc?rev=685023&view=rev (Add Eric Dalquist to
> KEYS)
> http://svn.apache.org/viewvc?rev=685529&view=rev (site xdoc update)
>
> As you see, this is mostly outstanding changes for the xdocs, besides
> the portlet 2.0 css change which you will apply to the branch, right?
> I'll take care of the other merges which should be easy enough :)
>
Craig and others,
I've now merged *all* the above outstanding changes from trunk to the 2.0-spi-refactoring branch, including the portlet-spec-2.0.css
(r667292) as it was just one new file and a single line in the pluto-default-themes.jsp.
I also threw in the Porlet 2.0 API javadocs (coming from the official JSR-286 download) to be made available online, just like the 1.0 API
javadocs. (note: svn eol-style property caused me some problems with the commit, having me do it in several steps).
AFAIK, the 2.0-spi-refactoring branch is now fully in sync with the trunk.
Regards,
Ate
>>
>> This comment does not diminish my high opinion of the the work you have
>> done on the 2.0-refactoring branch. Pluto will be a much better
>> product for
>> having your contributions added to it. Thank you!
>
> Thank you for you support too Graig!
> I gather this mean +1 from you (after the above merges are done), right?
>
> Regards,
>
> Ate
>
>> /Craig
>>
>> Ate Douma <at...@douma.nu> wrote on 10/31/2008 09:38:52 PM:
>>
>>> Finally,
>>>
>>> The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see
>>> http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
>>> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
>> trunk.
>>> After many, many refactoring iterations, we now reached a clean and
>>> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
>>> Pluto again in the Jetspeed-2 Portal (still under development in its
>>> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>>>
>>> While there are plenty of features which need "improvement" and of
>>> course lots of other cleanup/fixing issues, we don't expect *major*
>>> changes in the API/SPI further on.
>>> There are also still a few minor TCK 2.0 issues open, but those
>>> result from earlier changes on the trunk before this refactoring.
>>> The refactoring branch actually is already (again) more compliant
>>> than the trunk itself.
>>>
>>> So, we regard this task, which was primarily targeted at getting
>>> Pluto embeddable again for other portals and Jetspeed specifically, now
>> as
>>> finished.
>>>
>>> Once this vote passes, we propose to *save* the current trunk by
>>> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
>>> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
>> trunk.
>>> We'd like to ask all the active Apache Portals committers and other
>>> interested members of our community to review and cast your vote now!
>>>
>>>
>>>
>>> With kind regards,
>>>
>>> Ate Douma
>>> David Taylor
>>>
>>>
>>>
>>
>>
>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
> CDoremus@hannaford.com wrote:
>>
> Hi Graig,
Craig, sorry about the typo to your name above which was just pointed out to me :)
Regards,
Ate
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new
Pluto 2.0.0-SNAPSHOT trunk
Posted by Ate Douma <at...@douma.nu>.
CDoremus@hannaford.com wrote:
>
> This seems to indicate that you will be replacing the trunk with the
> 2.0-refactoring branch rather than doing a merge. Is that true? If so,
> there are some things that were applied to the trunk since the branch was
> created that were not applied to the branch. Some of them are my fault. For
> instance, I added portlet-spec-2.0.css to the trunk (and references in JSP
> page(s)), but not to the 2.0-refactoring branch. I will fix this
> discrepancy, but there should be a diff done between trunk and the branch
> to see what the major differences are before the replacement is done.
Hi Graig,
Yes. I'm proposing to replace the trunk (after saving it as a branch itself) with the 2.0-spi-refactoring branch.
While there has been some changes to the trunk, most of them are already applied to the branch too.
And as I'd like to keep track of the svn history of all the changes made to the branch, merging in from the branch isn't the best way of
doing that (if not extremely error prone already).
Of course, you are right we need to make sure the branch actually is up to date with the trunk changes too.
I was under the impression that to be the case already but after your comment I did run a check and found a few which haven't been applied.
Besides the portlet-spec-2.0.css (r667292) you mentioned already I found the following which should be the complete set of outstanding
changes to merge to the branch before we can replace trunk with it:
http://svn.apache.org/viewvc?rev=657367&view=rev (merging in doc changes from 1.1.x branch)
http://svn.apache.org/viewvc?rev=667292&view=rev (your portlet-spec-2.0.css)
http://svn.apache.org/viewvc?rev=671123&view=rev (site xdoc update)
http://svn.apache.org/viewvc?rev=671124&view=rev (site xdoc update)
http://svn.apache.org/viewvc?rev=678338&view=rev (site xdoc update)
http://svn.apache.org/viewvc?rev=685023&view=rev (Add Eric Dalquist to KEYS)
http://svn.apache.org/viewvc?rev=685529&view=rev (site xdoc update)
As you see, this is mostly outstanding changes for the xdocs, besides the portlet 2.0 css change which you will apply to the branch, right?
I'll take care of the other merges which should be easy enough :)
>
> This comment does not diminish my high opinion of the the work you have
> done on the 2.0-refactoring branch. Pluto will be a much better product for
> having your contributions added to it. Thank you!
Thank you for you support too Graig!
I gather this mean +1 from you (after the above merges are done), right?
Regards,
Ate
> /Craig
>
> Ate Douma <at...@douma.nu> wrote on 10/31/2008 09:38:52 PM:
>
>> Finally,
>>
>> The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see
>> http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
>> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
> trunk.
>> After many, many refactoring iterations, we now reached a clean and
>> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
>> Pluto again in the Jetspeed-2 Portal (still under development in its
>> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>>
>> While there are plenty of features which need "improvement" and of
>> course lots of other cleanup/fixing issues, we don't expect *major*
>> changes in the API/SPI further on.
>> There are also still a few minor TCK 2.0 issues open, but those
>> result from earlier changes on the trunk before this refactoring.
>> The refactoring branch actually is already (again) more compliant
>> than the trunk itself.
>>
>> So, we regard this task, which was primarily targeted at getting
>> Pluto embeddable again for other portals and Jetspeed specifically, now
> as
>> finished.
>>
>> Once this vote passes, we propose to *save* the current trunk by
>> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
>> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
> trunk.
>> We'd like to ask all the active Apache Portals committers and other
>> interested members of our community to review and cast your vote now!
>>
>>
>>
>> With kind regards,
>>
>> Ate Douma
>> David Taylor
>>
>>
>>
>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new Pluto
2.0.0-SNAPSHOT trunk
Posted by CD...@hannaford.com.
This seems to indicate that you will be replacing the trunk with the
2.0-refactoring branch rather than doing a merge. Is that true? If so,
there are some things that were applied to the trunk since the branch was
created that were not applied to the branch. Some of them are my fault. For
instance, I added portlet-spec-2.0.css to the trunk (and references in JSP
page(s)), but not to the 2.0-refactoring branch. I will fix this
discrepancy, but there should be a diff done between trunk and the branch
to see what the major differences are before the replacement is done.
This comment does not diminish my high opinion of the the work you have
done on the 2.0-refactoring branch. Pluto will be a much better product for
having your contributions added to it. Thank you!
/Craig
Ate Douma <at...@douma.nu> wrote on 10/31/2008 09:38:52 PM:
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue PLUTO-481, see
> http://issues.apache.org/jira/browse/PLUTO-481, is in our view now
> ready to be voted upon for promotion as the new Pluto 2.0.0-SNAPSHOT
trunk.
>
> After many, many refactoring iterations, we now reached a clean and
> stabile new Pluto 2.0 API and SPI interfaces which allows us to embed
> Pluto again in the Jetspeed-2 Portal (still under development in its
> own jetspeed-2 branch JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need "improvement" and of
> course lots of other cleanup/fixing issues, we don't expect *major*
> changes in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but those
> result from earlier changes on the trunk before this refactoring.
> The refactoring branch actually is already (again) more compliant
> than the trunk itself.
>
> So, we regard this task, which was primarily targeted at getting
> Pluto embeddable again for other portals and Jetspeed specifically, now
as
> finished.
>
> Once this vote passes, we propose to *save* the current trunk by
> moving it to a new branch called "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be moved/promoted to
trunk.
>
> We'd like to ask all the active Apache Portals committers and other
> interested members of our community to review and cast your vote now!
>
>
>
> With kind regards,
>
> Ate Douma
> David Taylor
>
>
>
Re: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new Pluto 2.0.0-SNAPSHOT trunk
Posted by Woonsan Ko <wo...@yahoo.com>.
+1
--- On Sat, 11/1/08, Ate Douma <at...@douma.nu> wrote:
> From: Ate Douma <at...@douma.nu>
> Subject: [VOTE] PLUTO-481: Promote branch 2.0-spi-refactoring as the new Pluto 2.0.0-SNAPSHOT trunk
> To: "Pluto Developers List" <pl...@portals.apache.org>
> Date: Saturday, November 1, 2008, 2:38 AM
> Finally,
>
> The 2.0-spi-refactoring branch which we started for issue
> PLUTO-481, see
> http://issues.apache.org/jira/browse/PLUTO-481, is in our
> view now ready to be voted upon for promotion as the new
> Pluto 2.0.0-SNAPSHOT trunk.
>
> After many, many refactoring iterations, we now reached a
> clean and stabile new Pluto 2.0 API and SPI interfaces which
> allows us to embed Pluto again in the Jetspeed-2 Portal
> (still under development in its own jetspeed-2 branch
> JS2-871-pluto-2.0-upgrade).
>
> While there are plenty of features which need
> "improvement" and of course lots of other
> cleanup/fixing issues, we don't expect *major* changes
> in the API/SPI further on.
> There are also still a few minor TCK 2.0 issues open, but
> those result from earlier changes on the trunk before this
> refactoring.
> The refactoring branch actually is already (again) more
> compliant than the trunk itself.
>
> So, we regard this task, which was primarily targeted at
> getting Pluto embeddable again for other portals and
> Jetspeed specifically, now as finished.
>
> Once this vote passes, we propose to *save* the current
> trunk by moving it to a new branch called
> "pre-2.0-refactoring-trunk-move".
> Thereafter, the 2.0-spi-refactoring branch can be
> moved/promoted to trunk.
>
> We'd like to ask all the active Apache Portals
> committers and other interested members of our community to
> review and cast your vote now!
>
>
>
> With kind regards,
>
> Ate Douma
> David Taylor