While analyzing a behavior of one of our Maven users we noticed:
>> That's crucial in this particular scenario as the guy is
>> very likely purging his local repository frequently.
> Yes, our IDE infrastructure gets very confused when one removes JARs from
> .m2/repository. The Java infrastructure detects that and immediately starts
> massive rescanning of all open projects to find out they are all broken. It
> drives me mad and I know what is happening, I am not surprised unknowledgable
> users freak out even more.
> I discussed this with Tomáš Zezula two weeks ago and I believe there is an
> easy cure: disable our Java support when the (essential) classpath is not
> Why it will work? As soon as one purges its local Maven repository, the IDE
> detects the JARs are missing (as now), but (as it will know these JARs are
> essential), it just switches to lexical only editing mode suggesting the user
> to fix its classpath. Performance will be improved (as we will not waste time
> adapting to a temporary situation to be fixed soon) and the user will at least
> know what to do (run a build).
> When I was helping Tomáš Pávek with performance, we tried to address this with
> the "priming build" concept, but it was a solution from outside of the Java
> infrastructure. As far as I can tell it works only after creating/opening new
> project and not if one deletes the repository later. I believe we need to move
> the solution directly into Java/parsing infrastructure.
> How complex that can be? Easy (not considering UI changes). Just enhance our
> classpath API to allow us to mark a classpath root to be "essential". That
> means add one boolean property and use it.
> Maven and other build systems that fully manage dependencies will use this new
> property to indicate that if a JAR in .m2/repository is missing, it means the
> system state is inconsistent.
> If there is something NetBeans 8 should deliver in terms of performance, then
> I wish it is support for essential classpath roots that will address missing
> Maven artefacts problems once and forever.
> PS: Our current system shows the Ant herritige: It is quite common in Ant that
> the classpath contains references to JARs and dirs that are missing. Our Java
> infrastructure optimizes for that. I have however not yet seen a valid Maven
> project that would point to non-existing JAR in .m2/repository (Miloš can of
> course provide a contra-example). Time to fix our Java infrastructure to be
> more Maven friendly.
After today's discussion it seems that a ClassPath could have attribute "incomplete" (easier for clients to observer). The providers could on the other hand mark some roots "essential" - the infrastructure would then do the mapping of missing essential -> incomplete.
please note the following changeset applied to trunk. It causes the maven projects not to fire changes when the project turns unloadable/broken.
Isn't this fixed?