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.
The module org.netbeans.modules.mercurial declares implementation dependency on org.netbeans.modules.diff and org.netbeans.modules.editor.errorstripe. Since the property AutoUpdate-Show-In-Client also is set to true for the module org.netbeans.modules.mercurial, it is hard to deliver org.netbeans.modules.mercurial bugfixes via AUC whose code changes are in org.netbeans.modules.diff or org.netbeans.modules.editor.errorstripe. It could be "mission impossible" in some cases. Could implementation dependencies be removed (for example through friend packages)?
I am afraid this would not be a trivial task. Should we remove the AutoUpdate-Show-In-Client property then? How do we do that?
Generally there are two possibilities: A) to create a Mercurial kit (in fact an empty NBM with AutoUpdate-Show-In-Client=true) which will depend on org.netbeans.modules.mercurial module with AutoUpdate-Show-In-Client=false. B) to use an existing kit and create dependency on org.netbeans.modules.mercurial module with AutoUpdate-Show-In-Client=false. IMHO mercurial is very specific module so the option B) isn't suitable.
We live happily with these impl dependencise since 5.0, why is there a problem now? Should not the AUC be fixed instead?
In short: No, AUC cannot be fixed. In more details: The process "how updates works with patches" is described in the issue 123694 . If we had to deliver a bugfix for the mercurial module and his cause was in org.netbeans.modules.diff or org.netbeans.modules.editor.errorstripe, we would do following: 1) to increment the implementation version for org.netbeans.modules.diff or org.netbeans.modules.editor.errorstripe (which is nonsense itself. Why we should the change implementation version in case where a "small" change deep inside the module has been made?) 2) to find out all modules those are depend on org.netbeans.modules.diff or org.netbeans.modules.editor.errorstripe via implementation version. 3) to increment spec. version for modules from 2) 4) to find out at least one visible module for every module from 2) 5) to increment spec. version for modules from 4) 6) to change spec. version in dependency between modules from 2) and 4) It is very laborious, it takes too much resources during patch download testing and it leads to delivery of modules those are not changed by a fix. I would ask a different question. What architecture reasons do you have in order that the implementation version have to be preserve?