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.
see subject. in current codebase the project needs to be loaded, it's lookup constructed and the ProjectInformation looked up in order to annotate the folder icon in the project chooser. That's memory and CPU inefficient
Created attachment 74172 [details] basic diff
a simple sketch that works, todos: dummy names ending with 2 need probably better wording no apichanges dialog only maven project type rewritten to use the new api.
[JG01] ImageUtilities.loadImage should be called with a 2nd arg 'true'. [JG02] I don't see ProjectFactory2 here - maybe forgot to 'hg add'? [JG03] If you are speeding up icon loading, you can surely retune ProjectChooserAccessory's badging tactic. It might be feasible to make it badge synchronously. (Try on a cold disk.) If not, you can at least reduce or eliminate the schedule delay in the badger task. [JG04] Might be handy for Result.getIcon to have a 'boolean forceLoad' param, which if true would do the logic PCA is doing now in 'if (icon == null) {...}'. Just test carefully on projects that e.g. have invalid project.xml files or are otherwise unloadable. [JG05] OpenProject.java change is unnecessary. [JG06] Perhaps Result should be abstract, and an icon should be produced only on demand. Consider Ant-based projects. It is quick to tell if Result should be non-null: whether project.xml exists or not. But parsing project.xml to find the specific type is more expensive, and some code may only be interested in whether the folder is a project, but not interested in the icon, so it should not have to pay for the parsing. Of course the primary code calling isProject is PCA, which wants the icon, but we would be penalizing any other code. If PM.isProject (not iP2) still called old PF.iP then this would not be an issue, but your current patch makes PM.iP delegate to iP2. A related question is how you avoid parsing project.xml a second time if and when the Project is actually to be loaded. Currently ABPFS parses project.xml only once, when PF.loadProject is called. But if it needs to parse project.xml just to get an icon, and then later lP is called, how could it avoid reparsing it? Maybe this is a minor enough issue that it would suffice to rely on warm disk caches, and assume that the icon parse (with no validation enabled) is fast enough. If it seems important, a WeakHashMap<FileObject,Document> cache (as mentioned in a separate issue) would be the obvious approach, but then you need to deal with the file being modified on disk after the cache is created but before the project is loaded. (Once the project is loaded, APH tracks file changes on disk.)
JG01 done JG02 forgot to add indeed, has just method ProjectManager.Result isProject2(FileObject projectDirectory); JG03 definitely TBD, maybe at the time most frequent project types use ProjectFactory2 JG04 I was thinking of providing special impl of Icon in case someone needs such a lazy loading. If the class turns into abstract (or non final only) we can remove the Result(Icon) constructor JG05 just a sideeffect or the repository wide commit
Created attachment 75471 [details] complete list of changes associated with the issue
please review. The changes in APIs for projectapi and project.ant are intended to prevent project loading in the open project dialog. JG01-06 shall be addressed now, I upgraded the spec versions, implemented the new apis in j2se, web, apisupport and maven modules, added javadoc and apichanges. the attached diff is produced by hg out -p, I haven't figured any way of showing the complete diff of local changes.
Regarding a diff: call the base rev (parent of c682e4092760 in this case) $base. Then run hg di -r $base -r tip If you do any merges from trunk, then you would use the trunk parent of the merge as your new base rev. A bit of work but the result is correct; see also http://www.selenic.com/mercurial/bts/issue28 You can also try http://wiki.netbeans.org/HgHowTos#section-HgHowTos-DevelopAPIReviewPatchesUsingMQ if you prefer that style. BTW it is a good idea to set [diff] git=1
re diff: Unfortunately I have 2 large scale merges in between the relevant local changes. Diff produced wrong results. I'd like to integrate in the coming days, please speak up if you strongly oppose the move.
As I say, having merges in between the local changes should not be a problem so long as you set the base revision for the diff correctly, to the remote changeset from the last such merge. If you can't figure it out quickly, just attach a bundle (hg bundle /tmp/153923.hg) and I can try to produce the diff for you.
[JG07] "{@link projectManager.Result}" is not going to work. [JG08] Why is Exceptions.printStackTrace commented out in AntBasedProjectFactorySingleton? [JG09] I guess ABPFS should return something non-null for an old ABPT provider. I think there needs to be some way for a Result to be constructed with an unknown icon. [JG11] Why the Result(String) constructor? Result(Icon) seems enough to me.
Created attachment 75753 [details] new patch
final diff attached. JG07+JG11 done. JG08+JG09 - good catch, thanks. i've reworked the way Ant factory works, as the ProjectManager.isProject() javadoc states, the method shall be "optimistic" in the sense that it can report false positives, but shall not report false negatives. That was not the case with the previous ant implementation, shall be better now. I've pushes the bits to main.
Integrated into 'main-golden', will be available in build *200901140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c682e4092760 User: Milos Kleint <mkleint@netbeans.org> Log: #153923 extend ProjectFactory to provide a project icon and rewrite the project open dialog to utilize it