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 28683 - API to find an installation-relative file
Summary: API to find an installation-relative file
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
Keywords: API, ARCH
Depends on:
Blocks: 28733 27151 27852 28376 28663 28666 28668 28729 28732 28736
  Show dependency tree
Reported: 2002-11-12 18:02 UTC by Jesse Glick
Modified: 2008-12-22 20:29 UTC (History)
7 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-11-12 18:02:20 UTC
Currently there is no supported API for finding a
file in the NetBeans installation. If something
lives in the system filesystem, you can find it
easily, even if it is packed under system/ in the
NBM rather than living in a layer. Otherwise, it
is hard.

(1) You can use ${netbeans.home} and
${netbeans.user}. But these are not supported, and
in fact issue #27151 will add a new choice.

(2) You can get a class from a module, and use
This is ugly, though; requires loading code from
the module; relies on the module JAR location;
etc. Not generally attractive.

Suggest a new service, e.g.:

public interface/abstract class
org.openide.modules.InstalledFileLocator {
     * Locate a file (or directory) in the
NetBeans installation.
     * Implementations might search netbeans.home,
     * etc.
     * @param relativePath from install root, e.g.
     * @param codeNameBase of the supplying
module; may be null if unknown
     * @param localized true to perform a
localized and branded lookup (useful for
documentation etc.)
     * @return the requested File, if it can be
found, else null
    public abstract File locate(String
relativePath, String codeNameBase, boolean localized);
     * Get the locator. Lookup is searched for all
     * locators. They are merged together and
called in sequence
     * until one of them is able to service a request.
     * If you use this call, require the token
     * org.openide.modules.InstalledFileLocator
     * to require any autoload modules which can
provide locators.
    public static InstalledFileLocator getDefault();

Possible also to replace the locate method with:

public abstract FileSystem locate(String
codeNameBase, boolean loc);

where this FileSystem might be disk-based or not,
and FileUtil.toFile could be used to get File's if
desired. Not clear if the capability to find
non-disk-based files is useful anyway; generally
such things are just placed in the system
filesystem to begin with. So unless there are
other arguments in favor, I would prefer the
variant that just gives a File directly. Note that
the impl is free to copy a resource to some /tmp
file and return that, if it needs to.

I would expect autoupdate to supply the default
locator. Since AU manages installed_modules/*.xml,
it is in the best position to understand the
correct logic (I think). But a JNLP-based system,
etc., might store files completely differently, so
a different locator would be needed.
Comment 1 Jesse Glick 2002-11-12 18:03:47 UTC
See also comments in issue #28666.
Comment 2 Jesse Glick 2002-11-12 18:21:28 UTC
Forgot to mention another argument for autoupdate supplying the
default: it could be more accurate than the current situation - thus
solving a bug! so I can mark this a DEFECT! :-)

Say x-1.0.nbm contains:


and x-1.1.nbm contains the same files, but of course newer. Say also
that x-1.0.nbm was installed in the user directory, but then later
x-1.1.nbm was installed in the global directory - so that the module
system quietly upgrades the user to 1.1. Now say that code in x.jar
searches ${netbeans.user} and ${netbeans.home} for "docs/".
It will find the old version!

If autoupdate implements the locator, it has a chance to know that the
active version of x.jar is coming from the x-1.1.nbm which is in
${netbeans.home}, and thus to search only there. (Using the module
code source *would* work correctly though.) This kind of logic cannot
easily be done by the locator client, only the provider. Putting the
locator impl in core might work here, since core also knows where a
module comes from, though it does not install associated files from an
Comment 3 Svata Dedic 2002-11-13 08:10:55 UTC
There's also some code in Java module, which could be replaced by this
feature :-)
Comment 4 Jesse Glick 2002-11-13 22:46:50 UTC
committed   * Up-To-Date  1.9         core/
added       * Up-To-Date  1.1        
committed   * Up-To-Date  1.169      
added       * Up-To-Date  1.1        
committed   * Up-To-Date  1.86        openide/
committed   * Up-To-Date  1.113      
committed   * Up-To-Date  1.48       
committed   * Up-To-Date  1.82       
added       * Up-To-Date  1.1        
Comment 5 Jesse Glick 2002-11-13 22:52:10 UTC
And used too, in some common NB modules:

committed   * Up-To-Date  1.11        core/javahelp/
committed   * Up-To-Date  1.5        
committed   * Up-To-Date  1.4        
committed   * Up-To-Date  1.54        form/
committed   * Up-To-Date  1.75       
committed   * Up-To-Date  1.65        java/
committed   * Up-To-Date  1.17       
committed   * Up-To-Date  1.6        
committed   * Up-To-Date  1.55        javadoc/
committed   * Up-To-Date  1.13       
committed   * Up-To-Date  1.3        
committed   * Up-To-Date  1.33        usersguide/
committed   * Up-To-Date  1.24       
committed   * Up-To-Date  1.46        utilities/
committed   * Up-To-Date  1.5