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.
In NB 3.4, the java module provided the ability to register library which would appear in the classpath. The jar was resolved relative to the netbeans installation directory. IN the projects branch, there is a need to perform this same registration via a nature. The current definition requires that a url be supplied. It would be extremely useful to support the ability to register java resources via a nature (using a path relative to the module or nb installation directory). In addition, resources which have been registered this way should allow them to be invisible to the user. This would allow the user to then only see the resources explicitly registered.
Re. invisibility -- I don't know whether it is a good idea; in 3.4, it was useful because it limited the number of FileSystems. In 4.0 it will contribute Resources node (which will be collapsed most of the time) but will not affect the main work area (Sources subtree). Since "Resources" were meant to show any external dependencies to the user, it seems more reasonable to put everything in there. If you need to add a bunch of JARs, you can bundle it as a library (see issue #23798) and add to the user block as one entity avoiding pollution.
The context in which this usage is envisioned is for J2EE component development. The resources that would be added via the nature are libraries which are required to be available on the J2EE application server and thus the user just expects these libraries to be available. If this resource was not visible to the user, the user would not be confused about libraries which are required to be part of the J2EE specification and those which are application driven. Will relative resolution (such as provided in NB 3.4 for library archives) be provided?
Yes, inclusion using the layer probably has to be supported (I already set the target milestone). The hiding problem is not with not showing the resource in Resources node, but with other places in the UI that manipulates with resources - e.g. various classpath customizers.
I expect that ContentDescriptor instances which return null for the getVisualObject method would be handled appropriately in the infrastructure provided customizers. One concern if these nature provided libraries are visible would be what happens if a user tries to delete the library?
ContentDescriptor is not a panacea - it is a low-level communication layer. If any code manipulates/displays with ClassPath, it should use dedicated APIs, not ContentDescriptors. There is a number of issues with invisible but present data - at the end the environment for building and running is different from what the user can see. This request impacts all clients of ClassPath API, since they all will have to check whether to display something (and how) or not. This is a "really good" solution: impact all others because of special feature of one. If you *must* have it, I think can be done - although it will mess presentation layer into pure data API. Note that we will not solve problems introduced by this design. re. deleting: If the user can re-add the library, where's the problem ? One reminder: this is not a primary API - but rather a support built on top of APIs. Java module is able to introduce its own classpath items even without this feature in its template/nature.
We are trying to achieve the sense of a J2EE platform. The J2EE platform requires that specific libraries which are above and beyond what is available in the SDK. In fact the J2EE spec also specifies minimum SDK requirements. One who develops for this platform expects that certain libraries will be available during compilation. In the case of a J2EE based project the intent is to provide these in the design time classpath. I am not attempting to dictate a design but I would like the ability to provide the ability to provide design time classpath, code completion, and javadocs from my nature. I don't think it makes sense for a user to remove the ability to compile against ejb api jar files for an ejb module project (this violates the premise of the nature).
So - it seems that you need not only some specific jars, but also a specific placement of them, right ? Should these jars be part of the "bootclasspath" (talking in application runtime's terms) or regular application classpath ? If I make a little abstraction, the intention is to add some resources (depending on a constraint external to plain java support, like what EJB spec is used etc) and have them distributed at all places where "regular" resources would be passed - except the standard classpath configuration UI, since that configuration item is specified elsewhere (e.g. by creating an EJB project or adding the EJB nature). Is that correct ?
No response. I will try to sketch some design on java.netbeans.org based on the info supplied so far; hope it will be sufficient. Currently I have some ideas, each with its own bonuses and drawbacks, which may or may not solve the "hiding" problem, depending on what the exact and full set of requirements is.
AFAIK the J2EE spec does not constrain the placement of the jar files, although in practice I suspect that most application servers will order the additional api's before the users classes. Distribution of the J2EE library resources in netbeans projects could be done using a specific versioned nature (J2EE 1.3 J2EE 1.4) which would supply the resources. I was envisioning something along these lines as this would be associated with the project and available when resources are available but not modifiable as once a J2EE artifact is created the contracted jars are required for compilation (EJB). I agree with your abstraction.
This issue is no more valid in promo-D.