Hi Chris,
I do not fully understand to this issue. Do you mean to return a
special mimetype for the JavaBuildTarget. It would be easy to find the
ContentDescriptor producing java classes, but it would be impossible
for a generic tool to find all ContentDescriptors which provide
output, because the JavaBuildTarget would have another mimetype.

I am suggesting that in addition to the BuildTargetDescriptor required
by the build infrastructure, the JavaBuildTarget will supply an
additional ContentDescriptor for the application/x-java-class mime
type. This will allow more specialize filtering of build targets which
produce java classes. 

I wonder why java API (org.netbeans.api.java.project) classes can not
be used. There's already a way how to enumerate all "javac" build
targets in a project.

There is no need for the additional mime type for java classes, since
Java module provides API for this.

Collection c = JavaProject.getJavaProject
(projectMember).getCompilationUnits();
for (Iterator it = c.iterator(); it.hasNext();)
    ((CompilationUnit)it.next()).getBuildTarget();

Using the java module api is fine if the accessing module already has
a module dependency on the java module. However, this does not
necessarily have to be the case. Providing an additional content
descriptor would allow queries for build targets which produce java
classes, not just access the build targets provided in a java project.
If you make the assumption that all access to java build targets will
be through a java project (and thus a module dependency) then this is
ok. I did not make this assumption when I requested this change. 

An additional content type marking "produced .class files" will be
implemented on Javac build targets, obeying the generic
ContentDescriptor contract.
As pointed out, Java support already provides richer interface to its
clients through a dedicated API. If you require an API richer than
ContentDescriptor, but still independent of Java module, you probably
want to file the request for project infrastructure or implement it
some other way.

Note that by copying the content type text and obeying the defined
contract (getContents() gives out set of .class files), the module
does not - formally - depend on java module APIs. But in fact it does,
since it uses (or implements) contract defined by java module.
Dependency on a symbol or a packaged code is relatively unimportant
detail. So the request "not to have dependency on java apis" seems
little strange.

I am not sure I agree that the ability to query for objects producing
a standard mime type (for which class file has a well known mime type)
would necessarily introduce a dependency on the java module.
Specifically what should be avoided is exclusion of another build
target producing class files (possibly another compiler such as a byte
code instrumentation compiler which can be used for code coverage
metrics). These externally introduced targets must be able to function
as the target supplied by the java nature. This is one of the reasons
why 31104 is important, so that other targets (not provided by the
java module can still be packaged correctly).

What is the standard content type for a set of .class files (as
opposed to a content type for a single .class file) and what is the
ContentDescriptor subclass bound to it ? Where are these two defined -
if they are standard ?

Suppose java module APIs will define this content type and associates
a ContentDescriptor subclass to it (though it will not bind it to any
project/comp.unit./other class). If your code uses the content type
and assumes that the specified ContentDescriptor subtype will be
returned, then you depend on a contract defined by java module. If you
do not declare such dependency cleanly, then you are just producing
messy code.

The same holds for implementors of such contract. Because you want
your code to work with them, they (not you) will be obliged to
implement an additional contract (provide the additional
ContentDescriptor) and make themselves dependent on java module APIs.

According to "Issue Type" description, I changed the issue type to
"FEATURE" (a feature that is missing, but is needed). Feel free to add
dependencies.

I have seen the following MIME types specify java class files: 
                                            application/java
                                            application/java-byte-code
                                            application/x-java-class
Consult your favorite MIME repository to determine which are the most
common. Since this is requested for a java ide this content descriptor
may be standardized, to be reused by other producers of class files. 
I don't see the need to distinguish the cardinality of the class file
set. 

My expected use of the this descriptor would be as follows:
Derive the set of interesting descriptors by filtering first on class
file producers (this would generally be overridden by the user in the
case of class to class file transformations) and then use the build
target descriptor to extract the actual files. Of course if getContent
were commonly available to all descriptors the second filtering would
be unnecessary. This could be done with adding a dependency on the
java module (there would likely be a dependency on the java project
nature).

I browsed briefly through IANA MIME directory but couldn't find the
types you mentioned. Maybe we should stick with the x- prefix then.
application/x-java-class is a good shoot, thanks.

Still, you may have problems with BTD.getContent(), since FileSet does
not give you the root folder, just the contained files.

In the meantime I have created a dedicated JavaDescriptor, which can
have a content type for sources or classes and defines getContent()
method itself in a way that can give you the root folder. Javac build
target is recoded to provide an implementation, which filters only
.class files as the content (to cover the case that classes are put
among the sources).
JavaDescriptor is a ContentDescriptor subclass acting independently of
JavaProject/CompilationUnits structure.

The exact algorithm you have written below should be possible after
the change is merged.

Expect merge of the code within a week.

Done; see o.n.a.java.project.JavaDescriptor; content types are 
declared as o.n.a.java.project.JavaProject.MIME_*. 
 
Currently the _CLASSES content is served from javac build target, it 
will be served from external resource items (jars) as well so that all 
items that provide class files can be searched for. If you are interested 
only in build targets, just search for both MIME_PROJECT_OUTPUT & 
MIME_JAVA_CLASSES. 
 

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

Marking issue as VERIFIED --->

---> CLOSED