Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 104658 - RecognizeInstanceFiles belongs in openide/loaders, not core/startup
RecognizeInstanceFiles belongs in openide/loaders, not core/startup
Product: platform
Classification: Unclassified
Component: Module System
All All
: P2 (vote)
: 6.x
Assigned To: Jaroslav Tulach
Depends on:
Blocks: 98426
  Show dependency treegraph
Reported: 2007-05-23 19:20 UTC by Jesse Glick
Modified: 2008-12-23 08:37 UTC (History)
0 users

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-05-23 19:20:53 UTC
RIF makes heavy use of Datasystems semantics:

1. Folder ordering.

2. Detailed format of .instance files.

Yet these things are defined in openide/loaders. (FolderOrder and
Comment 1 Jesse Glick 2007-05-23 19:23:22 UTC
Complicates issue #103187 because code in the wrong place is interpreting folder
ordering attributes.
Comment 2 Jaroslav Tulach 2007-05-24 16:39:46 UTC
Well, it cannot be in loaders, it would be useless. The goal was to allow 
applications written on top of NetBeans Runtime Container (e.g. without 
openide/loaders) to be able to use Lookups.forPath to read something from 
folders on system file system. This is satisfied.

Re.: "use of Datasystems semantics" - sure. It behaves as simplified 
FolderLookup. Of course that it has to have similar semantics.

I am not sure what exactly you do in issue #103187, maybe we could find a way 
to write the code in different way, share it between multiple usages, etc. 
However the general goal - e.g. ability to interpret SFS as instances without 
openide/loaders - is something I want to keep.
Comment 3 Jesse Glick 2007-05-24 17:32:19 UTC
I guess I don't follow what the purpose of not using openide/loaders is. If you
want the semantics of InstanceDataObject, you should simply use the API module
which provides that semantics. Why not?

For issue #103187 I expect to need a common API in openide/fs which could be
used in RIF.
Comment 4 Jaroslav Tulach 2007-05-25 07:19:03 UTC
Re. "purpose": once upon a time there used to be a discussion. Was it right to 
use openide/loaders for settings management or not? Was not it too heavyweight 
to empower all the loader stuff to just read a menu definition? Well, yes it 
was. The issue 98426 creates an alternative. #1 it is possible to read 
declarative registration with Lookups.forPath, #2 one can use .instance syntax 
on SFS without relying on loaders at all. Of course, the advanced tricks of 
openide/loaders - e.g. .settings files, or InstanceCookie in any kind of 
object, etc. are not supported. But that does not matter from the point of 
view of an extension point provider: "If you want to register something for 
me, put .instance files into X/Y/Z folder on system file system. If you want 
to register something more complex, then depend on core/settings, follow their 
contract and use .settings files, convertors, or your own loaders with 
InstanceCookie. I do not care, I use single common API that can read X/Y/Z for 
Comment 5 Jaroslav Tulach 2007-05-25 07:22:33 UTC
Re. "Single API in RIF" -
#1 it is not very good to create an API just for one client. 
#2 maybe you do not need this API to be public, core/startup and openide/fs 
are loaded by the same classloader anyway or can have impl dependency.
#3 recently you moved layer parsing to openide/fs, maybe the RIF could be 
implemented in openide/fs as well, then there would be no need for an API
Comment 6 Jesse Glick 2007-05-25 16:13:18 UTC
I don't understand how using Lookups.forPath will allow you to read more complex
settings with *.settings etc. FolderLookup would read them, but AFAICT L.fP will

RIF could equally well be in openide/fs; no strong opinion. But the API for
folder ordering I mentioned is needed from other places, not just RIF. See wiki
for the list.
Comment 7 Jaroslav Tulach 2007-05-28 05:52:58 UTC
When core/settings is installed, L.fP reads the SFS content using 
Comment 8 Jesse Glick 2007-06-01 01:22:14 UTC
Ah, I missed that.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo