[ https://issues.apache.org/jira/browse/DELTASPIKE-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matej Novotny resolved DELTASPIKE-1204. --------------------------------------- Resolution: Resolved Fix Version/s: 1.7.2 Since there were no comments/objections I [pushed my solution|https://github.com/apache/deltaspike/commit/3fed4bfb910abf3e58b8e12fd6cead76aaddad9a]. Marking this issue as resolved. > Wildfly managed profiles blow up > -------------------------------- > > Key: DELTASPIKE-1204 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1204 > Project: DeltaSpike > Issue Type: Bug > Components: Build > Affects Versions: 1.7.1 > Environment: Wildfly managed (or build managed) > Weld 2/3 > Reporter: Matej Novotny > Assignee: Matej Novotny > Fix For: 1.7.2 > > > 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|https://github.com/apache/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L1074] > * 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|https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/pom.xml#L83] > * 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|https://github.com/manovotn/deltaspike/tree/wflyManagedFix]. > **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). -- This message was sent by Atlassian JIRA (v6.3.4#6332)