bash-3.2$ svn stat
? .classpath
? .project
? .settings
~ target
See the "~ target"? That is what I believe was the cause of a mysterious build problem. (The tilde is probably due to me changing from "svn:ignore *" inside target dir, to "svn:ignore target", after discovering that the former doesn't work well. Maybe more in other blog post.)
The symptom of the problem I've been having for a few hours can be demonstrated and summarized like this:
No problem building in maven.
Lots of errors in red in Eclipse, as if a Maven dependency is not resolved somehow.
Turning off Workspace Resolution makes the errors go away.
Conclusion: something is up with Workspace Resolution.
Theory: 1) there is something wrong with the target directory; 2) workspace resolution uses a project's target directory for dependencies (perhaps just points to $dependee_project/target/classes on the classpath).
But that seems crazy. Surely the build should care how SVN flags the target directory? But the coincidence is a bit too strong to ignore.
--
Turns out that Eclipse clean + build fixed it. Don't know why.
But the target folder had a severe SVN weirdness...
Doing "svn update target" failed bizarrely: "svn: Unable to lock 'src'". Huh?
I've never seen this 'E', existing, before. I must've managed to set a svn:ignore on it, but it existed in the repo. Or something.
Turns out that Eclipse clean + build fixed it. Don't know why.
But the target folder had a severe SVN weirdness...
Doing "svn update target" failed bizarrely: "svn: Unable to lock 'src'". Huh?
Finally it got unstuck, inside Eclipse:
E .../target
Updated to revision 23696.
===== File Statistics: =====
Existing: 1
I've never seen this 'E', existing, before. I must've managed to set a svn:ignore on it, but it existed in the repo. Or something.
No comments:
Post a Comment