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.

Bug 189442 - Warning badges do not disappear from modules after parent is built
Summary: Warning badges do not disappear from modules after parent is built
Status: RESOLVED DUPLICATE of bug 175472
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on: 186024 197669
Blocks: 172502
  Show dependency tree
 
Reported: 2010-08-12 12:54 UTC by Jesse Glick
Modified: 2011-08-08 17:10 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Adds Validate correction action (4.72 KB, patch)
2010-08-19 21:36 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-08-12 12:54:37 UTC
Check out https://stapler.dev.java.net/svn/stapler/trunk/stapler/ (for example) and open in NB. There will be warning badges about missing dependencies, which is OK since the project is unbuilt. Build 'Stapler POM'. Badges remain on the modules even though their dependencies are now in the local repo. 'Show and Resolve Problems' still claims that these deps are missing. If you click 'Download Missing Dependencies', the badges go away immediately, i.e. nothing really needed to be downloaded - the IDE simply failed to notice that things had changed.

Perhaps the Maven project needs to listen to file creation events in the local repo. Or otherwise revisit any missing dependencies after a build completes.

Marking P2 since this is a major usability problem in my opinion: someone coming fresh to the Maven support with a new checkout of a project not only gets warning badges but there is no way to clear them after a build except by manually going through this dialog for every single module.
Comment 1 Jesse Glick 2010-08-12 22:29:29 UTC
Show and Resolve Problems should also perhaps offer to run 'mvn validate', which works to download missing plugins when 'Correct' is unavailable.
Comment 2 Jesse Glick 2010-08-16 20:32:52 UTC
Warning badges should also not be displayed on snapshot dependencies resolvable within the module tree.
Comment 3 Jesse Glick 2010-08-19 21:33:03 UTC
(In reply to comment #1)
> Show and Resolve Problems should also perhaps offer to run 'mvn validate',
> which works to download missing plugins when 'Correct' is unavailable.

Note that this does not work to download missing dependencies; for that you need resources:resources or resources:testResources.
Comment 4 Jesse Glick 2010-08-19 21:36:12 UTC
Created attachment 101546 [details]
Adds Validate correction action

Failed experiment, useless at least with old embedder. Some variant (moved to a different problem) might be useful with new embedder.
Comment 5 Jesse Glick 2010-08-20 17:11:00 UTC
Testing against trunk (old embedder), there are actually a number of things wrong in this scenario, which are probably no better with the new embedder.

1. Building stapler will not cause warning badges to automatically go away on stapler-groovy, even though stapler-1.151-SNAPSHOT.jar is now in the local repo; you have to reload stapler-groovy. This ought to be automatic if at all possible: the appearance of a dependency in the local repo ought to trigger a project reload. Could be accomplished via FileUtil.addFileChangeListener on relevant portions of the local repo, though the performance implications need to be checked.

2. #1 would not be as much of an issue were it not for the fact that stapler-groovy shows warning badges about a missing stapler-1.151-SNAPSHOT.jar to begin with: the IDE is already preferring stapler/src/main/java to this binary, so there is no pressing need for a warning. Could just show a dependency icon with no children - there is no JAR to expand- but no warning badge either. (#1 would still be a lower-priority problem for release artifacts used by multiple projects. For example, if several open projects declare a dep on guice.jar, and I build one of them which downloads the JAR, I would expect the warning badge to disappear from all the projects; currently it will disappear only from the one I built.)

3. Besides the "missing artifact" warnings, stapler-jelly shows Java parser errors. Not from org.kohsuke.stapler.* classes, since the IDE knows where to find sources for these; but from e.g. org.jvnet.localizer.LocaleProvider. Note that localized-1.7.jar is in the local repo, with sources and Javadoc, and is referred to without error badge from stapler/src/main/java. The problem is that stapler-jelly/pom.xml does not list this as a direct dependency, instead picking it up transitively from stapler/pom.xml. The IDE creates a dummy POM:

---%<--- /tmp/mevenide4403547231476456993pom
<project>
<modelVersion>4.0.0</modelVersion>
<packaging>pom</packaging>
<groupId>org.kohsuke.stapler</groupId>
<artifactId>stapler</artifactId>
<version>1.151-SNAPSHOT</version>
</project>
---%<---

which is fine for letting stapler-jelly be loaded without a missing dependency error, yet it misrepresents the real POM, so that the effective project model does not include the transitive dependencies.

I think the proper fix would be to change how the IDE intercepts attempts to find artifacts in the local repo. When a request is made for a *-SNAPSHOT.pom which corresponds to a known source project, serve up the pom.xml from the project's source directory (and begin listening to changes in it too).
Comment 6 Jesse Glick 2010-08-20 21:29:11 UTC
(In reply to comment #5)
> When a request is made for a *-SNAPSHOT.pom
> which corresponds to a known source project, serve up the pom.xml from the
> project's source directory (and begin listening to changes in it too).

Finally figured out how to inject at IDE_WORKSPACE, so started to do this in core-main #538506bc38af. Need bug #186024 to be fixed for it to work, though.
Comment 7 Jesse Glick 2010-08-24 17:53:06 UTC
#3 is I think fixed with core-main #bac0432e713c.
Comment 8 Jesse Glick 2010-08-24 18:21:37 UTC
#2 fixed in core-main #35150053c310. Will still show a warning badge on the dependency node, so you know it is not in the local repo, but will not produce a problem report (i.e. no badge on the project node, Show Problems, etc.). Missing dependencies which do not have a known source project correspondence will still be reported as problems.

Leaving open for #1: Reload Project is needed in cases where it should not be needed.
Comment 9 Quality Engineering 2010-08-25 03:26:20 UTC
Integrated into 'main-golden', will be available in build *201008250001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/538506bc38af
User: Jesse Glick <jglick@netbeans.org>
Log: Start of #189442: associate snapshot artifacts with their owners.
Comment 10 Quality Engineering 2010-08-26 03:22:36 UTC
Integrated into 'main-golden', will be available in build *201008260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bac0432e713c
User: Jesse Glick <jglick@netbeans.org>
Log: Part of #189442: associate missing POM artifacts with owning project's declaration.
Comment 11 Jesse Glick 2011-08-08 17:10:16 UTC
#1 is basically a duplicate.

*** This bug has been marked as a duplicate of bug 175472 ***