Probably since no one should be mounting anything
anymore, it is safe to deprecate some methods like
There is requested to deprecate now-inappropriate Repository methods
which means all methods except:
- getDefaultFileSystem (there is no other way how to get
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 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
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.
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