CVS-module:eclipse-project mapping (*nix)
creating a new project with cvs co of module 'sakai' from cvs.sakaiproject.org works well for getting the whole project to compile, but it does not do well for debugging,editing, and deploying using J2EE plugins (nor JSF plugins). Ideally, each submodule of the sakai module would be a seperate eclipse project.
You can check out each submodule as a seperate project by selecting the whole list (28 folders, or so) in the cvs browser and selecting the radio button to make indiv projects. But, eclipse uses the module name for the projects and not the project's .project file.
The quickest (....well not the quickest: the co from within eclipse is quick but insufficient ....) method I have found is to cvs co the sakai project from the command line. Then in eclipse import each one. See method two here: http://www.javadude.com/eclipse/convertingtojava.html ... (I like import more than the 'new java project' method)...but keep reading first.
importing into eclipse
Make sure that :
1. instead of the published cvs co command use this
cvs -q -z9 -d :ext:sakai@sakai_anon_cvs:/cvs co -r sakai_1-5-rc11 sakai
... note the username (use whatever tag is approp at the time).
2. run this command at the sakai module root dir:
find . -name Root -exec sed -r -i.bak '\{s/:ext:/:extssh:/\}' \{\} \;
... this changes the 'method' for the checkout to 'extssh' which eclipse uses the old Root files are saved to Root.bak in each directory.
3. Once your sure the last command did not fry anything, run this:
find . -name Root -exec sed -r -i.bak '{s/sakai_anon_cvs/cvs\.sakaiproject\.org/}' {} \;
... to change the cvs metafile reference (sakai_anon_cvs) to a hard server reference which eclipse seems to prefer. Make sure that the dsa signature file has been added to eclipse (preferences->cvs...). Note that this clobbers the last .bak file made.
the extssh method is the only one I have successfully used which respects the dsa signature ... the ext method keeps asking for a password.
Now you can do the imports if you have not already (if you ran the scripts above afterward, make sure you restart eclipse)....
Then for each project, 'right-click->team->share project' ... to add the cvs-connection to the project. This just a litte less tedious than tedious-as-all-get-out. Small comfort is that the sakai-reference submodule cannot have a tomcat nature (since it has no java files, I am guessing).
Maven plugin
This seems a bit buggy but it still works. The bugginess is that 1) everytime you run maven, there is a 'launch' related error and a dialog, but say 'OK' and maven runs fine.... and, 2) certain project.xml files are misinterpreted as incorrectly formatted by the validator. The dav and dav-server submodules, for example, both are flagged as having invalid formats starting after the first nested tag (<pomVersion>).... where the <name> tag starts.
Semi-automagic tomcat natures
To add tomcat natures without all the repetitive typing, pointing, and, especially, clicking:
Run this scriptlet in the sakai modules' root directory:
#!/bin/tcsh
foreach file ( `find . -name .tomcatplugin -exec dirname {} \; | awk -F'/' '{print $NF}'` )
sed -i.bak -r "{s/<warLocation>.*<\/warLocation>/<warLocation>\/usr\/local\/tomcat\/webapps\/sakai-$file.war<\/warLocation>/}" \
./$file/.tomcatplugin
sed -i.bak2 -r "{s/<webPath>.*<\/webPath>/<webPath>\/sakai-$file.war<\/webPath>/}" \
./$file/.tomcatplugin
end
foreach file ( `find . -name .project -print` )
sed -i.bak3 -r "{s/(\s+)(<nature>org.eclipse.jdt.core.javanature<\/nature>)/\1\2\n\1<nature>com.sysdeo.eclipse.tomcat.tomcatnature<\/nature>/}" $file
end
... be sure to change the \/usr\/local\/tomcat (the '/' chars are necessary additions) reference to match your tomcat install.