to avoid possible issues in production environment where the test bundle will be most likely not deployed.
We're in a modular world, you never know what's deployed and in which context; and you can't assume how things are consumed.
M
So what is the problem? Just add the flag to test bundles you are working on and that's it.
The problem is that it's inconsistent: build works fine because it does OSGi, and just opening the project in my workspace will cause an error to pop-up. Then I'll need to put the same flag, potentially annoying transitively other consumers of my test bundle if their are any.
It might have no value for you because you know which bundles are supposed to be deployed and which not in the production
Define "production". Here for Platform, there are committers that are all supposed to understand that kind of things when merging or reviewing. I suspect if there is no value for me, there is no value for any committer, thus no compelling value for the project.
but other people might not have that knowledge and happily consume API from the test projects inside production projects.
There are already API tools, internal, x-friends... flags to highlight all that in a more OSGi-native way, so the value added by this flag is 0 compared to it.
And the org.eclipse.ui.tests.harness bundle can be interesting in some cases in production of other projects (eg SWTBot is using IIRC in its "production").
I'm still not convinced about the value and would really like to read some existing discussion or bug report where this flag has helped anyone; because I could see here, and earlier in Tycho (that interprets that flag differently/correctly as opposed to how Platform/PDE sets it) that is has caused some trouble.
