Details
Major Description
Using a Wildfly profile with Weld causes things to blow up when executed with the following command mvn clean verify -Pwildfly-managed -Dweld.version=3.0.0.Alpha17 -Dmaven.repo.local=/home/manovotn/anotherMvnRepo.
There are two problems I detected so far:
- Compilation error (with clean Mvn repo)
- CDI control module - weld impl - is based on Weld version passed as parameter
- However, currently there is hardcoded cdi-api version in the wildfly profile
- Granted, it is provided, therefore the tests run fine on the Wildfly server, but the compilation of CDI control module will blow up as it now uses Weld 3.x and CDI 1.1 API
- At the moment, the CDI control module uses maven dependency plugin to unpack tck tests as test classes no matter the profile
- as can be seen here
- this makes no sense when running wildfly profile
- not to mention you do not have dependency on arq-weld-container so you cannot even execute it
Proposed solution:
- A dependency on cdi-api needs to be added to this profile
- it cannot be hardcoded (weld 2 used CDI 1.2, but weld 3 keeps up with latest CDI 2 EDR releases)
- We can either add a new build property like cdi.version
- this is all the more error prone
- if you don't pass this in, things get really weird
- We can fetch it in by declaring a dep. on a weld artifact, which has it
- e.g. adding a dependency on weld-core-impl which uses already defined weld.version will fetch in the required cdi-api as well
- Simply extend the Weld1/2/3 profiles and copy the build step into them
- it makes no sense to add these sources when running different profiles
Current draft of what I have in mind can be seen on top of my branch.
*Comments are welcome as I am not sure what I suggested above is a good way.*
Note that this should effect builds with Weld 2 and Weld 3 as they both use the very same profile for wildfly. Even though I currently tested this with Weld 3 only (getting to Weld 2 atm).