This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Essential Source Root / Incomplete ClassPath Support | ||
---|---|---|---|
Product: | java | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Classpath | Assignee: | Tomas Zezula <tzezula> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mkleint |
Priority: | P2 | Keywords: | PLAN |
Version: | 7.4 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
please note the following changeset applied to trunk. It causes the maven projects not to fire changes when the project turns unloadable/broken. http://hg.netbeans.org/core-main/rev/70e1a5cd79ab Isn't this fixed? |
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 > complete. > > 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.