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.

Bug 147071 - The implementation dependencies removal from org.netbeans.modules.mercurial
Summary: The implementation dependencies removal from org.netbeans.modules.mercurial
Status: NEW
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Ondrej Vrabec
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-12 12:49 UTC by pgebauer
Modified: 2011-10-10 12:11 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pgebauer 2008-09-12 12:49:16 UTC
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)?
Comment 1 Maros Sandor 2008-09-12 12:53:24 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?
Comment 2 pgebauer 2008-09-12 13:45:30 UTC
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.
Comment 3 Maros Sandor 2008-09-12 14:28:46 UTC
We live happily with these impl dependencise since 5.0, why is there a problem now? Should not the AUC be fixed instead?
Comment 4 pgebauer 2008-09-12 15:55:55 UTC
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?