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 42273

Summary:	[2004-06-01] Deprecate now-inappropriate Repository methods
Product:	platform	Reporter:	Jesse Glick <jglick>
Component:	Filesystems	Assignee:	rmatous <rmatous>
Status:	RESOLVED FIXED
Severity:	blocker	Keywords:	API, API_REVIEW_FAST
Priority:	P1
Version:	4.x
Hardware:	All
OS:	All
Issue Type:	TASK	Exception Reporter:

Description Jesse Glick 2004-04-21 15:02:39 UTC

Probably since no one should be mounting anything
anymore, it is safe to deprecate some methods like
add/removeFileSystem,
add/removeFileChangeListener, etc.

Comment 1 rmatous 2004-05-04 11:23:03 UTC

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.

Comment 2 Jesse Glick 2004-05-04 18:27:29 UTC

Agreed with summary in last comment.

Comment 3 Jaroslav Tulach 2004-05-05 17:14:41 UTC

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.

Comment 4 rmatous 2004-05-06 13:06:30 UTC

Partial backward compatibility seems to me like inconsistency which
cause that code is unreliable, hardly testable and so on.

Comment 5 rmatous 2004-05-11 14:13:05 UTC

Mentioned Repository methods will be deprecated (#42862 was already
fixed).

Comment 6 _ ttran 2004-05-31 08:03:19 UTC

Radek, still not done?

Comment 7 rmatous 2004-05-31 08:27:59 UTC

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.

Comment 8 rmatous 2004-06-01 15:52:36 UTC

/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