There are a couple of issues with how we stage API jars that impact CIs that are needed for specification approval.
1. If the API jars the CI depends on are only in the Jakarta staging repo, it has to include a profile to load the API jars from the to build. However, CIs may not be able to do their own release to the staging repo because they are not Eclipse project. Weld is one example. It would be better if spec reviews could be done in a way so that they get to a point where staged jars could be released prior to the final ballot. If a problem comes up a new point release could always be done.
2. Even though CDI is a wave 3 spec in terms of API dependencies, it has tests for the full platform and includes testcases for latter wave components. This means that the TCK used to verify the CDI spec really cannot be finalized until all of the platform APis exist in final form. Now that there is a public platform TCK project, those tests depending on latter waves should really be broken out and run as part of the respective TCK for the latter stage waves. We need a common way to produce test artifacts that can be consumed by specification TCKs. For example, the CDI team creates the tests that cover the specification mandates for EJBs and produces a test jar. The EJB/platform TCKs need to pull that in to test the CDI/EJB interactions.