Java requires a Descriptor (JavaDescriptor) for ClassPath set up. If
the build target wants to provide classpath entry it needs to provide
it. There is no other way how to do it.
For Resources:
The EnvironmentProvider can supply the default JavaDescriptor for the
jar mime type (*.jar files).
But jar file is nothing java module should take care of. It should be
and I hope it is provided by the JarPackager module.
For BuildTargets:
If the BuildTarget (BT) creates something which should be handled by
ClassPath it must provide JavaDescriptor.
The JarPackager BT has no jar mimetype, the only thing which has mime
type is BTDescriptor, this mime type is for different thing, and other
descritors (e.g. JavaDescriptor). You can add other descriptors with
other mime types, but you will get the same as with JavaDescriptor.
Java module should not automatically add descriptors to any BTs, it
should cause serious troubles.

The intention of the ContentDescriptor mime type methodology was to
allow linking of arbitrary build targets. Build Target A could use
Build Target B if build target B generates classes with a mime type
understood by A. This concept should be generalized onto resources. A
java project jpA could use the output from arbitrary project apB if
apB has a build target which supplies a recognized mime type (either
java classes or jar). Both mime types should be understood by the
project. The java project should allow a resource supplying the mime
type of (java classes or jar) to be used as a resource. What would
happen here is that the resource wizard (supplied by the java module)
would add the JarDescriptor (this should be straightforward for a jar
resource) to the resource created.

This would allow the modules to be decoupled in this area. The java
module could consume arbitrary build targets without requiring the
supplying module to implement the JavaDescriptor. 

JavaDescriptor is a generalized descriptor for "something which
contains java content". There are two forms of it (and two mime
types): one for sources, one for classes. JavaDescriptor is the
associated typed interface for those MIME types.

Your module produces a resource, and you want the resource to be used
by other module. It is very surprising solution to require other
module to implement or work with your interface (JarDescriptor), which
it has no use for (except importing some special module stuff). 

Java module _could_ consume arbitrary build targets (ignoring mimetype
and the associated contentdesc interface), if their ContentDescriptor
type (known to Java module) provides enough information to construct
the java-style resource. It could consume virtually anything, that
provides root folder information. 
However that would allow to import even totally unrelated things as
java resources, since there's no other tagging information available.  

So IF you want to interface with Java module, my recommendation is to
 use Java module's APIs, that is: JavaDescriptor and the two mimetypes
used for it. If you want to declare your module's products as
somethign that is processable by Java, it is far better to use typed
approach than just relying on mimetype's string copy.

If you want to, we could separate JavaDescriptor (a.k.a JarDescriptor)
to a separate Chris API's module so you don't need to depend on java
project APIs formally, but you will depend on them actually at runtime
- in that case I recommend you to talk with your apps' architect
before we do such change.

The mime types of the build target are implied by the
ContentDescriptors, so to add the mime type you have to add a
Descriptor. 
You mean that you will add some "special" descriptor with a "special"
mime type and Java should find it and add the JavaDescriptor with
JavaDescriptor mime type?
This is not probably what we want to support, you will need a
dependency on the "special" Descriptor (the same problem).

Or you may use the standard BuildTargetDescriptor, in this case it
will be even worse. BuildTargetDescriptor (BTD) is very generic and
has nothing in common with Java. The BTD exists for all BTs (producing
for example C++ classes).

Here is how I see this working:

A build target that would that can produce jar files would add an
instance of ContentDescriptor with "application/java-archive" passed
into the constructor. Since this mime type is commonly used, then one
would expect that the consumer (java module) would known how to create
a JavaDescriptorResource around these targets [reasonably expect that
BTD.getContents would return jar files].

This should be the same model used for browser plug-ins which register
to handle certain mime types. The supplying server does not have to
implement a special interface for each browser (instead the get
command is used by the consumer and the mime type is  used to decide
how/if the resource can be handled).

To be clear - is your request to react on a specific string and try to
interpret the ContentDescriptor using either ContentDescriptor or
BuildTargetDescrioptor generic interfaces and inject an additional
JavaDescriptor into a ProjectMember that provides such ContentType ?

In that case, the string would have to be declared in java APIs as a
manifested constant and you should use such constant in your BT. 

And in that case, I would prefer to provide a factory method for
creating a JavaDescriptor implementation around a given BTD instance
(for example), so you can easily add it to your BTD's Lookup, rather
than create a dummy mimetype/content descriptor that just serves as a tag.

BTW without further information (additional to those found in generic
BTDescriptor), it would be very tricky to create a JavaDescriptor for
the output: the BTD reports output folder - but what files in that
folder should be used as a resource ? 
Suppose the JAR BT will generate jar to a common jar output folder --
so which files in that folder will be "the" resource ? It would be
even worse if the output folder is shared w/ other types of build targets.

The mime string seems like it is generic (well known and won't
change), so I am not sure why a module would need to know about the
java API's just to get this string. 

The build target descriptor getContent returns a FileSet, where in the
case of a build target providing the jar content descriptor one would
just use the jar files described in this api. I am not sure why the
output folder would make a difference here.

Hmm. You still failed to explain the reason why you don't want to use
Java API declaration while you depend on Java API semantics (that
something like such mime type exists and is known to other module(s)).
It seems like depending on a menu position in your application - it is
documented on screenshots and probably won't change. 

Modules which claim to produce or process java content should declare
dependency on and use the common java infrastructure; otherwise we may
happily fall down to a lowest common denominator: java.lang.String,
java.lang.Object and reflection.

You may want a _bridge_ mini-module that would activate when
JarPackager & Java are both loaded, can use both their APIs to convert
stuff back and forth and connect these two together - that's perfectly
fine. 

It seems even more funny because I supposed JarPackager (or a part of
it) will/should contain support for things like Manifest - and it IS
quite java-specific, isnt' it ? So will you avoid using java project
APIs even for that implementation ?

Also you failed to explain why introducing an unnecessary intermediate
is preferrable to implement a well-known Descriptor (with possible
support class that makes the task easier).

I don't think that the java semantics are a requirement for publishing
a build target which creates jars. I only need to specify that my
build target creates jar files and the modules which can use a jar
file (java is only one instance of this) as a resource will take the
appropriate action. What would happen if another module which can use
jar files was introduced? I don't think it would be reasonable to
expect all modules which provide build targets to add another custom
descriptor. This would require the service to know about the client
and would not scale well (introduction of a module like this would
require that each client have a dependency on this module and add an
additional descriptor). 

Svato and Tomasi, I think that you are missing several important
points here. It seems like this is saidly very hard to imagine for you
but I think this is the case this time.

1. JarPackager should not, and in fact cannot correctly add a java
descriptor automatically to every jar build target. Take an example of
web module archive (WAR) which is a JAR file but it does not put java
classes into the root of archive. Jarpackager of course constructs its
java descriptor to be rooted in root of jar. It is a task for java
module to deside that certain jar file should be added to classpath
and to implement this. The same applies to remote resources: it is
again task for java module to let you add a jar build target as a java
remote resource and provide the java descritor for that jar.

2. It is a missconception to make the jarpackager module depend on the
java module. A folder can also be used as a root of classpath and that
does not mean that DataFolder needs to depend on java module APIs ;-)
Java module simply 'tags' some folders as classpath roots.

Actually I was fine with a solution that Java module allows to
transform any reasonable content (whose ContentDescriptor provides
enough information) to a JavaDescriptor; I was objecting against
introducing marker YetAnotherContentType - in that case, if that
marker meant "there are java classes inside", JavaDescriptor should be
used.
See my comment from 29/8/2003, the third paragraph. For some special
cases, bridge modules could be useful to provide _automatic_ transform .

No objections against taking _generic_ stuff and convert it into a
proper JavaResource (e.g. in a Wizard, if the contentdescriptor is not
informational enough).

Hi Pavel,
I agree that JarPackager does not and should not understand to the WAR
at all. But the same holds for Java module. Web module should add the
JavaDescriptor.

The JarPackage should depend only on the Java module API contract, if
it has dependency on the Java module fill issue on it.

Java module should NOT add to the classpath ANY build target which is
not regulary marked as CP Entry (implemented by JavaDescriptor).
The fact that BT produces Jar does NOT imply that it wants to be a
part of CP (e.g. BT produces a midlet Jar which is input of the other
BT which signs it and the signed jar should be on CP, not the original
one).

Tomasi,
I filed http://www.netbeans.org/issues/show_bug.cgi?id=35884 for
jarpackager. This is probably misscommunication between java and
jarpackager modules, since Obdrej claims that he must add
JavaDescriptor because of deficiency in project apis (that means in
java apis, i guess).

I think I did not make myself clear: the Jarpackager should not depend
on Java APIs. It currently uses it for two reasons: RootedFileSet and
JavaDescriptor. Both of them are poor design.

To your third comment:
I think that you convinced me that java module should not
-automatically- mark any jar files as classpath roots. On the other
hand it must be possible to create a java remote resource referencing
a build target that is does not provide classpath entry. Take a
handful of examples:
- BT1 produces classes, BT2 copies the classes produced by BT1, BT2 is
a generic "copy" target that does not provide classpath descriptor. It
is still valid requirement to create remote resource pointing to BT2.
- Jarpackager
- Ant script which produced classes
- A build target that produces resources, e.g. images, .properties
files, etc. - you may want to add it to runtime classpath as a remote
resource.

If you want to provide ClassPath resource, it is quite natural that
you depends on the ClassPath API.

Java should not introspect foreign BuildTargets to find out if they
are producing something that Java modules may understand to. This is
potential source of troubles (the resources e.g. ZIP/JAR can require
special care, which is unknown to Java module, e.g. offset of source
root, but known to provider)
Other problem is that the build target can be not compiled and it has
no output at all.

This can be written as a special UI, which allows user to add
arbitrary BT as Java resource, however Java module will not be
responsible for correctness of such a resource.

If someone wants such a functionality, please fill a task.

I said I gave up on the automatic introspection part. I filed a
separate issue for making it possible to connect remote resource for
arbitraty build target
(http://www.netbeans.org/issues/show_bug.cgi?id=35898).

I suppose that Java module will be responsible for this resource just
like it is responsible for a resource created for external files or
jar. Or can you explain the difference, please?

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