Add cnd.lsp module to the friends list of the nativeexecution module

[piotrhoppe]

The cnd.lsp module uses the nativeexecution API but is missing from its friends list. This PR adds cnd.lsp to the allowed friends of the nativeexecution module.

This is part of the ongoing work on standalone netbeans cnd plugin.

@jtulach please review.

[jtulach]

Opinion

• the list of "friend` modules" here is too long already
• hence turn it into simple <public-packages> - just like

  netbeans/platform/openide.execution/nbproject/project.xml

  Lines 88 to 90 in ed40dbb

  	<public-packages>
  	<package>org.openide.execution</package>
  	</public-packages>

• this is an just opinion
  • if others believe the "friend madness" shall continue
  • I can approve the extra entry
  • even I consider the list of more than hundred friends ridiculous

Request

• this change is missing versioning
  • without versioning this change is subject to this linkage problem
• you have to increase version base:
  • example:

    netbeans/platform/openide.execution/manifest.mf

    Line 3 in ed40dbb

    OpenIDE-Module-Specification-Version: 9.36

  • probably here: https://github.com/piotrhoppe/netbeans/blob/94cf34c11a72ae4823ee097c8a90dc5ff1a7642d/ide/dlight.nativeexecution/nbproject/project.properties#L24
• the cnd.lsp module must request the new version of org.netbeans.modules.dlight.nativeexecution otherwise the linkage error may pop up
• this must be done regardless of my opinion or advice - hence requesting changes

Advice

• you should document the change at apichanges.xml file
• a file present in every decent API providing module - https://github.com/piotrhoppe/netbeans/blob/94cf34c11a72ae4823ee097c8a90dc5ff1a7642d/platform/openide.execution/apichanges.xml#L59
  • verify with ant javadoc to see if that renders propery
• alas the apichanges.xml, file is missing in the dlight.nativeexecution project
• asking an external contributor to add it may be too much
  • here is a API Development link, if you want to try
• but this is not a request either

[mbien]

you have to increase version base:

example:

netbeans/platform/openide.execution/manifest.mf

Line 3 in ed40dbb
OpenIDE-Module-Specification-Version: 9.36

@jtulach the manifests are bumped once per release e.g #9344, but it also wouldn't hurt, outside of creating gaps in the released versions.

[neilcsmith-net]

the manifests are bumped once per release e.g #9344, but it also wouldn't hurt ...

I was about to comment that it would be better to leave that out. It does occasionally cause issues with reverts, and it's not really necessary given the version bumps and lack of a development UC. Other changes including removing friends usage, changing the dependency version and adding the API change info all agreed with.

[jtulach]

@jtulach the manifests are bumped once per release e.g #9344, but it also wouldn't hurt, outside of creating gaps in the released versions.

not really necessary given the version bumps and lack of a development UC

I do not think it is enough to wait for next release of NetBeans. The org.netbeans.modules.cnd.lsp usage needs to update its dependency on org.netbeans.modules.dlight.nativeexecution. To update such dependency now, there must be an increase of the version, because otherwise there is no way to track the API change of changing the list of friends (or rather going fully public). To let org.netbeans.modules.cnd.lsp express I need the nativeexecution module in a version that I am allowed use we need to increment the version and the org.netbeans.modules.cnd.lsp needs to depend on that incremented version. This is basically the same as adding a method into some module API - it also needs a version increment.

[mbien]

I do not think it is enough to wait for next release of NetBeans.

the versions were already incremented for the next release.

The org.netbeans.modules.cnd.lsp usage needs to update its dependency on org.netbeans.modules.dlight.nativeexecution.

the consumer modules can update their dependency requirement to the new version, since that version is already bumped in master when compared to the current release (NB30). Unless I am missing something here or we are talking about different version attributes. Although a version bump doesn't hurt (other than creating unreleased version gaps) it doesn't really add anything either.

If nobody is making use of the global bumps anymore we could discuss to stop doing those, since that would be one giant commit less per release with all the communication to avoid potential conflicts etc.

[neilcsmith-net]

the versions were already incremented for the next release.

👍 as I said, not really necessary. We can and should track all version changes based on the version increments made directly after branch.

Although a version bump doesn't hurt ...

Mostly they don't, but we have occasionally had some cross-branch fun with reverts and trying to stop versions going backwards! 😄

If nobody is making use of the global bumps anymore we could discuss to stop doing those ...

Personally, I don't think that's a good idea. Better to have the occasional double increment than miss something, and it makes the delivery branch strategy easier to work with.