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