Great, thanks Fred.
But what about my voodoo recipe; can just do a "clean install" run
configuration before I start the eclipse embedded tomcat? (And with Resolve Dependencies
off.) I already use some voodoo of trying to remember to stop tomcat before I do a
build; it used to not see the changes.
Fred Bricon wrote:
Rusty,
seems you've hit http://jira.codehaus.org/browse/MNGECLIPSE-904
For some unknown reason, test folders are not removed from the
.component file. Doesn't happen on all projects, can happen or not on
the same projects, I haven't found a pattern yet.
The best you can do for now is manually editing .component to remove
the test references as explained in MNGECLIPSE-904.
Try to relaunch "update maven configuration" afterwards to see if they
re-appear in the file.
regards,
Fred Bricon
On Fri, Jan 30, 2009 at 4:05 AM, Rusty Wright <[email protected]
<mailto:[email protected]>> wrote:
Eugene, I'll try and leave resolve dependencies off and always use
the "clean install" run configuration; do you think this will help
with the problem where it's adding the resources from
src/test/resources to the jars? At this point I can live with that.
Rusty Wright wrote:
The madness never ends!
Apparently this problem is caused by selecting the option
"Resolve dependencies from Workspace projects" in the project's
properties.
I had unchecked that but now the dependencies further down the
line aren't being put in the web app's lib directory. To recap
the dependency chain; waitlist-war depends on waitlist-web,
which depends on waitlist-core, which depends on waitlist-db.
I'm trying to add Spring Security (aka Acegi) and I've added the
requisite dependency lines in the pom for waitlist-web. I have
an eclipse Run Configuration that does dependency:analyze and
dependency:tree and the Spring Security jars are listed for
waitlist-war. And if I run my Run Configuration that has the
goals clean and package, in the target folder is the war file,
and running winzip on that shows the Spring Security jars in it.
But the waitlist-war folder down in the tomcat folder (down in
.metadata) doesn't have the Spring Security jars.
The other interesting thing is that when I turn on "Resolve
dependencies from Workspace projects" in the lib directory the 3
jar files that my project is producing, waitlist-core,
waitlist-db, and waitlist-web are named without the maven
version number; waitlist-core.jar, etc. With it off they had
the version as part of the name.
Now I am going crazy; I turned that option off, removed the
project from the servers, removed the tomcat server, quit
eclipse, started eclipse, added the tomcat, added the project to
it, and now in the lib directory the Spring Security jars are there.
Must be due to the alignment of the planets or something.
Rusty Wright wrote:
Argh, more hair pulling!
Again it's only happening with eclipse, things are fine when
I build with mvn on my unix box at the command line.
And equally maddening; it's suddenly fixed itself. I need a
bridge to jump off of.
What was happening is my xml config files in
src/test/resources were being put in the jars. I finally
realized what was happening when I was looking at the
console window and saw that logback was using
logback-test.xml instead of logback.xml (logback always uses
logback-test.xml if one is available). I had changed the
log level for org.springframework.beans to DEBUG in
logback.xml and it wasn't taking effect; it was still using
the WARN level setting in one of the logback-test.xml files.
The only thing I changed which seems to have fixed it is in
the project properties, under maven, is the box "Goals to
invoke after project clean", which has
process-test-resources in it, I cleared that for just one of
the modules, and then all of the jars stopped getting the
test resources. (I was rooting around down in the
.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpweb
folder on my Pc.) I put process-test-resources back and the
jars are still not getting the test resources.
Talk about voodoo.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
