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.
An ant target that would go through all the dependencies of a module, and for each update its version to the latest version available (i.e. currently, this can be done manually, by removing the dependency and adding it back again). The target should be also available in the suite's build - it would update dependencies of all the modules in the suite. Note that this is simpler than #73741: it should not look for missing dependencies nor remove unused dependencies, but simply update the version numbers of existing declared dependencies. (see also the discussion at http://forums.netbeans.org/viewtopic.php?t=42045)
Bug #70917 is probably what you are asking for, though I do not follow from the forum discussion why you think you need to be constantly updating dependencies among modules anyway: a dependency should express the *minimum* version of the other module which is needed, so you would only adjust the dependency version when you began using a new API from that module. The Ant-based project type offers no assistance in making that change, but then again it also offers no assistance in ensuring that any dependencies are correct, since it has no notion of history. If you want advanced dependency management and build-time enforcement of API compatibility, use Maven. *** This bug has been marked as a duplicate of bug 70917 ***
Consider the following scenario... Module1 to ModuleX (where X can be quite large in some projects) depend on utility module ModUtil version 1.1.30. A bug is fixed in ModUtil and the version is increased to 1.1.31. Module1 to ModuleX will still work with ModUtil version 1.1.30; no API changes were made. But as a developer, you know that there is a better functioning version of ModUtil available. It seems obvious (at least to me, and apparently to others) that you would want future deployments of Module1 to ModuleX to depend on the fixed or best version of ModUtil, and not the version with the bug. Why would you wish to permit future releases to have continued dependency on something that you know doesn't work correctly? Many times, the present set of modules contain the latest fixes, and it is desireable to update the dependencies of all modules to use the present set of modules. As discussed above, this is presently a manual process, and can be quite tedious for a large number of modules. This is why the ant target described above would be very useful.
(In reply to comment #2) > Module1 to ModuleX will still work with ModUtil version 1.1.30; no API changes > were made. Then they should still declare ModUtil > 1.1.30. > you know that there is a better functioning version of ModUtil available. That is fine, and if the user is still running 1.1.30, they should see 1.1.31 offered as an update in Plugin Manager, so they will get the bugfix. A dependency version is the _minimum possible_ version that you could possibly run against, not the _recommended_ version.
(In reply to comment #3) > A dependency version is the _minimum possible_ version that you could possibly > run against, not the _recommended_ version. There are situations where a running against an older, buggy module may be nothing more than a minor inconvenience for the end user. Unforunately, that is not the case for many/most of the bug fixes I deal with. This is because the bug is causing misinformation to be given to the end user, which could possibly lead to monetary liability. Thus, we have to update depenencies after such bug fixes. The "_minimum possible_ version that you could possibly run against" is defined by practically consideration to be the latest version known to be bug free. While technically possible to run against an older buggy version, it is not pragmiatic or wise to do so.
Then deliver your app over JNLP so you know that every user who is running the app online has the recommended versions of all modules, or otherwise manage module installations. Dependency declarations are not intended to track and control what is being run; they merely state what API versions are needed to avoid Java linkage errors and the like. Consider a module that no other module depends on - you still want to ensure that a user is running the most recent stable version.