I think you should also remove https://github.com/cdi-spec/cdi/blob/master/api/pom.xml#L301.

Aha, <skip>true</skip> is used to skip the default execution. That's confusing. I suppose there was no easier way to configure it...

Hm, it seems that AnnotationLiteralTest cannot reveal the problem with java.lang.Class.getDeclaredMethods() because (javadoc):

Throws:
SecurityException - If a security manager, s, is present and any of the following conditions is met:
* the caller's class loader is not the same as the class loader of this class and invocation of s.checkPermission method with RuntimePermission("accessDeclaredMembers") denies access to the declared methods within this class
* the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class
```

The test configuration is really puzzling, I don't see why you firstly skip test execution and then re-enable it in both phases (e.g. L301, L314, L327). If you remove all three, I think it will still execute - or is there any special reason for it?

The test configuration is really puzzling, I don't see why you firstly skip test execution and then re-enable it in both phases

@manovotn I need 2 test suites because the standard test are doing a lot of reflection and I couldn't activate SM for them. Adding a second test suite was necessary to activate SM for it. I have problem while overriding the standard test so I have to cancel it (<skip>true</skip>). But perhaps I can give another try...

Privileged action must be also used for Class#getDeclaredMethods()

Ok but how do you think I can test that?

The test configuration is really puzzling

I achieved to simplify surefire config and make tests launch clearer by removing <skip>true</skip> and override default-test suite instead of disabling it and create a new one.

Isn't this an impl detail? Ofc it's the official spec api, but this doesn't change the contract. So nothing needs to be released spec wise, right?

Isn't this an impl detail?

@struberg no it is not. User can have his own implementation of AnnotationLiteral which naturally extends this class. And on instantiation of that class the constructor on AnnotationLiteral is invoked. That in turn invokes getMembers() method which then invokes getDeclaredMethods() and that can cause issues with security manager.

@manovotn yes, the api.jar should get fixed. But that can be done as a simple maintenance release. It doesn't require a new spec revision.

@struberg Yes, we target a "simple API maintenance release" named CDI 2.0.SP1; except that it's probably not so simple because of JCP rules etc. @antoinesd knows more.

@struberg. It's a maintenance release. Doing it in the context of the JCP would have required to launch a MR (more than 60 days).

oki @antoinesd and @mkouba I think we are on the same page. Wenn talking about a cdi-api 'Maintenance Release' I also didn't mean a CDI Spec MR.
In my eyes it's really just a bugfix release of the cdi-api.jar. Kind of 2.0.1.

In any case nothing which requires to involve the EE EC for getting it to the people.