November 2009 - weld-commits - Jboss List Archives

Weld SVN: r4928 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 21:33:04 -0500 (Mon, 09 Nov 2009) New Revision: 4928 Modified: doc/trunk/reference/en-US/extend.xml Log: fix errors Modified: doc/trunk/reference/en-US/extend.xml =================================================================== --- doc/trunk/reference/en-US/extend.xml 2009-11-10 02:23:12 UTC (rev 4927) +++ doc/trunk/reference/en-US/extend.xml 2009-11-10 02:33:04 UTC (rev 4928) @@ -2,7 +2,7 @@ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [ ]>  <chapter id="extend"> - <title>Extending CDI through portable extensions</title> + <title>Portable extensions</title> <para> CDI is intended to be a foundation for frameworks, extensions and integration with other technologies. Therefore, @@ -35,12 +35,18 @@ <para> Providing its own beans, interceptors and decorators to the container </para> + </listitem> + <listitem> <para> + Injecting dependencies into its own objects using the dependency injection service </para> - Injecting dependencies into its own objects using the dependency injection service + </listitem> + <listitem> <para> Providing a context implementation for a custom scope </para> + </listitem> + <listitem> <para> Augmenting or overriding the annotation-based metadata with metadata from some other source </para> @@ -56,7 +62,7 @@ <title>The <literal>BeanManager</literal> object</title> <para> - The <literal>BeanManager</literal> interface lets us register and obtain beans, interceptors, decorators, + The <literal>BeanManager</literal> interface lets us obtain beans, interceptors, decorators, observers and contexts programmatically. </para> @@ -94,9 +100,9 @@ <programlisting role="JAVA">@Inject BeanManager beanManager</programlisting> <para> - Java EE components may obtain an instance of BeanManager from JNDI by looking up the name - <literal>java:comp/BeanManager</literal>. Any operation of BeanManager may be called at any time during the - execution of the application. + Java EE components may obtain an instance of <literal>BeanManager</literal> from JNDI by looking up the name + <literal>java:comp/BeanManager</literal>. Any operation of <literal>BeanManager</literal> may be called at any + time during the execution of the application. </para> <para>Let's study some of the interfaces exposed by the <literal>BeanManager</literal>.</para> @@ -104,7 +110,7 @@ </section> <section> - <title>The <literal>Bean</literal> class</title> + <title>The <literal>Bean</literal> interface</title> <para> Instances of the interface <literal>Bean</literal> represent beans. There is an instance of @@ -112,7 +118,7 @@ application. </para> - <programlisting role="JAVA"><![CDATA[public interface class Bean<T> extends Contextual<T> { + <programlisting role="JAVA"><![CDATA[public interface Bean<T> extends Contextual<T> { public Set<Type> getTypes(); public Set<Annotation> getQualifiers(); public Class<? extends Annotation> getScope();

14 years, 8 months

1
0
0 / 0

Weld SVN: r4927 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 21:23:12 -0500 (Mon, 09 Nov 2009) New Revision: 4927 Modified: doc/trunk/reference/en-US/decorators.xml doc/trunk/reference/en-US/interceptors.xml Log: revisions Modified: doc/trunk/reference/en-US/decorators.xml =================================================================== --- doc/trunk/reference/en-US/decorators.xml 2009-11-10 02:01:50 UTC (rev 4926) +++ doc/trunk/reference/en-US/decorators.xml 2009-11-10 02:23:12 UTC (rev 4927) @@ -17,8 +17,8 @@ interface, and is therefore aware of all the semantics attached to that interface. Since decorators directly implement operations with business semantics, it makes them the perfect tool for modeling some kinds of business concerns. It also means that a decorator doesn't have the generality of an interceptor. Decorators aren't able to - solve technical concerns that cut across many disparate types. The two complement one another. Let's look at some - cases where decorators fit the bill. + solve technical concerns that cut across many disparate types. Interceptors and decorators, though similar in many + ways, are complementary. Let's look at some cases where decorators fit the bill. </para> <para>Suppose we have an interface that represents accounts:</para> Modified: doc/trunk/reference/en-US/interceptors.xml =================================================================== --- doc/trunk/reference/en-US/interceptors.xml 2009-11-10 02:01:50 UTC (rev 4926) +++ doc/trunk/reference/en-US/interceptors.xml 2009-11-10 02:23:12 UTC (rev 4927) @@ -5,20 +5,13 @@ <title>Interceptors</title> <para> - Thanks to the managed bean specification, interceptors are now part of the core functionality of a bean. That - means that you no longer need to make your class an EJB just to use interceptors! + Interceptor functionality is defined in the Java Interceptors specification. CDI enhances this functionality with + a more sophisticated, semantic, annotation-based approach to binding interceptors to beans. </para> <para> - But that doesn't mean there aren't other improvements that can be made. CDI builds on the interceptor architecture - of managed beans by introducing a more sophisticated, semantic, annotation-based approach to binding interceptors - to beans. + The Interceptors specification defines two kinds of interception points: </para> - - <para> - Interceptor functionality is defined in the interceptor specification, which the managed bean, CDI, and EJB - specifications all support. The interceptor specification defines two kinds of interception points: - </para> <itemizedlist> <listitem> @@ -30,12 +23,17 @@ </itemizedlist> <para> + In addition, the EJB specification defines timeout method interception. + </para> + + <para> A <emphasis>business method interceptor</emphasis> applies to invocations of methods of the bean by clients of the bean: </para> <programlisting role="JAVA"><![CDATA[public class TransactionInterceptor { - @AroundInvoke public Object manageTransaction(InvocationContext ctx) throws Exception { ... } + @AroundInvoke + public Object manageTransaction(InvocationContext ctx) throws Exception { ... } }]]></programlisting> <para> @@ -44,19 +42,30 @@ </para> <programlisting role="JAVA"><![CDATA[public class DependencyInjectionInterceptor { - @PostConstruct public void injectDependencies(InvocationContext ctx) { ... } + @PostConstruct + public void injectDependencies(InvocationContext ctx) { ... } }]]></programlisting> <para> An interceptor class may intercept both lifecycle callbacks and business methods. </para> + + <para> + A <emphasis>timeout method interceptor</emphasis> applies to invocations of EJB timeout methods by the + container: + </para> + <programlisting role="JAVA"><![CDATA[public class TimeoutInterceptor { + @AroundTimeout + public Object manageTransaction(InvocationContext ctx) throws Exception { ... } +}]]></programlisting> + <section> <title>Interceptor bindings</title> <para> Suppose we want to declare that some of our beans are transactional. The first thing we need is an - <emphasis>interceptor binding annotation</emphasis> to specify exactly which beans we're interested in: + <emphasis>interceptor binding type</emphasis> to specify exactly which beans we're interested in: </para> <programlisting role="JAVA"><![CDATA[@InterceptorBinding @@ -92,20 +101,21 @@ <programlisting role="JAVA"><![CDATA[@Transactional @Interceptor public class TransactionInterceptor { - @AroundInvoke public Object manageTransaction(InvocationContext ctx) throws Exception { ... } + @AroundInvoke + public Object manageTransaction(InvocationContext ctx) throws Exception { ... } }]]></programlisting> <para> - All bean interceptors are beans, and can take advantage of dependency injection and contextual lifecycle - management. + Interceptors can take advantage of dependency injection: </para> - <programlisting role="JAVA"><![CDATA[@ApplicationScoped @Transactional @Interceptor + <programlisting role="JAVA"><![CDATA[@Transactional @Interceptor public class TransactionInterceptor { - @Resource Transaction transaction; + @Inject UserTransaction transaction; - @AroundInvoke public Object manageTransaction(InvocationContext ctx) throws Exception { ... } + @AroundInvoke + public Object manageTransaction(InvocationContext ctx) throws Exception { ... } }]]></programlisting> @@ -169,7 +179,8 @@ </interceptors> </beans>]]></programlisting> - <para>Or we could turn them both off in our test environment by simply taking no action! Ah, so simple.</para> + <para>Or we could turn them both off in our test environment by simply not mentioning them in + <literal>beans.xml</literal>! Ah, so simple.</para> </section> @@ -194,7 +205,8 @@ <programlisting role="JAVA"><![CDATA[@Transactional(requiresNew = true) @Interceptor public class RequiresNewTransactionInterceptor { - @AroundInvoke public Object manageTransaction(InvocationContext ctx) throws Exception { ... } + @AroundInvoke + public Object manageTransaction(InvocationContext ctx) throws Exception { ... } }]]></programlisting> <para>

14 years, 8 months

1
0
0 / 0

Weld SVN: r4926 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 21:01:50 -0500 (Mon, 09 Nov 2009) New Revision: 4926 Modified: doc/trunk/reference/en-US/part2.xml Log: minor Modified: doc/trunk/reference/en-US/part2.xml =================================================================== --- doc/trunk/reference/en-US/part2.xml 2009-11-10 01:58:49 UTC (rev 4925) +++ doc/trunk/reference/en-US/part2.xml 2009-11-10 02:01:50 UTC (rev 4926) @@ -26,8 +26,8 @@ <para> These techniques serve to enable loose coupling of client and server. The client is no longer tightly bound to an - implementation of an API, nor is it required to manage the lifecycle of the server object. This approach lets - <emphasis>stateful objects interact as if they were services</emphasis>. + implementation of an interface, nor is it required to manage the lifecycle of the implementation. This approach + lets <emphasis>stateful objects interact as if they were services</emphasis>. </para> <para>

14 years, 8 months

1
0
0 / 0

Weld SVN: r4925 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 20:58:49 -0500 (Mon, 09 Nov 2009) New Revision: 4925 Modified: doc/trunk/reference/en-US/producermethods.xml Log: minor Modified: doc/trunk/reference/en-US/producermethods.xml =================================================================== --- doc/trunk/reference/en-US/producermethods.xml 2009-11-10 01:55:19 UTC (rev 4924) +++ doc/trunk/reference/en-US/producermethods.xml 2009-11-10 01:58:49 UTC (rev 4925) @@ -120,7 +120,7 @@ </para> <para> - If this isn't what we want we can use dependency injection into the producer method to obtain bean + If this isn't what we want, we can use dependency injection into the producer method to obtain bean instances: </para>

14 years, 8 months

1
0
0 / 0

Weld SVN: r4924 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 20:55:19 -0500 (Mon, 09 Nov 2009) New Revision: 4924 Modified: doc/trunk/reference/en-US/scopescontexts.xml Log: better Modified: doc/trunk/reference/en-US/scopescontexts.xml =================================================================== --- doc/trunk/reference/en-US/scopescontexts.xml 2009-11-10 01:49:00 UTC (rev 4923) +++ doc/trunk/reference/en-US/scopescontexts.xml 2009-11-10 01:55:19 UTC (rev 4924) @@ -312,20 +312,15 @@ <title>The <literal>@New</literal> qualifier</title> <para> - The built-in <literal>@New</literal> qualifier annotation allows <emphasis>implicit</emphasis> definition of - a dependent bean at an injection point. Suppose we declare the following injected field: + The built-in qualifier <literal>@New</literal> allows us to obtain a dependent object of a specified class. </para> <programlisting role="JAVA"><![CDATA[@Inject @New Calculator calculator;]]></programlisting> - + + <para>The class must be a valid managed bean or session bean, but need not be an enabled bean.</para> + <para> - Then a bean with scope <literal>@Dependent</literal>, qualifier type <literal>@New</literal>, API type - <literal>Calculator</literal>, implementation class <literal>Calculator</literal> and deployment type - <literal>@Standard</literal> is implicitly defined. - </para> - - <para> - This is true even if <literal>Calculator</literal> is <emphasis>already</emphasis> declared with a different + This works even if <literal>Calculator</literal> is <emphasis>already</emphasis> declared with a different scope type, for example: </para>

14 years, 8 months

1
0
0 / 0

Weld SVN: r4923 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 20:49:00 -0500 (Mon, 09 Nov 2009) New Revision: 4923 Modified: doc/trunk/reference/en-US/scopescontexts.xml Log: various revisions Modified: doc/trunk/reference/en-US/scopescontexts.xml =================================================================== --- doc/trunk/reference/en-US/scopescontexts.xml 2009-11-10 01:48:46 UTC (rev 4922) +++ doc/trunk/reference/en-US/scopescontexts.xml 2009-11-10 01:49:00 UTC (rev 4923) @@ -33,8 +33,7 @@ <note> <para> - There's actually no way to remove a bean from a context explicitly. It turns out that's a good thing because - there is no confusion as to which instance you are getting. + There's actually no way to remove a bean from a context until the entire context is destroyed. </para> </note> @@ -103,7 +102,7 @@ </itemizedlist> <note> - <para>A CDI extension can support the conversation for other frameworks as well.</para> + <para>A CDI extension can support the conversation scope for other frameworks as well.</para> </note> <para>The request and application scopes are also active:</para> @@ -151,7 +150,7 @@ <listitem> <para> holds state associated with a particular web browser tab in a JSF application (browsers tend to share - domain cookies, and hence the session cookie, between tabs, which is the root of the issue). + domain cookies, and hence the session cookie, between tabs, so this is not the case for the session scope). </para> </listitem> </itemizedlist> @@ -221,14 +220,15 @@ This bean is able to control its own lifecycle through use of the <literal>Conversation</literal> API. But some other beans have a lifecycle which depends completely upon another object. </para> + </section> <section> <title>Conversation propagation</title> <para> - The conversation context automatically propagates with any JSF faces request (JSF form submission). It does - not automatically propagate with non-faces requests, for example, navigation via a link. + The conversation context automatically propagates with any JSF faces request (JSF form submission) or redirect. + It does not automatically propagate with non-faces requests, for example, navigation via a link. </para> <para> @@ -245,19 +245,20 @@ <programlisting role="HTML"><![CDATA[<a href="/addProduct.jsp?cid=#{conversation.id}">Add Product</a>]]></programlisting> <para> - Though it's probably better to use one of the link components in JSF 2: + It's probably better to use one of the link components in JSF 2: </para> <programlisting role="HTML"><![CDATA[<h:link outcome="/addProduct.xhtml value="Add Product"> <f:param name="cid" value="#{conversation.id}"/> </h:link>]]></programlisting> - + + <tip> <para> - The container is also required to propagate conversations across any redirect, even if the conversation is - not marked long-running. This makes it very easy to implement the common POST-then-redirect pattern, without - resort to fragile constructs such as a "flash" object. In this case, the container automatically adds a - request parameter to the redirect URL. + The conversation context propagates across redirects, making it very easy to implement the common + POST-then-redirect pattern, without resort to fragile constructs such as a "flash" object. The container + automatically adds the conversation id to the redirect URL as a request parameter. </para> + </tip> </section> @@ -266,8 +267,8 @@ <para> The container is permitted to destroy a conversation and all state held in its context at any time in order - to preserve resources. A CDI implementation will normally do this on the basis of some kind of timeout - — though this is not required by the CDI specification. The timeout is the period of inactivity before + to conserve resources. A CDI implementation will normally do this on the basis of some kind of + timeout—though this is not required by the specification. The timeout is the period of inactivity before the conversation is destroyed (as opposed to the amount of time the conversation is active). </para> @@ -286,8 +287,8 @@ <title>The dependent pseudo-scope</title> <para> - In addition to the four built-in scopes, CDI features the so-called <emphasis>dependent - pseudo-scope</emphasis>. This is the default scope for a bean which does not explicitly declare a scope type. + In addition to the four built-in scopes, CDI features the so-called <emphasis>dependent pseudo-scope</emphasis>. + This is the default scope for a bean which does not explicitly declare a scope type. </para> <para> @@ -297,15 +298,10 @@ <programlisting role="JAVA"><![CDATA[public class Calculator { ... }]]></programlisting> <para> - When an injection point of a bean resolves to a dependent bean, a new instance of the dependent bean is created - when the bean into which it's being injected is instantiated. Instances of dependent beans are never shared - between different beans or different injection points. They are strictly <emphasis>dependent objects</emphasis> - of some other bean instance. + An instances of a dependent bean is never shared between different clients or different injection points. It is + strictly a <emphasis>dependent object</emphasis> of some other object. It is instantiated when the object it + belongs to is created, and destroyed when the object it belongs to is destroyed. </para> - - <para> - Dependent bean instances are destroyed when the instance they depend upon is destroyed. - </para> <para> CDI makes it easy to obtain a dependent instance of a bean, even if the bean is already declared as a bean with @@ -313,7 +309,7 @@ </para> <section> - <title>The <literal>@New</literal> annotation</title> + <title>The <literal>@New</literal> qualifier</title> <para> The built-in <literal>@New</literal> qualifier annotation allows <emphasis>implicit</emphasis> definition of

14 years, 8 months

1
0
0 / 0

Weld SVN: r4922 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 20:48:46 -0500 (Mon, 09 Nov 2009) New Revision: 4922 Modified: doc/trunk/reference/en-US/intro.xml Log: little note about callbacks Modified: doc/trunk/reference/en-US/intro.xml =================================================================== --- doc/trunk/reference/en-US/intro.xml 2009-11-10 01:48:31 UTC (rev 4921) +++ doc/trunk/reference/en-US/intro.xml 2009-11-10 01:48:46 UTC (rev 4922) @@ -717,6 +717,9 @@ interfaces it implements directly or indirectly.</para> <para>If a managed bean has a public field, it must have the default scope <literal>@Dependent</literal>.</para> + + <para>Managed beans support the <literal>@PostConstruct</literal> and <literal>@PreDestroy</literal> lifecycle + callbacks.</para> <para> Session beans are also, technically, managed beans. However, since they have their own special lifecycle and

14 years, 8 months

1
0
0 / 0

Weld SVN: r4921 - doc/trunk/reference/en-US.

by weld-commits＠lists.jboss.org

Author: gavin.king(a)jboss.com Date: 2009-11-09 20:48:31 -0500 (Mon, 09 Nov 2009) New Revision: 4921 Modified: doc/trunk/reference/en-US/injection.xml Log: reinstate missing section delete waffle Modified: doc/trunk/reference/en-US/injection.xml =================================================================== --- doc/trunk/reference/en-US/injection.xml 2009-11-10 00:14:11 UTC (rev 4920) +++ doc/trunk/reference/en-US/injection.xml 2009-11-10 01:48:31 UTC (rev 4921) @@ -100,7 +100,7 @@ </listitem> <listitem> <para> - Finally, the <literal>@PostConstruct</literal> method of the bean is called, if defined. + Finally, the <literal>@PostConstruct</literal> method, if any, is called. </para> </listitem> </itemizedlist> @@ -526,42 +526,43 @@ <programlisting role="JAVA"><![CDATA[PaymentProcessor p = paymentProcessorSource.get();]]></programlisting> <para> - Of course, qualifiers can be specified at the injection point: + Qualifiers can be specified at the injection point: </para> <programlisting role="JAVA"><![CDATA[@Inject @Asynchronous Instance<PaymentProcessor> paymentProcessorSource;]]></programlisting> <para> Alternatively, we can specify the qualifier dynamically. First, we add the <literal>@Any</literal> qualifier to - the injection point: + the injection point, to suppress the default qualifier. (All beans have the qualifier <literal>@Any</literal>.) </para> <programlisting role="JAVA"><![CDATA[@Inject @Any Instance<PaymentProcessor> paymentProcessorSource;]]></programlisting> <para> - Now we can pass the qualifier to the <literal>select()</literal> method of <literal>Instance</literal>. We can - obtain a qualifier instance by subclassing the helper class <literal>AnnotationLiteral</literal>, since it's - otherwise difficult to instantiate an annotation type in Java. + Next, we need to obtain an instance of our qualifier type. Since annotatons are interfaces, we can't just write + <literal>new Asynchronous()</literal>. It's also quite tedious to create a concrete implementation of an annotation + type from scratch. Instead, CDI lets us obtain a qualifier instance by subclassing the helper class + <literal>AnnotationLiteral</literal>. </para> - - <programlisting role="JAVA"><![CDATA[PaymentProcessor p = paymentProcessorSource - .select(new AnnotationLiteral<Asynchronous>() {});]]></programlisting> + + <programlisting role="JAVA"><![CDATA[abstract class AsynchronousQualifier +extends AnnotationLiteral<Asynchronous> implements Asynchronous {}]]></programlisting> <para> - We can choose to create a concrete type for the annotation literal: + In some cases, we can use an anonymous class: </para> - <programlisting role="JAVA"><![CDATA[abstract class AsynchronousQualifier -extends AnnotationLiteral<Asynchronous> implements Asynchronous {}]]></programlisting> - + <programlisting role="JAVA"><![CDATA[PaymentProcessor p = paymentProcessorSource + .select(new AnnotationLiteral<Asynchronous>() {});]]></programlisting> + <note> <para> - The concrete type is required if the qualifier has members. + We can't use an anonymous class to implement a qualifier type with members. </para> </note> <para> - Here's how you might make use of dynamic selection: + Now, finally, we can pass the qualifier to the <literal>select()</literal> method of <literal>Instance</literal>. </para> <programlisting><![CDATA[Annotation qualifier = synchronously ? @@ -570,69 +571,94 @@ </section> -  + @Produces Logger createLogger(InjectionPoint injectionPoint) { + return Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName()); + } - <section> - <title>Lifecycle callbacks and component environment injection</title> +}]]></programlisting> - <para> - Managed beans and EJB beans support the lifecycle callback methods <literal>@PostConstruct</literal> and - <literal>@PreDestroy</literal> which are called after after all dependencies have been injected, and before the - bean is destroyed (when the context to which it belongs ends), respectively. EJB beans also support the EJB - callback methods <literal>@PrePassivate</literal> and <literal>@PostActivate</literal>. - </para> + <para>We can now write:</para> - <para> - Managed beans and EJB beans also support Java EE 5-style component environment injection, where the injection - point is declared using <literal>@Resource</literal>, <literal>@PersistenceContext</literal>, - <literal>@PersistenceUnit</literal>, <literal>@WebServiceRef</literal> or <literal>@EJB</literal>. However, in - a CDI environment, these annotations are most useful for declaring resources that can be injected by CDI. - </para> +<programlisting role="JAVA"><![CDATA[@Inject Logger log;]]></programlisting> - </section> + <para>Not convinced? Then here's a second example. To inject HTTP parameters, we need to define + a qualifier type:</para> +<programlisting role="JAVA"><![CDATA[@BindingType +@Retention(RUNTIME) +@Target({TYPE, METHOD, FIELD, PARAMETER}) +public @interface HttpParam { + @NonBinding public String value(); +}]]></programlisting> + + <para>We would use this qualifier type at injection points as follows:</para> + +<programlisting role="JAVA"><![CDATA[@HttpParam("username") String username; +@HttpParam("password") String password;]]></programlisting> + + <para>The following producer method does the work:</para> + +<programlisting role="JAVA"><![CDATA[class HttpParams + + @Produces @HttpParam("") + String getParamValue(ServletRequest request, InjectionPoint ip) { + return request.getParameter(ip.getAnnotation(HttpParam.class).value()); + } + +}]]></programlisting> + + <para>(Note that the <literal>value()</literal> member of the <literal>HttpParam</literal> + annotation is ignored by the container since it is annotated <literal>@NonBinding.</literal>)</para> + + <para>The container provides a built-in bean that implements the <literal>InjectionPoint</literal> + interface:</para> + +<programlisting role="JAVA"><![CDATA[public interface InjectionPoint { + public Object getInstance(); + public Bean<?> getBean(); + public Member getMember(): + public <T extends Annotation> T getAnnotation(Class<T> annotation); + public Set<T extends Annotation> getAnnotations(); +}]]></programlisting> + +</section> +

14 years, 8 months

1
0
0 / 0

Weld SVN: r4920 - build/trunk/dist-jcp.

by weld-commits＠lists.jboss.org

Author: pete.muir(a)jboss.org Date: 2009-11-09 19:14:11 -0500 (Mon, 09 Nov 2009) New Revision: 4920 Modified: build/trunk/dist-jcp/pom.xml build/trunk/dist-jcp/readme.txt Log: jcp build Modified: build/trunk/dist-jcp/pom.xml =================================================================== --- build/trunk/dist-jcp/pom.xml 2009-11-09 23:50:03 UTC (rev 4919) +++ build/trunk/dist-jcp/pom.xml 2009-11-10 00:14:11 UTC (rev 4920) @@ -1,16 +1,103 @@ -<?xml version="1.0"?> -<project xmlns="http://maven.apache.org/POM/4.0.0" - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> +<?xml version="1.0" encoding="UTF-8"?> +<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> + <modelVersion>4.0.0</modelVersion> <parent> + <groupId>org.jboss.weld</groupId> <artifactId>weld-parent</artifactId> - <groupId>org.jboss.weld</groupId> - <version>1.0.0-SNAPSHOT</version> + <version>6</version> </parent> - <modelVersion>4.0.0</modelVersion> <groupId>org.jboss.weld</groupId> - <artifactId>weld-distribution</artifactId> - <packaging>zip</packaging> - <name>Weld Distribution</name> + <artifactId>weld-jcp-dist</artifactId> + <version>1.0.0</version> + <packaging>pom</packaging> + <name>Weld (JCP) Distribution</name> + + <dependencies> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-core</artifactId> + <version>${weld.version}</version> + <optional>true</optional> + </dependency> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-core</artifactId> + <version>${weld.version}</version> + <optional>true</optional> + <classifier>javadoc</classifier> + </dependency> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-core</artifactId> + <version>${weld.version}</version> + <optional>true</optional> + <classifier>sources</classifier> + </dependency> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-spi</artifactId> + <version>${weld.api.version}</version> + <optional>true</optional> + <classifier>sources</classifier> + </dependency> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-api</artifactId> + <version>${weld.api.version}</version> + <optional>true</optional> + <classifier>sources</classifier> + </dependency> + <dependency> + <groupId>javax.enterprise</groupId> + <artifactId>cdi-api</artifactId> + <version>${weld.api.version}</version> + <optional>true</optional> + <classifier>sources</classifier> + </dependency> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-spi</artifactId> + <version>${weld.api.version}</version> + <optional>true</optional> + <classifier>javadoc</classifier> + </dependency> + <dependency> + <groupId>org.jboss.weld</groupId> + <artifactId>weld-api</artifactId> + <version>${weld.api.version}</version> + <optional>true</optional> + <classifier>javadoc</classifier> + </dependency> + <dependency> + <groupId>javax.enterprise</groupId> + <artifactId>cdi-api</artifactId> + <version>${weld.api.version}</version> + <optional>true</optional> + <classifier>javadoc</classifier> + </dependency> + </dependencies> + + <build> + <plugins> + <plugin> + <artifactId>maven-assembly-plugin</artifactId> + <configuration> + <descriptors> + <descriptor>assembly.xml</descriptor> + </descriptors> + <finalName>weld-${weld.version}</finalName> + </configuration> + <executions> + <execution> + <id>make-assembly</id> + <phase>package</phase> + <goals> + <goal>single</goal> + </goals> + </execution> + </executions> + </plugin> + </plugins> + </build> </project> Modified: build/trunk/dist-jcp/readme.txt =================================================================== --- build/trunk/dist-jcp/readme.txt 2009-11-09 23:50:03 UTC (rev 4919) +++ build/trunk/dist-jcp/readme.txt 2009-11-10 00:14:11 UTC (rev 4920) @@ -1,5 +1,5 @@ - Weld + JSR-299: Contexts and Dependency Injection RI What is it? ============ @@ -11,49 +11,16 @@ Status ======= - This is a preproduction release of Weld. + This is a production release of Weld. - System requirements - =================== - - Weld examples require either a Java EE 6 application server, a Java EE 5 - application server retrofitted to include CDI support, a servlet container - (using the Weld servlet extension) and Java SE (using the Weld Java SE - extension). In fact, through extensions, Weld can accomodate any Java - environment. - - Currently, you must use JBoss AS 5.2.0.Beta1 (use nightly builds until - released) or above deploy the provided examples out of the box. Marked - examples, which do not include EJB session beans, can also be deployed to - Apache Tomcat 6 or Jetty 6. Other application servers may be supported by - the examples in the 1.0.0 release. - - JDK 5.0 or JDK 6.0 is required for all Weld releases. - Contents of distribution ======================== - - doc/ - - API Docs and reference guide. Open doc/en-US/html/index.html in your - browser for instructions on how to get started using Weld and the - facilities offered by JSR-299. - - examples/ - - The Weld examples, the examples are described in more detail in the - reference guide - - jboss-as/ - - Installer for JBoss AS, change into this directory, and run ant update - There are more details in the reference guide lib/ - Libraries, for building the examples + Weld dependencies - lib/weld + artifacts/ Weld binary, source and javadoc jars @@ -71,6 +38,4 @@ Mailing Lists: https://lists.jboss.org/mailman/listinfo/weld-dev Source Code: http://anonsvn.jboss.org/repos/weld Issue Tracking: https://jira.jboss.org/jira/browse/WELD (core) - https://jira.jboss.org/jira/browse/WELDX (extensions) - https://jira.jboss.org/jira/browse/WELDINT (JBoss AS integration)

14 years, 8 months

1
0
0 / 0

Weld SVN: r4919 - build/trunk.

by weld-commits＠lists.jboss.org

Author: pete.muir(a)jboss.org Date: 2009-11-09 18:50:03 -0500 (Mon, 09 Nov 2009) New Revision: 4919 Added: build/trunk/dist-jcp/ Log: copy dist to create dist for jcp Copied: build/trunk/dist-jcp (from rev 4918, build/trunk/dist)

14 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-commits November 2009