[ds annotation tck] usage of constants in component proeprty types is not covered

[laeubi]

PDE-DS generator passes the TCK but generates wrong XML in case a constant is referenced see:

• Constants not resolved in ComponentPropertyType annotation values eclipse-pde/eclipse.pde#973

I therefore think this case is currently not covered by the TCK.

[stbischof]

@HannesWell
Would you try you First tck test? Would be nice.

Or is @laeubi you Favorit?

[HannesWell]

@HannesWell
Would you try you First tck test? Would be nice.

Yes I can try it.

[timothyjward]

A TCK is not required to be exhaustive, and doesn't guarantee that the implementation is bug free. If you'd like to contribute an extra test for the TCK we can review a PR, but otherwise I would suggest closing this issue.

[laeubi]

@HannesWell is already assigned here so why closing it?

Otherwise same as

• [ds annotation tck] Usage of empty array and classes in componet property types is not covered by the TCK #646 (comment)

[timothyjward]

@HannesWell is already assigned here so why closing it?

No visible progress since it was assigned 2 months ago.

Having large numbers of stale issues makes it hard to track real problems or enhancements. This isn't an actual bug in the TCK (the TCK isn't required to test 100% of cases), but a request to add a test as a result of a bug found in an implementation. We're happy to accept contributions like this where the tests make sense, but not to hold open issues indefinitely for them.

[laeubi]

Having large numbers of stale issues makes it hard to track real problems or enhancements.

Why is it not "real" if no one yet finds time working on this? Beside that Github UI allows numerous sorting and filtering including "recently updated".

Such issue at least helps other to see that there is something that probably can be picket up or if they have the same problem, closing valid enhancements/issue to get them "out of view" is in my opinion the worst a project can do regarding its community if it is manly driven by volunteer contributions.

[timothyjward]

Why is it not "real" if no one yet finds time working on this?

This is not a "real" problem in the TCK as the TCK is not making an erroneous assertion. The problem as described in this issue would not cause a valid implementation to fail the TCK.

Closing valid enhancements/issue to get them "out of view" is in my opinion the worst a project can do regarding its community if it is manly driven by volunteer contributions.

I agree that closing valid issues is a problem, which is why the only issues I have suggested closing related to this TCK are the ones where the TCK is not at fault. This issue relates to the fact that a bug was found in an implementation.

The purpose of the issue tracker in this repository is to cover bugs in the TCK or specification, to gather requests/requirements for future specifications, or for essential work needed to maintain the osgi build/release process.

If you want to propose additional TCK tests based on your experience then you can absolutely create a PR for it, the merits of which can be discussed in the PR.

I will reiterate that the issues relating to bugs in the TCK are being left open. Closing "nice to have extra coverage" issues like this one that are showing no long-term progress helps to raise the profile of those other issues which do need community attention. It also helps to avoid the perception that this repository is not being maintained, and bugs are simply left unfixed indefinitely.

[laeubi]

This is not a "real" problem in the TCK as the TCK is not making an erroneous assertion. The problem as described in this issue would not cause a valid implementation to fail the TCK.

It allows invalid implementations to pass, and it does not fall into a category that can't be tested or is very complex to test, so for me that's a real problem if I can claim my implementation passes the TCK but fails for real world usages and requires manual testing.

So if you think its not a problem, it could still be labeled as an enhancement with help wanted as it obviously would improve the TCK and not make it worse or fail any existing valid implementations.

and bugs are simply left unfixed indefinitely.

I don't see any bug label on this issue and have never claimed it is a bug. And just closing it is the best way to have it "left unfixed indefinitely"...