After renaming project folder ESP-IDF build will return error:
Build directory 'd:\githubs\fmc-320\firmware\vscode\test\01-log\build'
configured for project
'd:\workspace\fmc-320\firmware\vscode\test\01-log' not
'd:\githubs\fmc-320\firmware\vscode\test\01-log'. Run 'idf.py
fullclean' to start again.
I know I can start a fresh new project with old code, but there is a clever way to do this by patching the actual project?
Usually just performing a fullclean and rebuilding is enough. Did you try?
I have an Eclipse Dynamic Web Project that has multiple deployment descriptors (2 extra) that are adversely affecting deployment:
I do not know how extra came to be, nor how to get rid of them. There is only 1 web.xml file in the project located in WebContent/WEB-INF
How do I eliminate the extra descriptors?
Edit
Created a new Dynamic Web Project in workspace. The new project only has 1 deployment descriptor:
Furthermore, the contents of the .settings folder:
Whereas the .settings folder for the project with the extra deployment descriptors:
I had the same problem and a simple right click on the project and "Refresh" erased the duplicates ones
You can also fix this issue by doing the following:
-Clean server
-Run as->Maven build...
-Goals: clean install
-Run (after completion console window should say BUILD SUCCESS.. else fix your errors..)
-Maven -> Update Project
These steps only work if you are using Maven build tool.. but they worked for me as I was facing a similar issue with multiple deployment descriptors, and because of this my server was unable to pick up my coding changes
I have a maven project on eclipse with jrebel plugin installed. Hot-deploy used to work perfectly last week but now only xhtml pages are hot-deploy. When a java class is changed it doesn't hot deploy.
What I noticed is when I changed a file and save eclipse will automatically build it. But the output folder file is not updated base on file stamp that's why jrebel doesn't pick it up. When I run maven-install it compiles everything and all the java classes are reloaded which is not efficient.
So the main problem is eclipse newly compiled classes don't go to output folder (project/target/classes), even though it's set in Build Path.
Any idea?
By default, the content of your local Maven repository is cached for a day. This can happen even for bad downloads (as I experienced). See https://stackoverflow.com/a/7421893/44089 for a short description of how to work around that.
After several minutes of testing, I found a warning on a jar file specifically guava being downloaded as dependency. I've delete in repo to be redownloaded and after that jrebel is working again.
So the problem is a corrupted jar that causes everything to be rebuild even if only a single file is changed. But the weird part is there's no corrupted file error.
I'm building my project and I get a build error from within a file that is not part of my project. The file is not listed in the project navigator or in compile sources under build phases.
I've cleaned and run many times, same result.
How do I remove this file?
The problem is in the header file, not in the implementation file, something in your code imports that header, remove that statement.
This happened to me too. The fix for me was simply to restart XCode.
I think the issue came from me renaming the class and XCode must've cached the old name.
For months now I've been having an intermittent problem where, during my ant build, one of the jar files it produces is 0 bytes in size. This 0-byte jar file ends up getting packaged in my ear file, and the subsequent deployment fails. My project structure looks like this:
myProj
myProj-common
myProj-ejb
myProj-web
The resulting build directory contains these files
lib
myProj-common.jar <-- sometimes 0 bytes
META-INF
application.xml
MANIFEST.MF
myProj-common.jar <-- never 0 bytes
myProj-ejb.jar
myProj-web.war
It is the myProj-common.jar file in lib that is 0 bytes. The one in the main build directory is always the correct size. It's unclear to me why I have two copies of the jar file in the end result. All of the ant build scripts were automatically generated by NetBeans.
I'm still learning the ins and outs of ant build files, so it's not entirely clear to me why they're so complex. I've written a somewhat minimal alternate build.xml file that I use for building the software in our Hudson environment on a Solaris server. That build never has this problem.
After upgrading from NetBeans 7.0.1 to 7.1.1, the problem has gotten a lot more frequent, and occurs whether I build the project inside of NetBeans or on the command line. The system where I'm having this problem runs Windows XP. With NB 7.0.1 I had a bad build perhaps one time in six. Now I have a -good- build maybe one time in ten.
Any pointers on where I should be looking to debug this would be most appreciated.
I know it's an old question, but sharing mi experience maybe help someone.
I've had the same issue with netbeans 8.0.2 on linux, my enterprise project lib folder look like this:
~/NetBeansProjects/myeeproject/build/lib $ ls -l
-rw-rw-r-- 1 user1 user1 16013 jan 5 11:52 my_lib.jar
-rw-rw-r-- 1 user1 user1 1489258 jan 5 11:52 my_ws_lib.jar
-rw-rw-r-- 1 user1 user1 0 jan 5 11:52 commons-lang3-3.1.jar
-rw-rw-r-- 1 user1 user1 0 jan 5 11:52 itextpdf-5.4.5.jar
-rw-rw-r-- 1 user1 user1 0 jan 5 11:52 primefaces-4.0.jar
-rw-rw-r-- 1 user1 user1 0 jan 5 11:52 primefaces-extensions-1.1.0.jar
and I cannot deploy the project to glassfish server. Doing repeately clean & build sometimes solve the problem, sometimes not, but I've found that deleting the 0-bytes jar and then doing a build (or a deploy) works every time. The problem is that if there's a file already in place netbeans simply does not copy the library, it doesn't check filesize, so deleting it force netbeans to do a fresh copy.
bye
You should be able to figure out what's happening by executing Ant with the -d (debug) and -v (verbose) flags. You could either add these flags in NetBeans, or execute the build file generated by NetBeans from the command line.
This appears to be a conflict with our whole-disk encryption software, PGP Desktop. Recently it was running in a degraded mode on my laptop, which slowed my builds down considerably, but then I never saw the problem arise. My speculation is that this left time for the lower level drivers to complete whatever actions they were taking and flush their write buffers. It looks like right now the jar file is getting copied before the write buffer flushes and therefore a 0-byte file is getting copied. Ant never sees an error, which is why there's no failure in the build process.
Unfortunately there's not much I can do, except perhaps modify the build script to throw in a delay before the jar file gets copied. Right now my workaround is to manually copy the jar after a full Clean and Build, then run Build (as opposed to Clean and Build), which only takes a few seconds to repackage the ear file.
I think the reason the problem got more prevalent when I upgraded NetBeans is that some change in the IDE made the builds run faster, and thus I ran into the buffering problem more often.
I had been having a similar issue happen to me lately as well. Just to summarize, I have an EAR file which contains a few EJB files and a WAR file. I am in a Windows 7 64-bit environment with Netbeans 7.2 and I run on a local JBoss 7 server.
I have seen this happen when I do one of two things.
When I add a jar or library to the project and then remove it
When I do a clean and build on the EAR file
I have encountered this issue so many times, it's not even funny now. I don't know if I have the exact same problem as you, but here is what solved my issue.
After removing any jars or libraries, you must clean and build. When I remove any JAR file or library, I see empty jars end up in my EAR's lib folder. Cleaning this will help reduce your issue.
Here's the main thing that happens to me.
I cleaned ALL dependency projects and the EAR file itself and ensured all /dist folders were gone.
I selected "Clean and Build" on my EAR file.
I opened the EAR file in my /dist folder and saw that there will always be at least one JAR file in my /lib folder that is "empty" or size of zero.
Clean and Build ONLY the project(s) that has the size of zero. Then select "Build" and not "Clean and Build" on your EAR file. I hope this helps.
I can only theorize that the EJB is being built twice since it's a dependency in my WAR file, and it gets copied into the /lib folder during the second build. I have not done any ant debugging, only have found that this is a solution to my problem.
Summary: Clean and Build properly and make sure you are "Clean and Build"-ing the projects that end up as size 0 in your lib folder, then hit "Build" only on your EAR file.
Good luck!
I found a solution to this problem here: https://netbeans.org/bugzilla/show_bug.cgi?id=216033
In my case (Nebeans 8.0.2), it was enough to uncheck "Compile on Save" checkbox for my enterprise application. (Project properties -> Compile -> Compile on Save)