Intercluster implementation dependencies have to
be prohibited, so please remove those on db modules.
Cannot be solved in 4.1 because db module has no public API.
Although it is used only in enterprise cluster the assumption is that
some modules in ide cluster will want to use it in future so we do not
want to move db modules into enterprise cluster (although that would
solve the immediate problem).
I will ask for 4.1 waiver as soon as 4.0_WAIVER_REQUEST keyword is
In promo-F we have to figure out how to solve this. We can publish the
de facto db API as it is now if we do not plan to do any major work on
it. If we do (and we probably should) we will provide a replacement
for the current private API.
DevRev agreed this can be downgraded to P2.
Partially improved by moving the db/model (dbschema) module to
enterprise1 cluster. This does not remove any implementation
dependencies, but it eliminated a cross-cluster implementation
dependency on dbschema.
Waiver for NetBeans 4.1 approved.
Andrei is working on new db explorer API, that will solve the db module.
The dbschema will be solved by creating a friend API that will be used only
within enterprise cluster (see also issue 54471).
The friend API for dbschema was integrated into the trunk yesterday.
Well, I would say this is still not completely fixed, because there is an
implementation dependency of dbschema on db, which can not be eliminated by the
use of the new evolving API in db. This dependency also goes across clusters
(enterprise2 to ide6). Still, the major part of this was fixed, so reopening
with P3 priority.
This last subitem depends on the ability to have both public (evolving) and
friend API in one module, discussed as a part of issue 54123.
If the impl dep is between "really close" modules, then it is relatively
ok. I mean - it is not excelent, but we know no better right now. No need to
keep an open issue for that until we found what problems it causes.
 close modules must be in the same cluster, should be developed by the same
guys, always build together, the bridge should the thin and externally
db and dbschema don't match Yarda's definition of "really close" (they are not
in the same cluster). The impl dep is mainly caused by the usage of libddl part
of the db module in order to retrieve the database structure. Another way to
remove it (apart from the one Petr mentions) could be to make use of the new
database model (as soon as it's ready) instead of libddl.
TM 5.0 -> TBD
Not doable for 5.5 I think.
Not for 6.0 either.
We are working on a new metadata model, but currently it's read-only. Perhaps it can be used to replace libddl in the
next release, let's give it a shot.
Reassigned to new owner.