An ability to accept relative URLs is already available. Just provide
a proper resolver to the mutable fileset. Probably the add() method
should be better documented that it applies the resolver.encode to
incoming references.

I still don't quite get it - is the url resolved when added or when
converted to FileObject or ? Could you please document it well? 

And give specific documentation with code samples for the following
usecase:

I have urls [...,"/home/or141057/src/org/...",...] and want to create
FileSet with urls like [...,"org/...",...] from them.
Then take the fileSet and retrieve the FileObject corresponding to the
urls .

thanks.

Generally a resource (URL) passed to add() is encoded using the
resolver to internal sharable form. It depends on kind of the filesets
what params the add() accepts. Eg instances obtained from
FileSets.createFileObjectSet accept URLs and FileObjects, translate
them to URLs (via URLMapper) if needed and encode them to sharable
URLs. In reverse the fileset's iterator provides decoded URLs
(resolver.decode). In case you need resolved fileobjects you can use
the FileSets.toFileObjectSet helper providing fileobjects translated
from decoded URLs.

Your resolver has to know the prefix (base) to make incoming URLs
relative and vice versa.

Regarding Ondra's use case: why do you care whether URLs inside the
fileset are relative or absolute ? If you want to retrieve FileObjects
at the end, then you should not care whether URLs are relative or
absolute. FileObjects are neither relative nor absolute, FileObjects
are just FileObjects.

Well, I know you want relative URLs, so you can store your fileset in
the Project file, but then, why don't you just use
Project.getResolver() as the resolver ?

Also, you are saying that you put URLs into the filesets, and retrieve
FileObjects. Isn't this asymmetrical ? Why can't you do this
symmetrically, i.e. put in FileObjects and retrieve FileObjects (also,
I don't understand what exactly you mean by this in terms of concrete
API calls).

Looking at the RootedFileSet source - I actually like this approach.
In this approach, the information about the roots is not present to
the fileset itself - it is supplied extrernally. That's how it should be.

I have a couple comments about RootedFileSet, though:

First, the name of the class is not very good - this interface is not
a FileSet at all! But I can't think of a better one.

Secondly, this interface will not work if one root is a subfolder of
another one, e.g. c:\myproject\webmodule and
c:\myproject\webmodule\WEB-INF\classes. In this case, the relative
path of the files in the fileset may be ambiguous.

I think a better approach would be if the RootedFileSet contained a
collection of (root folder, fileset) pairs.

We aggreed at a meeting that the following will be implemented:

- a static method that would for each FileSet return a set of
(FileObject, [String]) pairs. The collection of Strings contains one
relative location for each occurrence of the FileObject in the FileSet. 

- a Look for filesets, that would be usable to show the contents of a
fileset in a tree . This is necessary for effective implementation of
browsers of fileSet contents. Nodes provided by the look must have
some indication of what FileObject AND relative location in the
FileSet they represent 

*** Issue 33897 has been marked as a duplicate of this issue. ***

Regarding the suggested solution: I believe this can work, however we
need to make sure that the information about the root can be supplied
for filesets which simply enumerate its files, i.e. filesets returned
by method FileSets.createFileObjectSet(...). If the solution outlined
above is adopted, then a new variant of this method that also takes
the root folder as a parameter should be provided. That would be
compatible with the spirit of the whole solution.

Could you, please, describe why do you need it? The original idea was
that for enumerated filesets each file is its own root so the relative
path in fileset-entry would be just an empty string.

I don't need this myself, this is more about API purity. 

I can imagine a case when you have some specific classes which you
want to deal with specially, e.g. classes
/src/com/foo/client/HackyClass1.java and
/src/com/foo/server/HackyClass2.java have to be pre-processed before
compiling. In this case, it would be natural if the root of the
fileset which contains these two classes was /src, rather than if
there were two roots /src/com/foo/client and /src/com/foo/server.

As described in
http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the
current work on projects prototype has been stopped.

--> VERIFIED