Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 235457 - Essential Source Root / Incomplete ClassPath Support
Essential Source Root / Incomplete ClassPath Support
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Classpath
7.4
PC Linux
: P2 (vote)
: TBD
Assigned To: Tomas Zezula
issues@java
: PLAN
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-03 12:49 UTC by Jaroslav Tulach
Modified: 2016-05-25 06:16 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2013-09-03 12:49:01 UTC
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.
Comment 1 Milos Kleint 2013-09-05 09:50:17 UTC
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
Comment 2 Jaroslav Tulach 2016-05-25 06:16:00 UTC
Isn't this fixed?


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo