openocd plugin has dependency on managedPlugin which is not given in the manifest file

[jantje]

openocd plugin has dependency on managedPlugin which is not given in the manifest file

[ruspl-afed]

@ilg-ul do you think org.eclipse.embedcdt.core bundle could be good new home for GnuMcuPropertyTester to fix the reported problem?

[ilg-ul]

You mean to relocate the definition of isGnuMcu

	<extension point="org.eclipse.core.expressions.propertyTesters">
		<propertyTester
			class="org.eclipse.embedcdt.managedbuild.cross.core.GnuMcuPropertyTester"
			id="org.eclipse.embedcdt.managedbuild.cross.core.propertyTester"
			namespace="org.eclipse.embedcdt.managedbuild.cross.core"
			properties="isGnuMcu"
			type="java.lang.Object">
		</propertyTester>
	</extension>

from org.eclipse.embedcdt.managedbuild.cross.core to org.eclipse.embedcdt.core?

I guess we can do this. Are there any compatibility issues?

[ilg-ul]

I took a second look, and apparently the reason behind this tester is to enable the properties pages only for GNU MCU projects. It checks some substrings in options ids.

If these checks run the same when invoked from org.eclipse.embedcdt.core, instead of relocating the definition, probably a better idea would be to add a new property tester (like isEmbeddedCdt), and update the references in the debug plug-ins.

I'm a bit rusty on these details, so any suggestions are welcome.

[jantje]

My 2 cent
It is probably lots easier to use/create a GNU MCU projects nature (which is dependent on the org.eclipse.cdt.core.cnature)
and filter on the GNU MCU projects nature instead of org.eclipse.cdt.core.cnature and remove the enabled when

[ruspl-afed]

It is probably lots easier to use/create a GNU MCU projects nature (which is dependent on the org.eclipse.cdt.core.cnature)

It would be easier in the beginning, now it is harder, since people already have a lot of existing projects that don't have this nature and adding a nature now will add even more problems to solve.

[jantje]

It would be easier in the beginning, now it is harder, since people already have a lot of existing projects that don't have this nature and adding a nature now will add even more problems to solve.

I'm not fully agreeing here. Adding a nature is not that hard and as you can verify whether a project is a gnu mcu project you can create a listener and add the nature at project open if it is missing.

[jonahgraham]

Adding a nature is not that hard

IIUC the issue is not adding a nature for new projects, but that we still need the other version as all user's existing projects won't have the nature. Is that what you were referring to @ruspl-afed?

[ruspl-afed]

If you need to have both nature-independent check with listener and nature-based processing you pay twice for the same functionality, isn't it?
Please don't get me wrong, personally I prefer natures, but this functionality is for Embedded Developers who will hardly value Eclipse-style design but will be very frustrated because of any change on their data (and .project that holds natures is a part of user data).

as all user's existing projects won't have the nature. Is that what you were referring to @ruspl-afed?

exactly @jonahgraham

[ilg-ul]

Any suggestion on how to proceed with this issue?

Would adding a new tester like isEmbeddedCdt to the core plug-in and leaving the current tester as deprecated be acceptable?

[jantje]

Would adding a new tester like isEmbeddedCdt to the core plug-in and leaving the current tester as deprecated be acceptable?

If openocd plugin would reference isEmbeddedCdt tester; to me that would be fine as IMHO openocd plugin has a dependency on core plugin in the manifest file.

[ilg-ul]

Fixed on 2023-07-24.

[ilg-ul]

Fixed on 2023-07-24.

[jantje]

Thanks