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]>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
>
>
>

Reply via email to