Checked out project does not compile

[GoogleCodeExporter]

What steps will reproduce the problem?

check out from svn with Aptana 151, subclipse, JDT added to Aptana, on Win XP

What is the expected output? What do you see instead?

The problems view shows these errors:
Description Resource    Path    Location    Type
Project 'persevere' is missing required library: 'C:\PROGRAM
FILES\IBM\WebSphere\AppServer1\lib\j2ee.jar'    persevere       Build path  Build
Path Problem
Project 'persevere' is missing required library: 'WEB-INF/lib/derby.jar'
persevere       Build path  Build Path Problem
Project 'persevere' is missing required source folder: 'test'   persevere   
Build path  Build Path Problem
The project cannot be built until build path errors are resolved
persevere       Unknown Java Problem
Unbound classpath variable: 'TOMCAT_HOME/lib/catalina.jar' in project
'persevere' persevere       Build path  Build Path Problem
Unbound classpath variable: 'TOMCAT_HOME/lib/jsp-api.jar' in project
'persevere' persevere       Build path  Build Path Problem

Original issue reported on code.google.com by frank.ge...@gmail.com on 20 Jul 2009 at 12:57

[GoogleCodeExporter]

It's not hard to fix. I removed all of those classpath settings and then worked 
out
the remaining compile errors.

1. add javax.servlet jar 
2. add jline jar

For Tomcat I have no solution. I just deleted the Tomcal channel for now. 

Original comment by frank.ge...@gmail.com on 20 Jul 2009 at 1:09

[GoogleCodeExporter]

I am not sure how portable .classpath really is, but I updated my jar 
references to be 
relative, and checked it in. Hopefully that should fix it. Otherwise perhaps I 
should 
remove .classpath from SVN altogether.

Original comment by kris...@gmail.com on 20 Jul 2009 at 1:49

• Changed state: Fixed

[GoogleCodeExporter]

Nonono, don't remove the .classpath! It is in fact a pleasurable experience to 
simply
check out the project and then having everything (almost) working. In the latest
version I only have a problem with the JRE variable. It's not a big deal to 
change that.

To avaoid even that you could remove the version numbers in jre1.5.0_15 and 
just call
your jre "jre" in the preferences. The advantage of this is that everybody who 
names
his jre as well "jre" doesn't get an outgoing change in .classpath.
For example my jre is called jre6 but I would rather rename it to jre than 
editing
the .classpath.

Original comment by frank.ge...@gmail.com on 20 Jul 2009 at 7:57

[GoogleCodeExporter]

OK, I updated the JRE to be a variable. Might want to check to make sure it is 
what you 
had in mind.

Original comment by kris...@gmail.com on 20 Jul 2009 at 8:28

[GoogleCodeExporter]

No, that creates a compile error. What I meant was not this

    <classpathentry kind="var" path="JRE"/>

neither

<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.
launcher.StandardVMType/jre1.5.0_15"/>

but this

<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.
launcher.StandardVMType/jre"/>

Assuming that in Preferences > Installed JRE I give the JRE I use the name 
"jre" as
at the end of the previous line, without a version number.

Original comment by frank.ge...@gmail.com on 20 Jul 2009 at 9:37

[GoogleCodeExporter]

Both the current solution (making JRE a var) and the solution proposed in 
comment 5
work, but they require developers to configure eclipse.  Eclipse seems to 
provide a
builtin way around this.  Just use:

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

That works for me with Fedora Eclipse 3.4.2.

On a related note, consider doing:

svn propset svn:eol-style native .classpath

so that it is easier for folks to create patches to .classpath.

Original comment by dean.brettle on 29 Jul 2009 at 7:34