[ 
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)

Reply via email to