Latest EAP Builds - Have to run/debug twice for resources to be copied

I was noticing this for teh last few builds, and a co worker is having this issue as well.


i believe it started around the time that "Processing Maven Resources" feature was added.  essenttailly, resources are not being copied to teh output directory all the time.  we then get class not found, or file not found when the app starts up and tries to read config.   Clicking run again, seems to "kick" idea, and it then takes a few more seconds to actually copy resources.  something strange is going on...you probably want this fixed before the official 8.1.1 release.  This is all interesting, because prior idea versions did not clean out the resources output so aggressivly - what i mean is that i can NOW do 2 runs in succession witth no code changes, the first succeeds, and the second i have to click run twice to get the resources copied.  but...the resources were there a minuteago for the first time i clicked "Run"!!

additionally, i am noticing libraries "dissappear" from the module config, and i have to maven sync again to get it back.

Thanks,
Trevor

5 comments
Comment actions Permalink

I would be curious to see what threads are active in intelliJ, and what OS you are using, Virus Scanner settings or other settings that might be relevant.

I haven't had to hit the run button twice, but I do have very slow 2 - 3 minutes start up times for the first test run. The second runs are unexpectedly slow at 10-15 seconds even when the test output window never lost focus from the first JUnit run. The 2+ minute Junit start times are even if I do a project rebuild right before that. These response times are suprising given that I have added a number of Virus scanning exclusions, which helped some, operate with 1 GB of Heap, and the only code(Java/Groovy etc...) is the test classes itself which number about 15 classes . By the way I am using XP 1GB Heap and McAfee virus scanning.

0
Comment actions Permalink

Rob,
You're issue seems to be something completely different. The issue
Trevor is talking about is not a timing issue, but the problem that
resources aren't copied to the output directory. So the program can't be
executed because there are some missing resources. Only after hitting
'Run' again the resources are copied and the program executes properly.

Trever,
I see the same behavior here, but I don't have any information helping
to resolve it. It doesn't happen every time, and I didn't find a pattern
about when it happens.

Rob wrote:

I would be curious to see what threads are active in intelliJ, and what OS you are using, Virus Scanner settings or other settings that might be relevent.

I haven't had to hit the run button twice, but I do have very slow 2 - 3 minutes start up times for the first test run. The second runs are unexpectedly slow at 10-15 seconds even when the test output window never lost focus from the first JUnit run. The 2+ minute Junit start times are even if I do
a project rebuild right before that. These response times are suprising given that I have added a number of Virus scaning exclusions, which help, operate with 1 GB of Heap, and the only code(Java/Groovy etc...) is the test classes itself which number about 15 classes . By the way I am using XP 1GB H
eap and McAfee virus scanning.

---
Original message URL: http://www.jetbrains.net/devnet/message/5236303#5236303


--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0
Comment actions Permalink

Maybe the problem is make-related? Does the problem also happens when
invoking Make manually before Run?

Tom

0
Comment actions Permalink

Hi .

      yes my issue is different.   i should add that it does not happen *every* time.  maybe 50%.  its a minor annoyance now, since my tests fail fast, but i thought i should report it when i noticed one of my developers with the same issue.

-Trevor

0
Comment actions Permalink

oops, forgot to add that we are using maven and I noticed this first (i believe) when some new maven resource copying feature was added to the latest eap builds.

0

Please sign in to leave a comment.