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.
Summary: | The implementation dependencies removal from org.netbeans.modules.mercurial | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | pgebauer <pgebauer> |
Component: | Mercurial | Assignee: | Ondrej Vrabec <ovrabec> |
Status: | NEW --- | ||
Severity: | blocker | CC: | jtulach, sustaining |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: |
Description
pgebauer
2008-09-12 12:49:16 UTC
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? |