Re: Build failed in Jenkins: DeltaSpike Deploy #2115

[John D. Ament]

Looks like this was the one job where that profile was still working right,
I tweaked the job config and restarted it

:-(

If there are any other java 8 jobs that are broken now, just add
-Pjava8.tests to the maven config.

John

On Thu, Nov 30, 2017 at 10:15 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/DeltaSpike%20Deploy/2115/display/redirect?page=changes
> >
>
> Changes:
>
> [john.d.ament] Disabling java 8 tests as recent jenkins changes make this
> profile
>
> --
> [...truncated 966.43 KB...]
> [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
> data-module-project ---
> [INFO] Deleting <
> https://builds.apache.org/job/DeltaSpike%20Deploy/ws/deltaspike/modules/data/target
> >
> [INFO]
> [INFO] --- apache-rat-plugin:0.12:check (default) @ data-module-project ---
> [INFO] Enabled default license matchers.
> [INFO] Will parse SCM ignores for exclusions...
> [INFO] Finished adding exclusions from SCM ignore files.
> [INFO] 63 implicit excludes (use -debug for more details).
> [INFO] Exclude: .idea/**/*
> [INFO] Exclude: readme/**/*
> [INFO] Exclude: **/*.log
> [INFO] Exclude: target/**
> [INFO] Exclude: test-ee7/target/**
> [INFO] Exclude: **/*.iml
> [INFO] Exclude: **/MANIFEST.MF
> [INFO] 72 resources included (use -debug for more details)
> [INFO] Rat check: Summary over all files. Unapproved: 6, unknown: 6,
> generated: 0, approved: 46 licenses.
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache DeltaSpike .. SUCCESS [
> 9.930 s]
> [INFO] Apache DeltaSpike Sources .. SUCCESS [
> 7.132 s]
> [INFO] Apache DeltaSpike CheckStyle-rules . SUCCESS [
> 21.050 s]
> [INFO] Apache DeltaSpike Parent ... SUCCESS [
> 10.937 s]
> [INFO] Apache DeltaSpike Test-Utils ... SUCCESS [
> 15.391 s]
> [INFO] Apache DeltaSpike Code Parent .. SUCCESS [
> 10.614 s]
> [INFO] Apache DeltaSpike Core . SUCCESS [
> 9.761 s]
> [INFO] Apache DeltaSpike Core-API . SUCCESS [01:14
> min]
> [INFO] Apache DeltaSpike Core-Implementation .. SUCCESS [
> 52.458 s]
> [INFO] Apache DeltaSpike ContainerControl parent .. SUCCESS [
> 9.824 s]
> [INFO] Apache DeltaSpike CDI ContainerControl API . SUCCESS [
> 14.664 s]
> [INFO] Apache DeltaSpike CDI ContainerControl TCK . SUCCESS [
> 14.598 s]
> [INFO] Apache DeltaSpike CDI OWB-ContainerControl . SUCCESS [
> 16.990 s]
> [INFO] Apache DeltaSpike CDI Weld-ContainerControl  SUCCESS [
> 14.853 s]
> [INFO] Apache DeltaSpike CDI OpenEJB-ContainerControl . SUCCESS [
> 20.835 s]
> [INFO] Apache DeltaSpike CDI Servlet-ContainerControl . SUCCESS [
> 17.783 s]
> [INFO] Apache DeltaSpike Modules .. SUCCESS [
> 9.985 s]
> [INFO] Apache DeltaSpike Proxy-Module . SUCCESS [
> 9.963 s]
> [INFO] Apache DeltaSpike Proxy-Module API . SUCCESS [
> 14.253 s]
> [INFO] Apache DeltaSpike Proxy-Module Impl ASM5 ... SUCCESS [
> 18.959 s]
> [INFO] Apache DeltaSpike Security-Module .. SUCCESS [
> 9.698 s]
> [INFO] Apache DeltaSpike Security-Module API .. SUCCESS [
> 14.664 s]
> [INFO] Apache DeltaSpike Security-Module Impl . SUCCESS [
> 19.988 s]
> [INFO] Apache DeltaSpike JPA-Module ... SUCCESS [
> 9.662 s]
> [INFO] Apache DeltaSpike JPA-Module API ... SUCCESS [
> 14.761 s]
> [INFO] Apache DeltaSpike JPA-Module Impl .. SUCCESS [
> 26.463 s]
> [INFO] Apache DeltaSpike Servlet-Module ... SUCCESS [
> 9.581 s]
> [INFO] Apache DeltaSpike Servlet-Module API ... SUCCESS [
> 13.733 s]
> [INFO] Apache DeltaSpike Servlet-Module Impl .. SUCCESS [
> 15.576 s]
> [INFO] Apache DeltaSpike JSF-Module ... SUCCESS [
> 9.730 s]
> [INFO] Apache DeltaSpike JSF-Module API ... SUCCESS [
> 15.936 s]
> [INFO] Apache DeltaSpike JSF-Module Impl .. SUCCESS [
> 31.941 s]
> [INFO] Apache DeltaSpike JSF-Module Impl (EE6 only) ... SUCCESS [
> 16.465 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module .. SUCCESS [
> 9.889 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module API .. SUCCESS [
> 26.509 s]
> [INFO] Apache DeltaSpike Partial-Bean-Module Impl . SUCCESS [
> 20.169 s]
> [INFO] Apache DeltaSpike BeanValidation-Module  SUCCESS [
> 10.116 s]
> [INFO] Apache DeltaSpike BeanValidation-Module API  SUCCESS [
> 13.972 s]
> [INFO] Apache DeltaSpike BeanValidation-Module Impl ... SUCCESS [
> 17.688 s]
> [INFO] Apache DeltaSpike Data-Module .. FAILURE [
> 0.781 s]
> [INFO] Apache DeltaSpike Data-Module API 

Re: CI for DeltaSpike?

[Gerhard Petracek]

hi matej,

one of the (manual) steps for a release is to check those results (before a
release gets started at all).
i'm not sure if others are still following it. at the time i did the
releases, it was a mandatory step.
back then i also added ci-jobs for new owb/weld releases immediately.
(it looks like nobody took over that part.)

regards,
gerhard



2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau :

> Sorry Matej, I don't get how Travis would help since you can do the
> same with jenkins which is already configured.
>
> Having the default build running on both weld and OWB would be more
> beneficial IMHO, but it is just the opinion from my side of the fence
> and experience.
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-30 14:57 GMT+01:00 Matej Novotny :
> > Thanks, but it was more of a rhetorical question (you saved me some
> digging though).
> > Still my claim holds true, nobody cares about them much. They must have
> been failing for quite some time now
> > Not to mention they aren't even updated to latest Weld version (or
> WildFly version for that matter).
> >
> >
> > Matej
> >
> > - Original Message -
> >> From: "Romain Manni-Bucau" 
> >> To: dev@deltaspike.apache.org
> >> Sent: Wednesday, November 29, 2017 5:03:02 PM
> >> Subject: Re: CI for DeltaSpike?
> >>
> >> Hi Matej,
> >>
> >> they are all on the ASF jenkins:
> >> https://builds.apache.org/view/A-D/view/DeltaSpike/
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >>
> >>
> >> 2017-11-29 16:47 GMT+01:00 Matej Novotny :
> >> > Hello
> >> >
> >> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I
> meant
> >> > Integration OFC) and DeltaSpike.
> >> > Apparently, there is no such thing now and even while some CI jobs
> exist
> >> > (where are they, anyway?), nobody really pays attention to them.
> >> > I mean those for Weld ones must have been failing for few months and
> yet
> >> > the JIRAs causing that were happily marked as Resolved.
> >> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> >> >
> >> > Today I noticed there is going to be a release soon and so I quikly
> went to
> >> > check how the build/tests fare with Weld profiles.
> >> > Turned out to be a disaster. So I then have to spend considerable time
> >> > backtracking the changes and figuring out the actual problem.
> >> > And it's not the first time this happened either.
> >> >
> >> > Therefore I wanted to bring up the topic of CI to avoid this in the
> future.
> >> > The ideal scenario is sending PRs and having them checked *before*
> merging
> >> > - obviously not an option here.
> >> > The GH repo is but a mirror (something we have to stick to I presume)
> which
> >> > makes it more complex, but still, it should be possible to set up a
> Travis
> >> > build on GH master which will execute after every sync.
> >> > That way the failures would be readily visible (via the travis status
> >> > "button").
> >> > In order to discover most problems there is no need for a complete
> test
> >> > matrix, it would do to just have two version of OWB and Weld without
> EE
> >> > container (with just the Arq. one).
> >> >
> >> >
> >> > A penny for your thoughts?
> >> >
> >> >
> >> > Regards
> >> > Matej
> >>
>

[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272712#comment-16272712
 ] 

ASF subversion and git services commented on DELTASPIKE-1302:
-

Commit e10e8863afcaeafc37c0d1184fb6d8058a68d081 in deltaspike's branch 
refs/heads/master from [~manovotn]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=e10e886 ]

DELTASPIKE-1302 Fix test deployment archive.


> ThreadPoolManager: ExecutorService map is always empty
> --
>
> Key: DELTASPIKE-1302
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.8.0
>Reporter: Alonso Gonzalez
>Priority: Minor
>
> ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to 
> an ExecutorService. Unfortunately the map never gets populated. It's always 
> empty.
> I need this because I want to use a specific ExecutorService with @Futureable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: CI for DeltaSpike?

[Romain Manni-Bucau]

Sorry Matej, I don't get how Travis would help since you can do the
same with jenkins which is already configured.

Having the default build running on both weld and OWB would be more
beneficial IMHO, but it is just the opinion from my side of the fence
and experience.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-30 14:57 GMT+01:00 Matej Novotny :
> Thanks, but it was more of a rhetorical question (you saved me some digging 
> though).
> Still my claim holds true, nobody cares about them much. They must have been 
> failing for quite some time now
> Not to mention they aren't even updated to latest Weld version (or WildFly 
> version for that matter).
>
>
> Matej
>
> - Original Message -
>> From: "Romain Manni-Bucau" 
>> To: dev@deltaspike.apache.org
>> Sent: Wednesday, November 29, 2017 5:03:02 PM
>> Subject: Re: CI for DeltaSpike?
>>
>> Hi Matej,
>>
>> they are all on the ASF jenkins:
>> https://builds.apache.org/view/A-D/view/DeltaSpike/
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>
>>
>> 2017-11-29 16:47 GMT+01:00 Matej Novotny :
>> > Hello
>> >
>> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
>> > Integration OFC) and DeltaSpike.
>> > Apparently, there is no such thing now and even while some CI jobs exist
>> > (where are they, anyway?), nobody really pays attention to them.
>> > I mean those for Weld ones must have been failing for few months and yet
>> > the JIRAs causing that were happily marked as Resolved.
>> > Meaning whoever fixed that probably only ran smoke tests with OWB.
>> >
>> > Today I noticed there is going to be a release soon and so I quikly went to
>> > check how the build/tests fare with Weld profiles.
>> > Turned out to be a disaster. So I then have to spend considerable time
>> > backtracking the changes and figuring out the actual problem.
>> > And it's not the first time this happened either.
>> >
>> > Therefore I wanted to bring up the topic of CI to avoid this in the future.
>> > The ideal scenario is sending PRs and having them checked *before* merging
>> > - obviously not an option here.
>> > The GH repo is but a mirror (something we have to stick to I presume) which
>> > makes it more complex, but still, it should be possible to set up a Travis
>> > build on GH master which will execute after every sync.
>> > That way the failures would be readily visible (via the travis status
>> > "button").
>> > In order to discover most problems there is no need for a complete test
>> > matrix, it would do to just have two version of OWB and Weld without EE
>> > container (with just the Arq. one).
>> >
>> >
>> > A penny for your thoughts?
>> >
>> >
>> > Regards
>> > Matej
>>

Re: CI for DeltaSpike?

[Matej Novotny]

Thanks, but it was more of a rhetorical question (you saved me some digging 
though).
Still my claim holds true, nobody cares about them much. They must have been 
failing for quite some time now
Not to mention they aren't even updated to latest Weld version (or WildFly 
version for that matter).


Matej

- Original Message -
> From: "Romain Manni-Bucau" 
> To: dev@deltaspike.apache.org
> Sent: Wednesday, November 29, 2017 5:03:02 PM
> Subject: Re: CI for DeltaSpike?
> 
> Hi Matej,
> 
> they are all on the ASF jenkins:
> https://builds.apache.org/view/A-D/view/DeltaSpike/
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> 
> 
> 2017-11-29 16:47 GMT+01:00 Matej Novotny :
> > Hello
> >
> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
> > Integration OFC) and DeltaSpike.
> > Apparently, there is no such thing now and even while some CI jobs exist
> > (where are they, anyway?), nobody really pays attention to them.
> > I mean those for Weld ones must have been failing for few months and yet
> > the JIRAs causing that were happily marked as Resolved.
> > Meaning whoever fixed that probably only ran smoke tests with OWB.
> >
> > Today I noticed there is going to be a release soon and so I quikly went to
> > check how the build/tests fare with Weld profiles.
> > Turned out to be a disaster. So I then have to spend considerable time
> > backtracking the changes and figuring out the actual problem.
> > And it's not the first time this happened either.
> >
> > Therefore I wanted to bring up the topic of CI to avoid this in the future.
> > The ideal scenario is sending PRs and having them checked *before* merging
> > - obviously not an option here.
> > The GH repo is but a mirror (something we have to stick to I presume) which
> > makes it more complex, but still, it should be possible to set up a Travis
> > build on GH master which will execute after every sync.
> > That way the failures would be readily visible (via the travis status
> > "button").
> > In order to discover most problems there is no need for a complete test
> > matrix, it would do to just have two version of OWB and Weld without EE
> > container (with just the Arq. one).
> >
> >
> > A penny for your thoughts?
> >
> >
> > Regards
> > Matej
> 

[jira] [Resolved] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matej Novotny resolved DELTASPIKE-1304.
---
Resolution: Fixed

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272436#comment-16272436
 ] 

Matej Novotny commented on DELTASPIKE-1304:
---

Oops, excuse the typo in commit message, obviously it should say "CdiTestRunner 
will *now* use..."

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272433#comment-16272433
 ] 

ASF subversion and git services commented on DELTASPIKE-1304:
-

Commit 390d270cca6b300ab3f617ba4e61a69029952227 in deltaspike's branch 
refs/heads/master from [~manovotn]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=390d270 ]

DELTASPIKE-1304 CdiTestRunner will not use flat deployment for Weld.


> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

Matej Novotny created DELTASPIKE-1304:
-

 Summary: Make CdiTestRunner use "flat" deployment on Weld by 
default
 Key: DELTASPIKE-1304
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
 Project: DeltaSpike
  Issue Type: Improvement
Reporter: Matej Novotny


In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
but is still configurable.

Since DS depends on Weld 1.x API, there is no option to configure this via 
{{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
property.

Flat deployment would eliminate some test problems as, for instance, custom 
{{MockManager}}. Namely 
[{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
 and the test linked to it which breaks all tests in that module for Weld.
The reason is that it uses {{beans.xml}} to enable alternatives, which in Weld 
only works for given bean archive (e.g. this leads to eternal Holy Bean Archive 
War between Weld and OWB interpretations :) ).
Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
is unit test level and the "flatness" doesn't really matter there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matej Novotny updated DELTASPIKE-1304:
--
Fix Version/s: 1.8.1

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DELTASPIKE-1304) Make CdiTestRunner use "flat" deployment on Weld by default

[Matej Novotny (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matej Novotny reassigned DELTASPIKE-1304:
-

Assignee: Matej Novotny

> Make CdiTestRunner use "flat" deployment on Weld by default
> ---
>
> Key: DELTASPIKE-1304
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1304
> Project: DeltaSpike
>  Issue Type: Improvement
>Reporter: Matej Novotny
>Assignee: Matej Novotny
> Fix For: 1.8.1
>
>
> In Weld 1 this was a default behaviour, with Weld 2 and onwards, this changed 
> but is still configurable.
> Since DS depends on Weld 1.x API, there is no option to configure this via 
> {{org.jboss.weld.environment.se.Weld}}, but it can still be done via system 
> property.
> Flat deployment would eliminate some test problems as, for instance, custom 
> {{MockManager}}. Namely 
> [{{CustomMockManager}}|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/impl/src/test/java/org/apache/deltaspike/test/testcontrol/CustomMockManager.java]
>  and the test linked to it which breaks all tests in that module for Weld.
> The reason is that it uses {{beans.xml}} to enable alternatives, which in 
> Weld only works for given bean archive (e.g. this leads to eternal Holy Bean 
> Archive War between Weld and OWB interpretations :) ).
> Swapping the test runner behaviour with Weld shouldn't cause any harm as this 
> is unit test level and the "flatness" doesn't really matter there.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)