On 05/06/2010 10:16 AM, Gary Weaver wrote:
Eric,

Thanks! A few questions:

* Is there any advantage of working with trunk currently vs. the 3.2.1 release 
for those who would really like to be prepared for/use uP 3.3 (well, 
specifically JSR-286/Pluto 2)?
No, from a portlet developer's point of view it is either 168 or 286. If you want to play with 286 dev while we get pluto 2 integrated into uPortal you can give their little development portal a try. It has full 286 support in a very simple portal UI.

* Should trunk be working via same method as used below for setup and/or is 
there an easier/preferred way to set it up?
Yes that should work.

* Could you provide a SWAG (like<= few days,<= few weeks,<= month,<= few 
months,<= several months, etc. - no one would hold you to the guess, but just to help with 
our planning) for when the working-pluto-2.0 branch might be stable enough to be merged back 
into trunk?
I have been well learned to not provide these ... especially with a 4 week old baby at home :) I know there is at least another ~ 40 hours of dedicated dev time going into the pluto 2 work this month. As soon as we have something working in the branch it will be merged back into trunk and we'll cut a M1 release which will include a quickstart.

Also, please let me know if I can help work on anything here or there while I 
have a chance (as non-committer, just providing patches) that would help get uP 
3.3 out more quickly. No job is too small or tedious if it needs to be done, 
although I can't guarantee how much time I would have to work on tasks.
Hrm, when I switch back to uPortal coding next week from my normally scheduled work I'll take a run through the tasks and post a list here that would be good for folks with time to take a look at.

Thanks,
-Eric

Thanks!
Gary

On May 5, 2010, at 6:31 PM, Eric Dalquist wrote:

Nope it is not working. Wait for pluto 2 to be merged back into trunk.

On 5/5/10 4:09 PM, Gary Weaver wrote:
Know you guys are busy, but was hoping to try to start building against the 
pluto 2 dev version of uPortal.

At first I looked at trunk, and after a while I noticed it was still using 
Pluto 1.1.7.

So then I found https://www.ja-sig.org/svn/uPortal/branches/working-pluto-2.0 
and figured out that I could do the following to setup a build environment:

* Be sure JAVA_HOME set to Java 1.6 for each terminal window opened. (I set 
TOMCAT_HOME also)
* Setup a clean Tomcat 6.
* (Read http://www.ja-sig.org/wiki/display/UPM31/01+Tomcat )
** Set following to conf/catalina.properties
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar

** Add emptySessionPath="true" to relevant connectors in conf/server.xml (like 
connector on port 8080)

* Create (tomcat6)/shared/lib and (tomcat6)/shared/classes directories
* Alter (tomcat6)/bin/catalina.sh (or .bat but this is for .sh) to up memory:
JAVA_OPTS="$JAVA_OPTS -Xmx1024m -XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled"
Do that outside of any conditionals/if's for example:

...
if [ -z "$LOGGING_MANAGER" ]; then
   JAVA_OPTS="$JAVA_OPTS 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager"
else
   JAVA_OPTS="$JAVA_OPTS $LOGGING_MANAGER"
fi

JAVA_OPTS="$JAVA_OPTS -Xmx1024m -XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled"
...

* Get uPortal:

svn co https://www.ja-sig.org/svn/uPortal/branches/working-pluto-2.0/
cd working-pluto-2.0

* Copy build.properties.sample to build.properties and fill in everything. Even 
though maven.home commented out, I found it had to be set even if maven2/bin 
(mvn) was on path.
* Build/copy wars and jars:
ant deployPortletApp

* Start HSQL:
ant hsql

* In new terminal window...
* Set JAVA_HOME (and TOMCAT_HOME).
* Populate the DB (I couldn't run the init-db target it said to. instead of 
bothering to look into I ran the other one):
ant initportal

* Start tomcat.

In catalina.log there are tons of errors like:

Exception in thread "Timer-(some number)" java.lang.NoClassDefFoundError: 
org/apache/pluto/driver/container/ApplicationIdResolver

Basically it just looks as if it isn't integrated yet, so I assume it is in 
process of integration.

Not asking for an early release, but is there a good release version of that 
branch that you'd recommend I try that might be stable enough to build against 
that would provide enough value to merit not just using 3.2.1 instead?

Thanks!
Gary



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to