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.
It is often a case that when a library X is used in a project you also need other libraries that the lib. X depends on. Typically you compile against the API of lib. X but for runtime (or deployment) you need library Y that provides implemenation of X or library Z that is used by implementation of X. I am filing this issue as a more general solution for problem described in 23820 which is java specific and imposes a solution to -include- the required libraries. It may be more straighforward to only expres dependencies of required libraries.
I (think) I agree. I just want to restate this in a different way to make sure I understand what is being requested. There are (at least) two attributes to a resoruce. 1: The identity of the resource itself. 2: The list of resources that the identified resoruce is dependent upon. I am confused about the description of the interface/implementation dependency relationship. An interface implementation is directly dependent upon the interface definition, not the other way around. I may compile against the interface but there is no easy way I can infer from that compilation dependency that I need an implementation of the interface to run. In all likelyhood the client of the interface and the implementation of the interface use the interface library as a resource in their respective projects. Addressing attribute 2 above, the list of resoruces that a given resource is dependent upon. Is it useful to make the distinction between a direct dependency and an indirect one? I believe both sets of information are useful for different types of processing. Given a choice of only one, I would prefer knowing the full list of resoruces that resoruce X is dependent upon. An API contract about how to answer these questions would be ideal.
more about the interface/implementation issue: It is correct that both client and implementaiton will have compile time dependency on an interface library. My point was that the client will likely also need to have -runtime- dependency on the implementation library, not only the interface. I agree that this may be hard to infer from the code (perhaps a default can be provided to assume that any library used in compilation of interface will likely be needed for execution of any client of the interface). My idea was that the developer of interface library knows that anyone compiling against his API also needs an implemenation for runtime. So the developer of interface is the right person to say that whoever us compiling against MyInterace library should also add MyImplementation library for running. This is more like a hint, the user should be able to ignore this if she has a different implementation of the MyInterface. I am not sure what you mean by direct/indirect dependencies. Can you elaborate on that?
In the dependency tree: A / \ B C / \ D E A Depends on B C D and E A Directly depends on B and C. By directly dependent, I ment the immediate children on the dependency graph. Dependent means all of the children, grand children, great grand children ...., on the dependency graph. I genology terms the distinction it is the same as the distinction between direct decendents and decendents, we are all decendent from Eve but we are not Eve's children. Why is it useful to make this distinction? Lets say I want to package A for deployment. As part of the packaging, I am told that B is already installed at my deployment target. Knowing that D and E are only dependencies of A throug B, I may be able to avoid deploying those libraries. As I indicated, getting the full list is more important than just direct dependencies. All of the use cases I can envision will at some time need to see the full list. The direct dependencies are simply "nice to have". As regards your suggestion about an interface providing hints about its implementations, it still seems like the wrong direction to me. If I am compiling against a pure interface, the actual implementation is probably going to be instantiated via a factory method. Factory methods will nearly always have static linkage to their implementation classes (reflection excepted). An application would not be able to use an instance of one of these interfaces until one was first created, again through the factory class. It all boils down to my inability to imagine a use case where the user would not have to have a linkage to the implementation class anyway. Aiding the user whereever possible is a good thing, my question in this case is wouldn't the user have gotten the help anyway? Do you see a use case that that I did not see?
As described in http://www.netbeans.org/servlets/ReadMsg?msgId=619519&listName=nbdiscuss the current work on projects prototype has been stopped.
--> VERIFIED