On 5/6/10 2:08 PM, Gary Weaver wrote:
The ant build is not required, it is there as a utility. I know Rutgers is doing complete maven overlays and has been since 3.0* 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.Basically I have a few goals (and some more questions)- 1. I want to update our portal overlay project. We have some source modifications for shib and doing custom stats (that I'm hoping to replace as much as possible with the uP 3.3 way of doing things) and the rest is config, templates, CSS, js, images, etc. I'm somewhat confused because I know that a lot of people were doing overlays with Maven 2, but the build still seems to be a hybrid of Maven and Ant. I'm guessing if I want to really be able to swap releases I should switch back to the "copy the uPortal release from svn to a tmp dir, copy our files over it, and run these commands to build"-type of overlay build vs. the pom.xml based overlay build?
A portlet is a portlet. If your JSR-168 portlet works in uPortal 3.x it will continue to work. Unless your portlet is somehow using a uPortal specific API you shouldn't need to be worried about testing portlets between versions of uPortal.2. I need to be sure our current portlets could be deployed and still run. We deployed most from the admin tool in uP 2.5.3.2, but we'd want to automate the publishing of the portlets after each time HSQL is started. What is the current way to do this?
3. Once we get all of that going and the portal skin modified, then we'll probably be looking into updating/adding portlets. We might update a few existing portlets to take advantage of new features in JSR-286, but more likely well look into using rails-portlet or similar to see how well that would work for writing new portlets or rewriting old ones to be more easily maintainable by the rest of the team. We webproxied an app Jeremy B. wrote locally that integrates with JSONP services we are providing so we might end up going that route as well. (It is more powerful since we can have services be cross-domain and the javascript can run on any site, not just within the portal.) Thanks, GaryThanks! 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
smime.p7s
Description: S/MIME Cryptographic Signature
