Draft changes for packaging/deployment/lifecycle.

spec/src/main/asciidoc/core/injectionandresolution.asciidoc

@@ -24,9 +24,8 @@ The container is not required to support circular chains of dependencies where e
 
 Beans and their clients may be deployed in _modules_ in a module architecture.
 In a module architecture, certain modules are considered _bean archives_.
-The library may be an explicit bean archive or an implicit bean archive, as defined in <<bean_archive>>.
-In {cdi_lite}, libraries that are bean archives are always implicit bean archives.
-// TODO this all depends on how we define packaging and deployment for Lite, so this paragraph must be revisited!
+In {cdi_lite}, a library that is a bean archive is always an implicit bean archive, as defined in <<bean_archive_lite>>.
+Other kinds of bean archives exist in {cdi_full}.
 
 A bean packaged in a certain module is available for injection, lookup and name resolution to classes packaged in some other module if and only if the bean class of the bean is required to be _accessible_ to the other module by the class accessibility requirements of the module architecture.
 

spec/src/main/asciidoc/core/injectionandresolution_full.asciidoc

@@ -9,7 +9,7 @@
 
 In addition to rules defined in <<selection>>, the following rules apply.
 
-An alternative is not available for injection, lookup or name resolution to classes in a module unless the module is a bean archive and the alternative is explicitly _selected_ for the bean archive or the application.
+A library may be an explicit bean archive or an implicit bean archive, as defined in <<bean_archive>>.
 
 [[declaring_selected_alternatives_full]]
 

spec/src/main/asciidoc/core/packagingdeployment.asciidoc

@@ -1,6 +1,9 @@
 [[packaging_deployment]]
 
-== Packaging and deployment
+== Packaging and deployment in {cdi_full}
+
+This chapter replaces <<packaging_deployment_lite>> for the purpose of {cdi_full}.
+In case of overlap, the <<packaging_deployment_lite>> chapter should be considered merely informative.
 
 When an application is started, the container must perform _bean discovery_, detect definition errors and deployment problems and raise events that allow portable extensions to integrate with the deployment lifecycle.
 
@@ -16,7 +19,7 @@ Portable extensions may even integrate with the process of building the `Bean` o
 
 [[bean_archive]]
 
-=== Bean archives
+=== Bean archives in {cdi_full}
 
 Bean classes of enabled beans must be deployed in _bean archives_.
 
@@ -66,7 +69,7 @@ An extension may be deployed in any archive, including those that are not bean a
 
 [[initialization]]
 
-=== Application initialization lifecycle
+=== Application initialization lifecycle in {cdi_full}
 
 When an application is started, the container performs the following steps:
 
@@ -83,7 +86,7 @@ When an application is started, the container performs the following steps:
 
 [[shutdown]]
 
-=== Application shutdown lifecycle
+=== Application shutdown lifecycle in {cdi_full}
 
 When an application is stopped, the container performs the following steps:
 
@@ -93,13 +96,13 @@ When an application is stopped, the container performs the following steps:
 
 [[type_bean_discovery]]
 
-=== Type and Bean discovery
+=== Type and Bean discovery in {cdi_full}
 
 The container automatically discovers managed beans (according to the rules of <<what_classes_are_beans>>) in bean archives and searches the bean classes for producer methods, producer fields, disposer methods and observer methods.
 
 [[type_discovery_steps]]
 
-==== Type discovery
+==== Type discovery in {cdi_full}
 
 First the container must discover types.
 The container discovers:
@@ -192,7 +195,7 @@ If an explicit bean archive contains the `<trim/>` element in its `beans.xml` fi
 
 [[bean_discovery_steps]]
 
-==== Bean discovery
+==== Bean discovery in {cdi_full}
 
 For every type in the set of discovered types (as defined in <<type_discovery_steps>>), the container must:
 

spec/src/main/asciidoc/core/packagingdeployment_lite.asciidoc

@@ -2,8 +2,113 @@
 
 == Packaging and deployment
 
-// TODO
-[NOTE]
-====
-TBD based on what approach we choose
-====
+Before an application is started, or during application startup, the container must perform _bean discovery_, execute build compatible extensions, and detect definition errors and deployment problems.
+
+Bean discovery is the process of determining:
+
+* Bean archives within application, and any beans contained within them
+* Which alternatives and interceptors are _enabled_
+* The _ordering_ of enabled interceptors
+
+Additional beans may be registered programmatically via <<spi_lite>>.
+
+[[bean_archive_lite]]
+
+=== Bean archives
+
+Bean classes of enabled beans must be deployed in _bean archives_.
+
+A bean archive has a _bean discovery mode_ of either `annotated` or `none`.
+This is governed by presence of `beans.xml` file which can be either empty or it can declare the `bean-discovery-mode` attribute.
+Default value for this attribute is `annotated`.
+
+An archive which:
+
+* contains a `beans.xml` file with the `bean-discovery-mode` of `none`, or,
+* contains a portable or build compatible extension and no `beans.xml` file
+
+is not a bean archive.
+
+An _implicit bean archive_ is:
+
+* an archive which contains a `beans.xml` file that is empty, or,
+* an archive which contains a `beans.xml` file that has `bean-discovery-mode` attribute set to `annotated`
+
+When determining which archives are bean archives, the container must consider all JAR archives available through implementation-specific means.
+Implementations are required to document how the candidate JAR archives are found.
+
+The `beans.xml` file must be named:
+
+* `META-INF/beans.xml`.
+
+The container searches for beans in all bean archives discovered as described above.
+
+If a bean class is deployed in two different bean archives, non-portable behavior results.
+Portable applications must deploy each bean class in no more than one bean archive.
+
+Implicit bean archives are likely to contain classes which are not deployed as beans.
+
+An extension may be deployed in any archive, including those that are not bean archives.
+
+[[initialization_lite]]
+
+=== Application initialization lifecycle
+
+// TODO related to https://github.com/eclipse-ee4j/cdi/issues/482
+// also related to https://github.com/eclipse-ee4j/cdi/issues/496
+// Capture init process WRT build compatible extensions + type discovery + bean discovery
+// see <<initialization>> for format that is used for CDI Full
+
+[[shutdown_lite]]
+
+=== Application shutdown lifecycle
+
+When an application is stopped, the container must destroy all contexts.
+
+[[type_bean_discovery_lite]]
+
+=== Type and Bean discovery
+
+The container automatically discovers managed beans (according to the rules of <<what_classes_are_beans>>) in bean archives and searches the bean classes for producer methods, producer fields, disposer methods and observer methods.
+
+[[type_discovery_steps_lite]]
+
+==== Type discovery
+
+First the container must discover types.
+The container discovers each Java class with a bean defining annotation in an implicit bean archive.
+
+// TODO at this point, we should probably mention build compatible extensions and how you can get notified of events and change these types
+// we should mention Enhancement phase here and link to the relevant doc part
+// related to https://github.com/eclipse-ee4j/cdi/issues/483
+
+[[bean_discovery_steps_lite]]
+
+==== Bean discovery
+
+For every type in the set of discovered types (as defined in <<type_discovery_steps_lite>>), the container must:
+
+* inspect the type metadata to determine if it is a bean, and then
+* detect definition errors by validating the class and its metadata, and then
+* determine which alternatives and interceptors are enabled, according to the rules defined in <<enablement>>.
+// TODO mention any events we fire for build compatible extensions at this point - Processing
+// e.g. if we have an equivalent of ProcessBeanAttributes and/or ProcessBean
+// related to https://github.com/eclipse-ee4j/cdi/issues/483
+
+For each enabled bean, the container must search the class for producer methods and fields, as defined in <<producer_method>> and in <<producer_field>>, including resources, and for each producer:
+
+// TODO mention any events we fire for build compatible extensions at this point - Processing
+// e.g. if we have an equivalent of ProcessInjectionPoint and/or ProcessProducer and/or ProcessBeanAttributes and/or ProcessBean
+// related to https://github.com/eclipse-ee4j/cdi/issues/483
+
+For each enabled bean, the container must search the class for observer methods, and for each observer method:
+
+// TODO mention build compatible extension equivalent - Processing
+// e.g. if we have an equivalent of ProcessObserverMethod
+// related to https://github.com/eclipse-ee4j/cdi/issues/483
+
+Then, the container registers the `Bean` and `ObserverMethod` objects:
+
+* For each enabled bean that is not an interceptor, the container registers an instance of the `Bean` interface defined in <<bean>>.
+* For each enabled interceptor, the container registers an instance of the `Interceptor` interface defined in <<interceptor>>.
+* For each observer method of every enabled bean, the container registers an instance of the `ObserverMethod` interface defined in <<observer_method>>.