Given that the component has no default assignee it's safe to assume this issue won't help. Are you opposed to resolving this as Not a Defect?

Resolve it as whatever you like.
I just tried to get some feedback from the maintainers before I start to
write a new cmake-plugin from scratch.
Kanstantsin suggested to ask here.

The only developer to work on the plugin since 2009 has made the last change in April 2011, and has never done anything in this tracker (volkai). Given that, and that there's no default assignee for the component, I doubt you'll have any success with this issue.

However, you could try emailing to ask about the status of the plugin, see email address in user profile linked above.

before I start to write a new cmake-plugin from scratch.

Maybe you could take over maintainership of the plugin rather than do a full rewrite? There are over 1000 known users of the plugin who could benefit from that.

I contacted the developer, he said he would not have any time to maintain it and is no longer using it himself. (Thanks for the profile link)

Maybe you could take over maintainership of the plugin rather than do a full rewrite? There are over 1000 known users of the plugin who could benefit from that.

Maintainership-take-over could be an option, but I have to admit that I'm more than hesitating to deal with issues, the original developer was not willing to look at in years. Even then, a full rewrite will be necessary, since I do not work on fully undocumented code.
And getting the quirks out of the existing plugin, it will require to break compatibility with any existing jobe.

Glad I could point you in the right direction.

Consider asking for advice on the jenkinsci-dev mailing list. I'm pretty sure it's not too much effort to do a kind of "import configuration" step (basically during XML deserialization, readResolve and all that) so that your rewritten code could work with existing configuration. You can also make it a semantically versioned "2.0" and note some incompatibility to previous versions in plugin manager/update center to make users aware of the big step.

I think there's value in continuing work (at least from a migration of on-disk configuration point of view), as having multiple plugins around that do essentially the same thing (assuming that's the case) is a weird situation for everyone. Plus, you'll inherit the users of the existing plugin, finding bugs for you Just my suggestion, how you decide to proceed is of course your choice.