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.
cnd/core/nbproject/project.xml lists quite a few public packages, which by casual inspection are clearly not intended as APIs and would not be accepted as such. Please consider which Java classes you actually need to expose to other modules in the cnd cluster, and list those as friend packages to the appropriate list of friend modules. Of course if you want to develop an official API in the future, that would be fine too, but this should be a quick change.
OK, here is what I can do: Remove those packages from the public list that neither CND, ATD, or SS are using. I will not rename or move any APIs. I build entire SS each Friday so I can make sure everything still builds and runs. Gordon pointed out that the Fortran project in St. Petersburg also uses APIs from core but I have no way of knowing which ones. I will make a best guess and we can add them back if we break their build. Are there any other know 'outside' projects using CND?
you can checkout fortran module cnd/fortran from branch cnd6_fortran, then open fortran project in IDE and I think any find usages of core classes will point to Fortran as well
I managed to get rid of (only) 4 packages: - <package>org.netbeans.modules.cnd.api.project</package> - <package>org.netbeans.modules.cnd.execution41.org.openide.actions</package> - <package>org.netbeans.modules.cnd.execution41.org.openide.execution</package> - <package>org.netbeans.modules.cnd.makewizard</package> Searching source for packages is not enough. If a class is used from a particular package and the code references a method in a subclass, the subclass also need to be in a public package but the include don't necessarily reflect this. Clearly, we need to clean up the APIs in CND (we have know this for a long time), but it is unfortunately not in our 6.0 plans. I will consider this issue fixed.
You need to use <friend-packages> and enumerate those modules you wish to actually use these packages. It should only take a few minutes if you know who uses them (and you definitely need to know this!).
Why is that important? Is it a performance issue? We would rather not do this (especially not weeks before freeze) because we are not sure we know all CND's users. And why should we?
We are aware of several research projects involving CND which are not managed by us. I don't think we can make this change now. I totally agree that CND's APIs should be cleaned up and only true public APIs should be exposed but it is a long standing issue we just haven't gotten to yet.
It is an architecture issue, not a performance issue. (I just noticed that this was not fixed properly while checking behavior of some new build logic which determines whether a module has public packages or out-of-cluster friends.) I am not asking to change the set of packages exported or their contents for 6.0. Just to list the modules which will consume these classes. Certainly you know which such modules are in the standard NB build, or in nb.org sources generally. If there are external projects (outside nb.org) which are using cnd's classes, you absolutely need to know about them - otherwise it would be impossible to determine whether incompatible changes you make to public classes would break one of the downstream modules. So find out who they are, get their code name bases, and list them as friends.
I may not be that easy to find out. How do you ask someone when you don't know who they are? I have advocated for a long time that our APIs should be cleaned up but it has never happened and here we are few weeks before freeze. I don't think we can do what you ask now. I will bring the issue up at our next iteam meeting and hear what project management thinks.
Reassigning to Vladimir V. We will consider doing this for 6.0. It is the right thing to do but may be too late to do safely.
How do you make any changes to classes in cnd at all if you don't know who might be depending on them and how? As just the most recent example, yesterday the public classes org.netbeans.modules.cnd.editor.spi.cplusplus.CppSwitchActionProvider org.netbeans.modules.cnd.editor.spi.cplusplus.GotoDeclarationProvider were deleted. So anyone who happened to be using them without your knowledge would now be in trouble. This was not the only incompatible change in the past week, either. If you simply switch to friend packages and enumerate all known friends, you will find out who depends on your classes - they will not be able to build or run their modules until you add them, at which point they will need to contact you and you will know who they are. Ultimately up to you. Came to my attention mainly because we are tracking signature changes on api-changes@netbeans.org and we plan to limit distribution of mail relating to intra-cluster friend packages to cvs@*.netbeans.org mailing lists, reserving the general alias for changes in public packages and inter-cluster or external friend packages.
I don't think we disagree - we should just have done it earlier. Anyway, the team just agreed to go ahead and do it for 6.0 and take the risk. Vladimir V. will probably make the change tomorrow.
fixed: - provide non-stable APIs only to listed friend modules cvs log: Checking in modelapi/nbproject/project.xml; /shared/data/ccvs/repository/cnd/modelapi/nbproject/project.xml,v <-- project.xml new revision: 1.5; previous revision: 1.4 done Checking in antlr/nbproject/project.xml; /shared/data/ccvs/repository/cnd/antlr/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in completion/nbproject/project.xml; /shared/data/ccvs/repository/cnd/completion/nbproject/project.xml,v <-- project.xml new revision: 1.13; previous revision: 1.12 done Checking in makeproject/nbproject/project.xml; /shared/data/ccvs/repository/cnd/makeproject/nbproject/project.xml,v <-- project.xml new revision: 1.17; previous revision: 1.16 done Checking in modelui/nbproject/project.xml; /shared/data/ccvs/repository/cnd/modelui/nbproject/project.xml,v <-- project.xml new revision: 1.8; previous revision: 1.7 done Checking in repositoryapi/nbproject/project.xml; /shared/data/ccvs/repository/cnd/repositoryapi/nbproject/project.xml,v <-- project.xml new revision: 1.4; previous revision: 1.3 done Checking in highlight/nbproject/project.xml; /shared/data/ccvs/repository/cnd/highlight/nbproject/project.xml,v <-- project.xml new revision: 1.16; previous revision: 1.15 done Checking in modelutil/nbproject/project.xml; /shared/data/ccvs/repository/cnd/modelutil/nbproject/project.xml,v <-- project.xml new revision: 1.14; previous revision: 1.13 done Checking in apt/nbproject/project.xml; /shared/data/ccvs/repository/cnd/apt/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in modelimpl/nbproject/project.xml; /shared/data/ccvs/repository/cnd/modelimpl/nbproject/project.xml,v <-- project.xml new revision: 1.20; previous revision: 1.19 done Checking in refactoring/nbproject/project.xml; /shared/data/ccvs/repository/cnd/refactoring/nbproject/project.xml,v <-- project.xml new revision: 1.14; previous revision: 1.13 done Checking in modelservices/nbproject/project.xml; /shared/data/ccvs/repository/cnd/modelservices/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in dwarfdump/nbproject/project.xml; /shared/data/ccvs/repository/cnd/dwarfdump/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in core/nbproject/project.xml; /shared/data/ccvs/repository/cnd/core/nbproject/project.xml,v <-- project.xml new revision: 1.17; previous revision: 1.16 done Checking in projectbridge/nbproject/project.xml; /shared/data/ccvs/repository/cnd/projectbridge/nbproject/project.xml,v <-- project.xml new revision: 1.2; previous revision: 1.1 done Checking in discovery/nbproject/project.xml; /shared/data/ccvs/repository/cnd/discovery/nbproject/project.xml,v <-- project.xml new revision: 1.7; previous revision: 1.6 done Checking in dwarfdiscovery/nbproject/project.xml; /shared/data/ccvs/repository/cnd/dwarfdiscovery/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in syntaxerr/nbproject/project.xml; /shared/data/ccvs/repository/cnd/syntaxerr/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done
verified