Re: [Building Sakai] Confirmation on Tomcat and Maven version for Sakai 2.9

Answers inline!

On Thu, Apr 19, 2012 at 7:15 PM, Mustansar Mehmood <mustansar@...> wrote:

Hi,
   I may have missed some announcements and am a bit confused about the proper version requirements for Sakai 2.9.
1- What tomcat version is recommended for Sakai 2.9.x. I think it is 7 what confuses me is that what happens when we dont follow the optional steps in the development walk through tutorial
https://confluence.sakaiproject.org/display/BOOT/Development+Environment+Setup+Walkthrough

1. [OPTIONAL] Delete the default webapps from the webapps dir

   rm -rf webapps/*
   

2. Configure tomcat 7 to use the old tomcat 5.5 classloader dirs
   1. Edit conf/catalina.properties

      1. Add the following to the line that begins with "common.loader=..."

         ,${catalina.base}/common/classes/,${catalina.base}/common/lib/*.jar
         

      2. Add the following to the line that begins with "shared.loader=..."

         ${catalina.base}/shared/classes/,${catalina.base}/shared/lib/*.jar
         

      3. Add the following to the line that begins with "server.loader=..."

         ${catalina.base}/server/classes/,${catalina.base}/server/lib/*.jar
         

   2. [OPTIONAL] Create the directories

      mkdir -p shared/classes shared/lib common/classes common/lib server/classes server/lib

Tomcat 7 is recommended for Sakai 2.9.x. I believe the TCC even went as far as saying Tomcat 7 was required.

https://confluence.sakaiproject.org/display/TCC/2011+TCC+Voting+Summary 

If you build with the -P pack-demo target, it correctly modifies these properties and startup files so it works according to the directions, otherwise you'll have to do it manually. When Sakai 2.9 is officially released this will get a prominent section in the release notes. The optional steps 1a is just a cleanup (to remove the default webapps that tomcat deploys like ROOT) and the optional b.ii. isn't really necessary because when you unpack the binary or do a deploy, it will make those directories anyway. 

Before Sakai 2.9 is released I plan on writing up a split configuration which we used at Michigan that has the CATALINA_HOME (the tomcat files) separate from the CATALINA_BASE (the Sakai binaries). This is pretty cool because it allows you to do much easier upgrades of both tomcat and Sakai, and also works well with how many distributions (like unix) deploy their tomcat. Though ubuntu has the concept of a private instance installer as well as the global instance now, so it's not that big of a deal. :) 

 

2- Do we need to change this line in settings.xml
 <appserver.id>tomcat5x</appserver.id> to reflect tomcat 7?

I wasn't sure what this was used for. I searched the trunk-all and it's in 2 files

reset-pass/account-validator-tool/pom.xml

25:      <appserver.id>${sakai.appserver.id}</appserver.id>

site-manage/site-manage-participant-helper/pom.xml

26:        <appserver.id>${sakai.appserver.id}</appserver.id>

However it's just being used "as properties" and appserver.id isn't even used. So since I've never defined it, I don't think it's useful. ;) (If it is maybe someone else could say, but it's never broke anything for me not having it)

Secondly, is sakai 2.9.x supposed to with with maven 3 ?  If so I am getting errors in building Fresh copy of Sakai-2.9.x-all

Maven 2 OUTPUT
==========
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

This error is based on the JDK 7. Earle did some work to make trunk compatible with JDK 7 but we didn't merge many of these back to 2.9.x yet. Since Java 6 is EOL in November 2012, I think that these all should get merged. This is tracked on SAK-20908 and the specific merge for search was at https://source.sakaiproject.org/viewsvn?view=revision&revision=104897. 2.9.x-all as of *today* won't build and many tests fail under JDK 7, and it's still being released with JDK 7. I believe it should still be compiled with a JDK 6 target but should run and compile under 7.

As far as the maven version, Maven 3 is recommended. The way indies are released they will cause checksum errors on the metadata if you try to build 2.9.x (the non-all version) with Maven 2, but it still works.