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.
Probably since no one should be mounting anything anymore, it is safe to deprecate some methods like add/removeFileSystem, add/removeFileChangeListener, etc.
There is requested to deprecate now-inappropriate Repository methods which means all methods except: - getDefault - getDefaultFileSystem (there is no other way how to get SystemFileSystem now) Priority: crucial Justification [just copy & pasted from jglick's mail]: The previous semantics of Repository are broken, but we already were totally changing the semantics of Repository in order to get rid of individual mounts and the classpath correspondence. What should be used instead of Repository: URLMapper is good replacement and can be considered as factory providing FileObjects. Moreover is already part of filesystem API. Concept based on URLMapper has some advantages in comparism to Repository and for example can prevent from: - providing duplicit instances of FileObjects - clashes caused by naming convention used by Repository (resource name didn't contain any information about which protocol is requested ) Backward compatibility: Backward compatibility is broken cause MasterFS isn't part of Repository. The same is true for JarFileSystems provided by ArchivURLMapper without putting them into Repository which has its technical background. See comment written up be Jesse: "ArchiveURLMapper cannot mount anything to Repository - it would be a memory leak. Anyone relying on useful FileObject's being in the Repository will find out that it is not always true, at least for JAR entries, and we cannot make it always true." Putting MasterFS into Repository would be just half way backward compatibility that wouldn't be sufficient anyway.
Agreed with summary in last comment.
There is a difference between deprecation and what is really happening. Deprecation of Repository is fine. Breaking Repository by not having "visible" filesystems in it is not that fine, because we would have to make sure that it is really not used. Filled issue 42862 to track one of the possible problems. As reviewers thought that even partial backward compatibility is better than none, they believe the most bug 42862 could be make less important by including master fs - the most "visible" fs in repository.
Partial backward compatibility seems to me like inconsistency which cause that code is unreliable, hardly testable and so on.
Mentioned Repository methods will be deprecated (#42862 was already fixed).
Radek, still not done?
This isssue means just changes in documentation thus I preffered other issues that seemed to be more risky (defacto is Repository already dead because there isn't nothing stored in it - except SystemFileSystem). Will be fixed ASAP.
/cvs/openide/src/org/openide/filesystems/Repository.java,v <-- new revision: 1.51; previous revision: 1.50 /cvs/openide/api/doc/changes/apichanges.xml,v <-- apichanges.xm new revision: 1.203; previous revision: 1.202