Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

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 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).... (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

Assumptions:

  1. you have tcsh, and
  2. you installed the sysdeo.com tomcat plugin

To add tomcat natures without all the repetitive typing, pointing, and, especially, clicking:

Run this scriptlet in the sakai modules' root directory:

addTomcatNatures.tcsh
#!/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
  • 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 VarunaServlet.java file 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.

  • No labels