ah. ok. For cdi 1.0, if all the implementor checks all jars having beans.xml and then merge the classes to the module bean archive, this will be fine. I think a spec issue will be raised to update section 5.

On Mon, May 4, 2015 at 8:59 AM, Mark Struberg <struberg@yahoo.de> wrote:
The CDI-1.0 TCK initially did not check anything in that regard. A test got added in a _very_ late version. This was in fact released AFTER CDI-1.1 was published if I remember correctly. So this version is not even part of the EE6 TCK…

LieGrue,
strub

> Am 04.05.2015 um 09:07 schrieb Jozef Hartinger <jharting@redhat.com>:
>
> Yes, chapter 5 is a bit confusing when it comes to composite Java EE modules. Comments inline:
>
> On 05/03/2015 12:20 AM, Emily Jiang wrote:
>> I agree with Mark. I am confused about section 5 and section 12. Weld-2 leaves the work of specifying the bean archive to the integrator. I am wondering how the new version of app server using Weld-2 can pass the CDI 1.1/1.2 CTS at all if the integrator creates its bean archives based on section 12.
> The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented. Therefore, implementing bean archive as defined in Chapter 12 is the right approach for a Weld integrator.
>>
>> I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?),  is based on section 5. Can someone confirm? The spec needs to be updated to remove the conflict between section 5 and section 12.
>> ---------- Forwarded message ----------
>> From: Emily Jiang <emijiang6@googlemail.com>
>> Date: Sat, May 2, 2015 at 10:21 PM
>> Subject: Re: [cdi-dev] bean archives
>> To: Mark Struberg <struberg@yahoo.de>
>>
>>
>> I agree with Mark. I am confused about section 5 and section 12. Weld-2 leaves the work of specifying the bean archive to the integrator. I am wondering how the new version of app server using Weld-2 can pass the CDI 1.1/1.2 CTS at all if the integrator creates its bean archives based on section 12.
>>
>> I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?),  is based on section 5. Can someone confirm? The spec needs to be updated to remove the conflict between section 5 and section 12.
>>
>> On Sat, May 2, 2015 at 3:47 PM, Mark Struberg <struberg@yahoo.de> wrote:
>> Actually the rules are still not clear. Section 5 and 12 contradict each other. The EE6 RI, JBossAS6 and TomEE and WAS did behave like in section 5 (1 BDA per ee-module) whereas Weld-2 behaves like in section 12.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Saturday, 2 May 2015, 10:13, Antoine Sabot-Durand <antoine@sabot-durand.net> wrote:
>>
>>
>> Hi Emily,
>>
>> The rules) apply to each jar (archive). There is no merging, thus an app can contain three types of archives :
>> Non bean archives,
>> Implicit bean archives,
>> Explicit bean archives.
>>
>> Antoine Sabot-Durand
>>
>>
>> Le 1 mai 2015 à 23:03, Emily Jiang <emijiang6@googlemail.com> a écrit :
>>
>>>
>>> I have a question on bean archives.
>>>
>>> For the jars under web-inf\lib, are they individual bean archives or they should be merged   with web-inf\classes files and use the beans.xml under web-inf\ to form one bean archive?
>>>
>>>
>>> If they are merged together to form one bean archive, what will happen if they have their own beans.xml under Meta-inf dir?
>>>
>>> Below is the what spec says, but it does not mention the jar under web-inf\lib. The spec should make this situation clear.
>>>
>>> In the CDI1.2 spec:
>>> When determining which archives are bean archives, the container must consider:
>>> • Library jars, EJB jars or application client jars
>>> • The WEB-INF/classes directory of a war
>>> • Directories in the JVM classpath
>>> The container is not required to support application client jar bean archives.
>>> A Java EE container is required by the Java EE specification to support Java EE modules. Other
>>> containers may or may not provide support for war, EJB jar or rar bean archives.
>>> The beans.xml file must be named:
>>> • META-INF/beans.xml , or,
>>> • in a war, WEB-INF/beans.xml or WEB-INF/classes/META-INF/beans.xml.
>>>
>>>
>>>
>>> --
>>> Thanks
>>> Emily
>>> =================
>>> Emily Jiang
>>> ejiang@apache.org
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@apache.org
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@apache.org
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>>
>> cdi-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.




--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org