This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
SourceDescriptor should be registered in lookup of project member returned from getSourcesOwner(). In addition there should be a direct access to SourceDescriptor from CompilationUnit so that I do not need to use lookup. The same applies to JavaDescriptor. I suggest to add: SourceDescriptor getSoucesDescriptor (); JavaDescriptor getJavaDescriptor(); (just a reminder:) JavaDescriptor design is still TDB.
I would suggest to register only JavaDescriptor in the getSourceOwner()'s Lookup - unless you have specific use case for using more generic SourceDescriptor. Java Descriptor offers all of SourceDescriptor + conversion to path-like data. Is JavaDescriptor design TDB (o.n.a.java.project.JavaDescriptor is not the right thing) ?
Yes, I do have a use case for SourceDescriptor. Jarpackager API accepts SourceDescriptor (as well as BuildTargetDescriptor and ResourceDescriptor) for definition of contents. It needs getContents() method so it cannot work directly with ContentDescriptor. So it does not accept JavaDescriptor. I think that it is a valid requirement to ask the Java module to expose its sources via a SourceDescriptor. The specific use case that I am interested in is to package resources in source classpath, like images, property files, etc. which are not represented by Compiled Classes contents.
BTW: if JavaDescriptor provides all functionality of SourceDescirptor then it should extend it, this would solve the problem. AFAIK Tomas was planning to do some other changes in JavaDescriptor so I am not sure if it will be possible.
SourceDescriptor has fixed content type, which cannot be changed by subclasses. When I asked to make it changeable by subclassing in order to have JavaDescriptor extend SourceDescriptor, it was denied. Later it showed up that JavaDescriptor (or some descriptor) is needed to describe classes, sources or just "java stuff", so it is better to have JavaDescriptor _not_ extend SourceDescriptor, IMHO. OK, it would be really ridiculous to have JarPackager depend on java stuff. Since the C.U. == list of sources + output (described by the build target), the methods you suggested only makes that more explicit.
ok. I will describe my requirements that I need the Java module to address. If you have a better idea of -how- to do it, I do not care. I need a SourceDescriptor that describes sources of a given CompilationUnit. I cannot use JavaDescriptor instead because I need to pass this to a module that does not depend on the java module (that is jarpackager). My module does depend on java module and I want to ask jarpackager to package (part of) sources of a specific compilation unit. I would also like to hear opinion of Tomas, since the issue is assigned to him.
Sorry if my last comment seemed as a disagreement -- it was an ACK actually :) What you have written makes a lot of sense, although it establishes a new usage for SourceDescriptor: not only declare individual sources, but also declare groups of sources (although not published in the project-wide ContainersList). I can certainly live with that - and since the grouping is defined by Java project model, java/project module is the place that should implement SourceDescriptor.
Fixed.
i've verified all these issues
closing all my verified issues