Small nuisance - having to "repair IDE" and rebuild the whole project every time I restart IDEA Ultimate.

Hello, Bruno!

Thank you for reporting this!

I'm assuming you are referring to IDEA's Artifacts, correct?

Are those derived automatically from the Maven configuration or configured manually?

What are the exact errors messages you're getting when the issue occurs?

The builds are Maven builds, one project, and about 10-20 modules, most of them producing WARs.

What breaks seems to be corrupt zips(or more likely the wars) for a set of modules within the project.   Zips that were fine before shutdown the night before but are corrupt the next morning.

The normal complaint is that one of those WARs failed.

What I found to be reliable in band-aiding it for the day is to:

• Repair IDE.
• Invalidate caches.
• Rebuild whole project using Maven.
• Launch.

Also, it doesn't happen every day, but nearly every day.  It did not seem to happen this morning.

My hope is that when 2025.1 becomes the stable version and I download it… this will go away.

Bruno Genovese I would appreciate more details on how exactly the issue manifests:

• What indication does IDEA give that the JARs/WARs are corrupt?
• How said JARs/WARs are used? I'm assuming you're deploying them to an Application Server?

Based on what I know so far, I would guess a third-party interference, i. e. something other than IDEA touches the files (or perhaps IDEA's caches), possibly modifying their contents and/or metadata, which causes IDEA to consider them invalid.

I encourage you to give 2025.1 EAP a try as well - you can install it side-by-side with your current instance of IDEA.

I am trying to replicate the problem.  Unfortunately it does not happen every single day and it only happens when I first start the computer, IntelliJ Idea and attempt to run.  Sometimes it happens every day, sometimes it works fine for a few days in a row.   So it might be a bit before I can give you a precise error message.

In the meantime I can give you more details:

• The “applications” are all constructed in a single project, each as a module.
• One module is a simple library compiled as a JAR.
• Another module is a “command line” Spring Boot application with a thread that runs continuously, and several REST services running on the embedded Tomcat of Spring Boot and listening on port 8443.
• The rest of the modules are either REST services, each compiled as a WAR and deployed on and actual Tomcat 10, listening to port 443, or very small JAR libraries containing a few objects used by the corresponding WAR-deployed REST service.   These JAR libraries allow referring to the JSON-passed data as objects in both the client and REST service.  Nothing fancy.
• The whole thing is built with MAVEN.   It can be built module by module, but for safety I usually build the whole project (including every module).
• Typical execution involves (1) running the configuration of the command-line app, and (2) running a configuration that includes a few (3-6) of the WAR assembled REST services (and/or a web application) that is also part of the overall project.

The error typically happens during deployment on the actual Tomcat 10 of the various WARs.   One or more initial WARs deploy fine, but eventually it reaches a WAR that fails to deploy thinking that the WAR is corrupt, causing the rest of the Tomcat 10 deployment to fail.

At that point nothing will make it work, not even attempting to rebuild the whole project with Maven.  Repairing the IDE and invalidating the caches first is the only way to get things back to work.  I seem to remember that at this point it is not even necessary to rebuild the project but I am not 100% certain, as I usually rebuild the full project as an extra safety.

From everything I've seen my gut instinct is to think that perhaps the WARs for the Tomcat 10 instance running in IntelliJ are being cached somewhere and somehow getting “stuck there”, and that the IDE repair/cache invalidation clears them… causing the real WARs to be copied back in from the Maven repository or the workspace.  But I have no idea why this would happen when I shutdown the IDE and computer at the end of the day and not during the day as I work on the various pieces of code, since it rebuilds fine every time I execute during the day.

I hope this helps.

P.S.: As I mentioned this is a small nuisance, and my hope is that it will fix itself when the stable version of 2025.1 is released and I switch to it, making the issue on 2024.2.0.2 Ultimate (Build #IU-242.20224.419, built on August 19, 2024) not matter anymore.   I never had this issue before this version.

Something I noticed when looking up the version in About that might be relevant:   Runtime version: 21.0.3+13-b509.4 amd64 (JCEF 122.1.9)  VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o…. but I know my CPU is an Intel 64-bit.   This might be relevant, or it might not.

Bruno Genovese Thank you for sharing the details!

What type of Run Configuration is used for those two steps:

Typical execution involves (1) running the configuration of the command-line app, and (2) running a configuration that includes a few (3-6) of the WAR assembled REST services (and/or a web application) that is also part of the overall project.

Spring Boot Run Configuration and an Application Server Run Configuration, I'm guessing?

The exact error message you are getting here:

The error typically happens during deployment on the actual Tomcat 10 of the various WARs.   One or more initial WARs deploy fine, but eventually it reaches a WAR that fails to deploy thinking that the WAR is corrupt, causing the rest of the Tomcat 10 deployment to fail.

Would be very very helpful to move the investigation forward. I would also suggest to test if the WARs actually have to be rebuilt after invalidating the caches to make the Project work again.

In regards to this issue:

Something I noticed when looking up the version in About that might be relevant:   Runtime version: 21.0.3+13-b509.4 amd64 (JCEF 122.1.9)  VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o…. but I know my CPU is an Intel 64-bit.   This might be relevant, or it might not.

amd64 is another name for x86_64 architecture, so this should not be a concern.