Once again from the README.cnd we have: > To build the C/C++ support, please copy the following files from the > original NetBeans repository to your clone: > * cnd.debugger.common2/src/org/netbeans/modules/cnd/debugger/common2/icons/debugger_log.png > => cnd/cnd.debugger.common2/src/org/netbeans/modules/cnd/debugger/common2/icons/debugger_log.png So for these icons can some new ones get created to replace these? Since there were recent svg and redone icons introduce a little while back...maybe some similar would would be needed anyway. > * cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/CPPParserEx.java > => cnd/cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/CPPParserEx.java > > * cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/CPPSymbol.java > => cnd/cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/CPPSymbol.java > > * cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/cppparser.g > => cnd/cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/cppparser.g This seems parser and grammer oriented. > * cnd.repository/src/org/netbeans/modules/cnd/repository/storage/data/UTF.java > => cnd/cnd.repository/src/org/netbeans/modules/cnd/repository/storage/data/UTF.java > > * cnd.repository/src/org/netbeans/modules/cnd/repository/util/LongHashMap.java > => cnd/cnd.repository/src/org/netbeans/modules/cnd/repository/util/LongHashMap.java > * cnd.utils/src/org/netbeans/modules/cnd/utils/resources/mime-resolver-hex-based.xml > => cnd/cnd.utils/src/org/netbeans/modules/cnd/utils/resources/mime-resolver-hex-based.xml These seem data type oriented. > * cnd.testrunner/src/org/netbeans/modules/cnd/testrunner/ui/CndUnitHandlerFactory.java > => cnd/cnd.testrunner/src/org/netbeans/modules/cnd/testrunner/ui/CndUnitHandlerFactory.java Seems unit test oriented. > * mercurial.remote/src/org/netbeans/modules/mercurial/remote/ui/update/ResolveConflictsExecutor.java > => dlight/mercurial.remote/src/org/netbeans/modules/mercurial/remote/ui/update/ResolveConflictsExecutor.java > > * remotefs.versioning.api/src/org/netbeans/modules/remotefs/versioning/api/Scrambler.java > => dlight/remotefs.versioning.api/src/org/netbeans/modules/remotefs/versioning/api/Scrambler.java > > * subversion.remote/src/org/netbeans/modules/subversion/remote/ui/update/ResolveConflictsExecutor.java > => dlight/subversion.remote/src/org/netbeans/modules/subversion/remote/ui/update/ResolveConflictsExecutor.java These seem remote access / remote file systems for select revision control software is an issue > Download the following files into the specified folders: > * https://netbeans.osuosl.org/binaries/47F0DB803884692F28A26A2FF80A7D6756B091DB-cnd-build-trace-1.0.zip > => cnd/cnd.discovery/external/cnd-build-trace-1.0.zip > > * https://netbeans.osuosl.org/binaries/E59851B0E49C05D728D5C653E52750FA5B6A8F0E-cnd-rfs-1.0.zip > => cnd/cnd.remote/external/cnd-rfs-1.0.zip > > * https://netbeans.osuosl.org/binaries/5CAB59D859CAA6598E28131D30DD2E89806DB57F-antlr-3.4.jar > => cnd/cnd.modelimpl/external/antlr-3.4.jar While trying to build recently, I did noticed some other artifacts where downloaded. I assume something similar is possible here as well? Or is changing them to use true dependencies (i.e. pull from say maven repository) better to do here?
> From NetBeans 8.2 binary, copy file: > * cnd/modules/org-netbeans-modules-cnd-antlr.jar => cnd/libs.antlr.cnd/external So based on some of the above, it seems like: (1) antlr related files dependencies are an issue Is replacing this more likely or is there a chance of them getting opened/relicensed? That said, there do seem to be newer antlr versions available...maybe it's time to update this (see https://www.antlr.org/download.html or https://github.com/antlr/antlr4). Or was this the place where the "language server" option could come in to play as well? Or should the classes be replaced with stub classes with empty stub methods for these and then reimplement them as it's worked? (2) Some of the remote access / remote file systems for select revision control software is an issue Not sure why any of this is specific to C/C++ functionality directly. Shouldn't remote access/file systems be addressed by other modules? Is it as simple as replacing calls to this to use the other existing interfaces wherever the methods are used? (3) Some debug related items are an issue I seem to recall a thread sometime back about debugging/profiling which was Oracle specific so maybe alternatives if not available needed here. Can any of the recent cpplite be reused here to fill any of these gaps? Eric Bresie [email protected] On Sun, Jul 26, 2020 at 2:33 PM Jan Lahoda <[email protected]> wrote: > On Sun, Jul 26, 2020 at 9:21 PM Eric Bresie <[email protected]> wrote: > > > <[email protected]> > > > > > > On Sun, Jul 26, 2020 at 1:27 PM Brad Walker <[email protected]> wrote: > > > > > On Sun, Jul 26, 2020 at 9:57 AM Eric Bresie <[email protected]> wrote: > > > > > > > Okay so from the README.cnd I see: > > > > > > > > > There are many caveats currently, a possibly incomplete list: > > > > > > > > > > > >* building requires a number of files from the original repository - > > > work > > > > by >NetBeans C/C++ enthusiasts is needed to resolve this in one way > or > > > > another > > > > > > > > Is there a reason these files are not included? > > > > > > > > Is it as simple as pull these (maybe update licenses), and check them > > in > > > to > > > > the new cnd branch? > > > > > > > > > > From my perspective, I'm unsure at this point.. We will need to look > into > > > this.. > > > > There is a reason why these files were not included. These were not part of > the donation, and hence cannot be relicensed to Apache. We may be able to > use some of them, under some conditions - see > https://apache.org/legal/resolved.html Category B and Category X. E.g. I > suspect using the icons under CDDL may be possible by putting the icons > into the repository and marking them properly. For the other files, that is > harder to say, and probably some investigation must be done to determine if > a replacement is needed or not, and what the replacement should be. The > reason for not including those files is to make it clear these are open > questions (as opposed to just having a list somewhere, which could be > missed). > > > > > > > > > > >* building requires a number of binaries to be added manually > > > > > > > > Would changing any build files (ant/maven?) to pull these directly > from > > > > applicable repositories instead of having to copy these resolve this? > > > > > > > > For example, I see reference to an antlr jar being needed. Could > > > reference > > > > to dependency to this which then gets pulled during prep for > building? > > > > > > > > > > Same as above.. But, I started giving this some thought as Antonio did > > > mention this.. > > > > > > >* external libraries/dependencies need to be reviewed and put up to > > Apache > > > > standard > > > > > > > > What is meant by “Apache standard”? > > > > > > > > What needs to be done here? > > > > > > > > > > Not sure what needs to be done here.. But, if you have some comments, I > > > think everyone would welcome that.. > > > > > > Just an FYI, but Antonio has been giving some effort recently. And that > > is > > > a welcome addition! > > > > > > -brad w. > > > > > > > Regarding "Apache standard", I thought maybe something from here > > http://www.apache.org/dev/standards/ > > > > It was simply meant to make sure the code adheres to the 3rd party > licensing policy: > https://apache.org/legal/resolved.html > the release policy: > https://www.apache.org/legal/release-policy.html > > and any other Apache policy (or any other additional NetBeans requirements > we would want to add). > > Jan > > > > But I'm thinking this has to do when potentially implementing a standard, > > not necessarily what the standards are. > > > > Maybe it's more "notional" or maybe having to do with the "Apache Way" > > like: > > https://apache.org/theapacheway/index.html > > https://blogs.apache.org/foundation/entry/the-apache-way-to-sustainable > > https://apache.org/foundation/how-it-works.html > > https://apache.org/foundation/how-it-works.html#meritocracy > > https://blogs.apache.org/foundation/category/SuccessAtApache > > <https://blogs.apache.org/foundation/category/SuccessAtApache> > > https://blogs.apache.org/infra/entry/promoting-podlings > > > > Assume it has to do with meeting the quality standards (maybe like a > > podlings project) or other standard processes when managing things. > > > > Coding standards? > > > > Of course licensings is always something to consider. > > > > Eric Bresie > > [email protected] > > >
