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.
While it's possible to add build dependencies using the project properties dialog, this is not possible for testing. This is inconsistent i.e. with J2SE projects. Please add use tabs for dependencies in Project Properties/Libraries, so both dependency types can be added at the same place.
Would be more consistent. Not a priority.
1. This is flagged as an enhancement request - is it really necessary to also reduce priority? 2. Seems, that especially for OSGi modules, every NetBeans dependency has to be added manually. I understand, that OSGi modules are not only developped for NB, so if NB doesn't know, what the module is aimed for, it may not add such dependencies automatically. So, as an additional convinience from the dialog, a button should be available to tell NB that the module is intended to be run in Netigso mode.
#2 sounds like it would be a separate issue, but I cannot follow what you are saying at all.
(In reply to comment #3) > #2 sounds like it would be a separate issue, but I cannot follow what you are > saying at all. Please excuse for my English, maybe I'm sometimes thinking in German while writing ... It's both, separate and related. My problem with a new issue is, that the new issue depends on this one (as the switch for automatic testing dependencies wouldn't make sense without the additional dependencies tab), and I don't want to spread bugzilla with dependent low-priority issues, so taking this as a list of ideas, currently. My problem with testing dependencies (probably only for OSGi modules?) is, while running the module is possible, testing isn't because of missing dependencies. I'd guess, this only true for OSGi modules, but haven't tested yet. If so, there should be a switch, so OSGi module project knows it can rely on NB modules. BTW, I've found a dependency on Startup module for jar:file protocol, and Startup seems to need more, so I preferred to workaround this.
(In reply to comment #4) > while running the module is possible, testing isn't because of missing > dependencies. I am not sure what the context for this is. Are you referring to masterfs? If you use FileUtil.toFileObject, you need to make sure masterfs is in the runtime CP. That is not specific to testing; "running" the module in the full app works if and only if this module is included in the app, and similarly when running a non-NB-module-system app including calls to FileUtil.toFileObject you would need to include masterfs in your classpath. In general, depending on what you are doing, various modules may or may not need to be loaded. > I'd guess, this [is] only true for OSGi modules I do not think OSGi has anything to do with this.
(In reply to comment #5) > (In reply to comment #4) > > while running the module is possible, testing isn't because of missing > > dependencies. > > I am not sure what the context for this is. Are you referring to masterfs? If > you use FileUtil.toFileObject, you need to make sure masterfs is in the runtime Sorry, yes, masterfs is the module I've thought about (however, this does not guarentee, that jar:file: protocol can be used). > That is not specific to testing; "running" the module in the full app works > if and only if this module is included in the app, and similarly when running a > non-NB-module-system app including calls to FileUtil.toFileObject you would > need to include masterfs in your classpath. In general, depending on what you > are doing, various modules may or may not need to be loaded. > That's what I wanted to say in second comment, #2: If NB would know, the module will be run internally, it could probably add some dependencies automatically, e.g. to masterfs. > > I'd guess, this [is] only true for OSGi modules > > I do not think OSGi has anything to do with this. Just hought, they are more "external".
(In reply to comment #6) > this does not guarantee, that jar:file: protocol can be used You can use the jar protocol in any Java app, though conversion of such a URL to a FileObject requires a service found in core.startup. > If NB would know, the module > will be run internally, it could probably add some dependencies automatically The IDE cannot know what your code is going to do when it runs and what services you intended to be available.