Signature issues with Tycho 2.4.0 about tycho

[mickaelistria]

@laeubi This is a consequence of d9a5824 . This seems to highlight that the approach of tests in module but without having this module signed is not really usable together with signed bundles. Again, it seems to me that generating a test fragment, that would be signed, would work better.
The bundle in question is oddly configured though. i'll try to fix the bundle first.

[laeubi]

So the new feature executes now tests that previously where ignored? I don't see how test fragment could hlep here as they do not apply here anyways.

[mickaelistria]

So the new feature executes now tests that previously where ignored?

Yes, because the module was an eclipse-plugin and had the test attribute set in .classpath. But I think this is worth fixing this module first and I submitted https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/179816

I don't see how test fragment could hlep here as they do not apply here anyways.

It wouldn't help to fix this particular issue; it's just a reminder that tests that are not part of the same classloader as main artifact can fail in different ways because of classloading or class access restrictions; and that is something that works just fine with test-fragments. It's just IMO 1 more reason to have the story of the "tests in bundles" support to generate an explicit test fragment as it allows more reliable class access.

[laeubi]

The it should either be a test-plugin or distinguish between Uinit and integration test with a proper filter. The "test-fragment" discussion really does not relate here and won't have changed anything.
Beside that I still don't see any benefit in supporting this, the whole classloader/acessrestriction thing simply has no meaning when defining a test class and only complicates the whole thing with no gain. In fact it even does not make sense for plain unit-test as there is no "OSGI-Runtime".

[laeubi]

As the referenced bug is closed I think we can close this too, please reopen if you see any issue.