eclipse setup using cvs

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. Ultimately, I want to be able to modify, and deploy changes on a submodule (tool) level.

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.

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 (if you did replace all the Root files with the Root.bak files: find . -name Root -exec mv '{}.bak' {} \; ), run this:

find . -name Root -exec sed -r -i.bak2 '{s/sakai_anon_cvs/sakai@cvs\.sakaiproject\.org/}' {} \;

... to change the cvs metafile reference (sakai_anon_cvs) to a hard server reference and username which eclipse seems to prefer. Make sure that the dsa signature file has been added to eclipse (preferences->cvs...). Note that this makes Root.bak2 files as a fallback.

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).... (see first comment below about importing)
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.

Debugging with Remote Tomcat

• Start tomcat using

  catalina.sh jpda start

  ..or using the tomcat plugin

• Inside eclipse select Run->debug....select Remote Java Application and click 'New...'
• Give the new debug config a name like 'Testing'
• Set the host and port (default on tomcat is 8000), choose an eclipse project by using the browse button
• source locations should be already be set to project source locations, so shouldn't need to change anything
• Checkmark the 'Allow temination of remote VM'
• click close and save changes

Test it out

• Open the src/java/org/sakaiproject/portal/varuna/VarunaServlet.java file in the portal module and scroll to the doGet() method
• double-click in the left margin (or use another method) to set a break-point near the beginning of the method
• select Run->Debug... and select the newly created debug config.
• change to the debug perspective if it does not happen automagically.
• switch to a browser and login into to the sakai instance

.... since basically all requests are being sent throught the portal webapp, the login should freeze.

• switch back to eclipse. The breakpoint line should be highlighted.

to resume the thread rightclick the highlighted (paused) thread in the upper-left panel of the debug perspective and select Resume from the context menu. Alternatively, select the thread and press the F8 key. Remember the breakpoint will stop the server everytime until the breakpoint is cleared (double-click it) or eclipse stops running.

JSP plugin

A common problem with JSP/HTML editor plugins is SWT library issues. This is from a myeclipse faq (#9) (http://myeclipseide.com/enterpriseworkbench/help/index.jsp?topic=/com.genuitec.myeclipse.doc/html/quickstarts/htmleditor/index.html):

... but don't do all that. I just created the /etc/gre.conf file and for the path I used '/usr/lib/firefox-1.0.2' ... but you can also use anu mozilla 1.6+ path like RHWS 4's /usr/lib/mozilla-1.7.8