Bug 21036

This will require an API change. Probably support for custom writer. I
suggest to use SAX style methods:

protected void startFolder (String name);
protected void startFile (String name, String url);
protected void writeFile (byte[] ) or char[]?
protected void writeAttribute (String name, String type, String value)
protected void endElement ();

That could be used to format and customize (skip attributes, etc.)
content of XMLFS.

We can either introduce new class or reuse that already present (and
not very useful) XMLFileSystem.Impl. Anyway the class needs to have
those protected methods and also a way how to start the dump.

Is this really necessary?? The DTD is public, anyone can just read the
XML files with SAX themselves and process them however they see fit.
The only aspects of XMLFileSystem which are not trivially copyable
parsing jobs are:

- FileSystem behavior, which is not needed here

- loading of attribute values from custom formats, which is not done here

- merging files and folders; needed here but surely not very
complicated, especially since a client may need custom logic to handle
the originating XML file for a file/folder/attr

I would rather just move the relevant code to core than introduce and
maintain a new (potentially messy) API for this.

Obviously better approach. So guys just remove the code from openide
somehow.

So, this issue is assigend to me. Jesse please if you plan to move
code from XMLFS yourself the reassigne appropriately. If not then let
me know and I`ll do it.

I put it there, I should get rid of it.

Thanks for the patch anyway Petr. :-)

In progress (have apparently working rewrite). As a side effect, split
cache manager into interface + impl: since the impl is no longer
dependent on a hack in XMLFileSystem, it is possible to remove
knowledge of the storage format from ModuleLayeredFileSystem more easily.

If there is time, we can try implementing a binary storage format.
(MDR's btree looks interesting but also rather complicated and
heavyweight - maybe a simple custom binary format with
RandomAccessFile would serve as well.)

Time permitting, I also hope to write a unit test ensuring that the
cache's merged filesystem has the same contents as XMLFileSystem
would, i.e. that it is accurate.

committed   * Up-To-Date  1.20       
core/src/org/netbeans/core/projects/Bundle.properties
committed   * Up-To-Date  1.14       
core/src/org/netbeans/core/projects/ModuleLayeredFileSystem.java
committed   * Up-To-Date  1.27       
core/src/org/netbeans/core/projects/SystemFileSystem.java

added       * Up-To-Date  1.1        
core/src/org/netbeans/core/projects/cache/LayerCacheManager.java
added       * Up-To-Date  1.1        
core/src/org/netbeans/core/projects/cache/ParsingLayerCacheManager.java
added       * Up-To-Date  1.1        
core/src/org/netbeans/core/projects/cache/XMLLayerCacheManagerImpl.java


XMLFileSystem 1.56

The new cache impl. doesn't work for the IDE, because
there are wrong attributes used in the module layers
and the cache manager refuses to create the cache for broken layers
Problems:
e.g. string_V_alue=project

The original XMLMapAttrs implementation was more forgiving
(ignored case) thus it worked before.

Which is why I fixed all module layers in standard-with-apisupport
config to use correct case, before committing the new impl. Did you do
a full CVS update? See issue #15482 for more.

IMHO the XMLFileSystem impl is wrong; the former module layers were
not validatable against the published DTD, and should have been rejected.

Oops, I didn't :(
Thanks.

Cache hack is gone.