Return-Path: X-Original-To: apmail-deltaspike-commits-archive@www.apache.org Delivered-To: apmail-deltaspike-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C2F3217DF2 for ; Thu, 23 Oct 2014 13:01:12 +0000 (UTC) Received: (qmail 80452 invoked by uid 500); 23 Oct 2014 13:01:12 -0000 Delivered-To: apmail-deltaspike-commits-archive@deltaspike.apache.org Received: (qmail 80421 invoked by uid 500); 23 Oct 2014 13:01:12 -0000 Mailing-List: contact commits-help@deltaspike.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@deltaspike.apache.org Delivered-To: mailing list commits@deltaspike.apache.org Received: (qmail 80412 invoked by uid 99); 23 Oct 2014 13:01:12 -0000 Received: from mx1-us-east.apache.org (HELO mx1-us-east.apache.org) (54.164.171.186) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Oct 2014 13:01:12 +0000 Received: from mx1-us-east.apache.org (localhost [127.0.0.1]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id 113654354D for ; Thu, 23 Oct 2014 13:01:12 +0000 (UTC) Received: by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org, from userid 111) id 05A5C43858; Thu, 23 Oct 2014 13:01:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx1-us-east.apache.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from eris.apache.org (eris.apache.org [140.211.11.4]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id B071B43865 for ; Thu, 23 Oct 2014 13:01:08 +0000 (UTC) Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 808F32388C27; Thu, 23 Oct 2014 13:00:37 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r1633803 [9/10] - in /deltaspike/site/trunk/content/documentation/staging: ./ releasenotes/ Date: Thu, 23 Oct 2014 13:00:34 -0000 To: commits@deltaspike.apache.org From: rafabene@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20141023130037.808F32388C27@eris.apache.org> X-Virus-Scanned: ClamAV using ClamSMTP Added: deltaspike/site/trunk/content/documentation/staging/security.html URL: http://svn.apache.org/viewvc/deltaspike/site/trunk/content/documentation/staging/security.html?rev=1633803&view=auto ============================================================================== --- deltaspike/site/trunk/content/documentation/staging/security.html (added) +++ deltaspike/site/trunk/content/documentation/staging/security.html Thu Oct 23 13:00:33 2014 @@ -0,0 +1,815 @@ + + + + + + + + + +DeltaSpike Security Module + + + + + + + + + + + + + + + + +

DeltaSpike Security Module

+ +

Hint
SecurityBinding for class and method invocations
Integrating 3rd party security frameworks +
+
Making intitially requested and secured page available for redirect after login +
- CDI Implementation to redirect the login to the first denied page
- PicketLink Implementation to redirect the login to the first denied page
+
AccessDecisionVoterContext +
- SecurityStrategy SPI
+

+ +

Hint

If you are using features described by this page and the CDI +container you are using is Weld (or OpenWebBeans in BDA mode), you have +to enable the security interceptor in your beans.xml file:

<beans>
+    <interceptors>
+        <class>org.apache.deltaspike.security.impl.extension.SecurityInterceptor</class>
+    </interceptors>
+</beans>

SecurityBinding for class and method invocations

This feature of the security module functions by intercepting method +calls, and performing a security check before invocation is allowed to +proceed.

In order to use the DeltaSpike security module, you must first have +installed the proper dependencies into your POM file. Once this is +complete, you may proceed to create a security parameter binding +annotation. This is what we will use to add security behavior to our +business classes and methods.

Create the SecurityBinding:

@Retention(value = RUNTIME)
+@Target({TYPE, METHOD})
+@Documented
+@SecurityBindingType
+public @interface CustomSecurityBinding {
+}

Next, we must define an Authorizer class to implement behavior for our +custom SecurityBindingType. This class is simply a CDI bean which +declares a @Secures method, qualified with the security binding +annotation we created in the first step.

This method has access to the InvocationContext of the method call, so +if we need to access parameter arguments, we can do so using the given +context. Note that we may also inject other beans into the parameter +list of our @Secures method.

Create the Authorizer:

@ApplicationScoped
+public class CustomAuthorizer
+{
+    @Secures
+    @CustomSecurityBinding
+    public boolean doSecuredCheck(InvocationContext invocationContext, BeanManager manager, @LoggedIn User user) throws Exception
+    {
+        return user.isLoggedIn(); // perform security check
+    }
+}

We can then use our new annotation to secure business or bean methods. +This binding annotation may be placed on the entire class (securing all +methods,) or on individual methods that you wish to secure.

Secure a bean method:

@ApplicationScoped
+public class SecuredBean1
+{
+    @CustomSecurityBinding
+    public void doSomething(Thing thing)
+    {
+        thing.doSomething();
+    }
+}

Next, we may access parameter values from the method invocation directly +in our authorizer bean by creating custom @SecurityParameterBinding +types; this is a simple step once we have completed the work above:

Create a parameter binding annotation:

@Retention(value = RUNTIME)
+@Target({PARAMETER})
+@Documented
+@SecurityParameterBinding
+public @interface CurrentThing {
+}

Now, when a secured method is invoked, we can inject actual parameter +values as arguments into our authorizer method, providing domain-level +security in our applications:

Update the Authorizer to use parameter binding:

@ApplicationScoped
+public class CustomAuthorizer
+{
+    @Secures
+    @CustomSecurityBinding
+    public boolean doSecuredCheck(InvocationContext invocationContext, BeanManager manager, @LoggedIn User user, @CurrentThing Thing thing) throws Exception
+    {
+        return thing.hasMember(user); // perform security check against our method parameter
+    }
+}

Note that our business method must also be annotated.

Complete the parameter binding:

@ApplicationScoped
+public class SecuredBean1
+{
+    @CustomSecurityBinding
+    public void doSomething(@CurrentThing Thing thing)
+    {
+        thing.doSomething();
+    }
+}

Our method is now secured, and we are able to use given parameter values +as part of our security authorizer!

There may be cases where you may want to base your authorization logic +on the result of the secured method and do the security check after the +method invocation. Just use the same security binding type for that +case:

@ApplicationScoped
+public class SecuredBean1
+{
+    @CustomSecurityBinding
+    public Thing loadSomething()
+    {
+        return thingLoader.load();
+    }
+}

Now you need to access the return value in the authorizer method. You +can inject it using the @SecuredReturn annotation. Update the Authorizer +to use a secured return value:

@ApplicationScoped
+public class CustomAuthorizer
+{
+    @Secures
+    @CustomSecurityBinding
+    public boolean doSecuredCheck(@SecuredReturn Thing thing, @LoggedIn User user) throws Exception
+    {
+        return thing.hasMember(user); // perform security check against the return value
+}

Now the authorization will take place after the method invocation using +the return value of the business method.

Complete the parameter binding:

@ApplicationScoped
+public class SecuredBean1
+{
+    @CustomSecurityBinding
+    public void doSomething(@CurrentThing Thing thing)
+    {
+        thing.doSomething();
+    }
+}

Our method is now secured, and we are able to use given parameter values +as part of our security authorizer!

Integrating 3rd party security frameworks

@Secured

@Secured is build on @SecurityBindingType and a very simple +alternative to the rest of the security module. It’s a basic hook to +integrate a custom security concept, 3rd party frameworks,… . It +doesn’t provide a full blown security concept like the rest of the +security module, but other DeltaSpike modules ensure that the security +concepts are integrated properly (e.g. correct behaviour within custom +scope implementations,…). It just allows to integrate other security +frameworks easily.

(In MyFaces CODI it was originally a CDI interceptor. This part changed +a bit, because between the interceptor and @Secured is the +@SecurityBindingType concept which triggers @Secured as on possible +approach. Therefore the basic behaviour remains the same and you can +think about it like an interceptor.)

Securing all intercepted methods of a CDI bean:

//...
+@Secured(CustomAccessDecisionVoter.class)
+public class SecuredBean
+{
+    //...
+}

Securing specific methods:

//...
+public class SecuredBean
+{
+    @Secured(CustomAccessDecisionVoter.class)
+    public String getResult()
+    {
+        //...
+    }
+}

AccessDecisionVoter

This interface is (besides the Secured annotation) the most important +part of the concept. Both artifact types are also the only required +parts:

public class CustomAccessDecisionVoter implements AccessDecisionVoter
+{
+    @Override
+    public Set<SecurityViolation> checkPermission(AccessDecisionVoterContext accessDecisionVoterContext)
+    {
+        Method method = accessDecisionVoterContext.<InvocationContext>getSource().getMethod();
+
+        //...
+    }
+}

[TODO] hint about the changed parameter/s

SecurityViolation

In case of a detected violation a SecurityViolation has to be added to +the result returned by the AccessDecisionVoter.

AbstractAccessDecisionVoter

You can also implement the abstract class AbstractAccessDecisionVoter. +This is a convenience class which allows an easier usage:

public class CustomAccessDecisionVoter extends AbstractAccessDecisionVoter
+{
+
+    @Override
+    protected void checkPermission(AccessDecisionVoterContext accessDecisionVoterContext,
+            Set<SecurityViolation> violations)
+    {
+        // check for violations
+        violations.add(newSecurityViolation("access not allowed due to ..."));
+    }
+}

@Secured and Stereotypes with custom Meta-data

If there are multiple AccessDecisionVoter and maybe in different +constellations, it’s easier to provide an expressive CDI stereotypes for +it. Later on that also allows to change the behaviour in a central +place.

Stereotype support of @Secured:

@Named
+@Admin
+public class MyBean implements Serializable
+{
+  //...
+}
+
+//...
+@Stereotype
+@Secured(RoleAccessDecisionVoter.class)
+public @interface Admin
+{
+}

Furthermore, it’s possible to provide custom meta-data easily.

Stereotype of @Secured with custom meta-data:

@Named
+@Admin(securityLevel=3)
+public class MyBean implements Serializable
+{
+  //...
+}
+
+//...
+@Stereotype
+@Secured(RoleAccessDecisionVoter.class)
+public @interface Admin
+{
+  int securityLevel();
+}
+
+@ApplicationScoped
+public class RoleAccessDecisionVoter implements AccessDecisionVoter
+{
+    private static final long serialVersionUID = -8007511215776345835L;
+
+    public Set<SecurityViolation> checkPermission(AccessDecisionVoterContext voterContext)
+    {
+        Admin admin = voterContext.getMetaDataFor(Admin.class.getName(), Admin.class);
+        int level = admin.securityLevel();
+        //...
+    }
+}

Making intitially requested and secured page available for redirect after login

DeltaSpike can be combined with pure CDI or with any other security +frameworks (like PicketLink) to track the denied page and make it +available after user logs in.

CDI Implementation to redirect the login to the first denied page

Your LoginService will fire a custom UserLoggedInEvent

public class LoginService implements Serializable {
+
+    @Inject
+    private Event<UserLoggedInEvent> userLoggedInEvent;
+
+    public Usuario login(String username, char[] password) {
+        //do the loggin process
+        userLoggedInEvent.fire(new UserLoggedInEvent());
+    }
+
+}

Use @SessionScoped or @WindowScoped for AdminAccessDecisionVoter and +store the denied page on your own.

@SessionScoped //or @WindowScoped
+public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
+
+    @Inject
+    private ViewConfigResolver viewConfigResolver;
+
+    private Class<? extends ViewConfig> deniedPage = Pages.Home.class;
+
+    @Override
+    protected void checkPermission(AccessDecisionVoterContext context, Set<SecurityViolation> violations) {
+        if(loggedIn) {
+            //...
+        } else {
+            violations.add(/*...*/);
+            deniedPage = viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
+        }
+    }
+
+    public Class<? extends ViewConfig> getDeniedPage() {
+        try {
+            return deniedPage;
+        } finally {
+            deniedPage = Pages.Home.class;
+        }
+    }
+}

And in AuthenticationListener you inject AdminAccessDecisionVoter

public class AuthenticationListener {
+
+    @Inject
+    private ViewNavigationHandler viewNavigationHandler;
+
+    @Inject
+    private AdminAccessDecisionVoter adminAccessDecisionVoter;
+
+    public void handleLoggedIn(@Observes UserLoggedInEvent event) {
+        this.viewNavigationHandler.navigateTo(adminAccessDecisionVoter.getDeniedPage());
+    }
+
+}

PicketLink Implementation to redirect the login to the first denied page

Once that PicketLink handles the authentication for you, you only need +to store the denied page and observe PicketLink LoggedInEvent to +redirect you back to the denied page.

Use @SessionScoped or @WindowScoped for AdminAccessDecisionVoter and +store the denied page on your own.

@SessionScoped //or @WindowScoped
+public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
+
+    @Inject
+    private ViewConfigResolver viewConfigResolver;
+
+    private Class<? extends ViewConfig> deniedPage = Pages.Home.class;
+
+    @Override
+    protected void checkPermission(AccessDecisionVoterContext context, Set<SecurityViolation> violations) {
+
+        AuthorizationChecker authorizationChecker = BeanProvider.getContextualReference(AuthorizationChecker.class);
+        boolean loggedIn = authorizationChecker.isLoggedIn();
+
+        if(loggedIn) {
+            //...
+        } else {
+            violations.add(/*...*/);
+            deniedPage = viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
+        }
+    }
+
+    public Class<? extends ViewConfig> getDeniedPage() {
+        try {
+            return deniedPage;
+        } finally {
+            deniedPage = Pages.Home.class;
+        }
+    }
+}

And in AuthenticationListener you inject AdminAccessDecisionVoter

public class AuthenticationListener {
+
+    @Inject
+    private ViewNavigationHandler viewNavigationHandler;
+
+    @Inject
+    private AdminAccessDecisionVoter adminAccessDecisionVoter;
+
+    public void handleLoggedIn(@Observes LoggedInEvent event) {
+        this.viewNavigationHandler.navigateTo(adminAccessDecisionVoter.getDeniedPage());
+    }
+
+}

AccessDecisionVoterContext

Because the AccessDecisionVoter can be chained, +AccessDecisionVoterContext allows to get the current state as well as +the results of the security check.

There are several methods that can be useful

+
getState() - Exposes the current state : INITIAL, VOTE_IN_PROGRESS, VIOLATION_FOUND, NO_VIOLATION_FOUND
+
+
getViolations() - Exposes the found violations
+
+
getSource() - Exposes e.g. the current instance of javax.interceptor.InvocationContext in combination with @Secured used as interceptor.
+
+
getMetaData() - Exposes the found meta-data e.g. the view-config-class if @Secured is used in combination with type-safe view-configs
+
+
getMetaDataFor(String, Class<T>) - Exposes meta-data for the given key
+

SecurityStrategy SPI

The SecurityStrategy interface allows to provide a custom +implementation which should be used for @Secured. Provide a custom +implementation as bean-class in combination with @Alternative or +@Specializes (or as global-alternative).

In case of global-alternatives an additional config needs to be added to +/META-INF/apache-deltaspike.properties - e.g.:

globalAlternatives.org.apache.deltaspike.security.spi.authorization.SecurityStrategy=mypackage.CustomSecurityStrategy

Note: The config for global-alternatives is following the pattern: +globalAlternatives.<interface-name>=<implementation-class-name>

+ +

+ + + +

+ + + + \ No newline at end of file Added: deltaspike/site/trunk/content/documentation/staging/servlet.html URL: http://svn.apache.org/viewvc/deltaspike/site/trunk/content/documentation/staging/servlet.html?rev=1633803&view=auto ============================================================================== --- deltaspike/site/trunk/content/documentation/staging/servlet.html (added) +++ deltaspike/site/trunk/content/documentation/staging/servlet.html Thu Oct 23 13:00:33 2014 @@ -0,0 +1,534 @@ + + + + + + + + + +Servlet Module + + + + + + + + + + + + + + + + +

Servlet Module

+ +

Configuration
Injectable Servlet objects +
+
Servlet event propagation +
+

+ +

Configuration

In most cases there is no need for any additional configuration beside +adding the required dependencies to your project, because all required +listeners and filters are automatically registered in the container.

However there are certain situations in which you will have to manually +register the listeners and filters in your web.xml:

+
Your container doesn’t support Servlet 3.0 or newer.
+
+
You have set metadata-complete=true in your web.xml.
+
+
You packaged the servlet module in the lib directory of an EAR archive.
+

In these cases you will have to add the following section manually to +your web.xml:

<listener>
+    <display-name>EventBridgeContextListener</display-name>
+    <listener-class>org.apache.deltaspike.servlet.impl.event.EventBridgeContextListener</listener-class>
+</listener>
+
+<listener>
+    <display-name>EventBridgeSessionListener</display-name>
+    <listener-class>org.apache.deltaspike.servlet.impl.event.EventBridgeSessionListener</listener-class>
+</listener>
+
+<listener>
+    <display-name>ServletContextHolderListener</display-name>
+    <listener-class>org.apache.deltaspike.servlet.impl.produce.ServletContextHolderListener</listener-class>
+</listener>
+
+<listener>
+    <display-name>RequestResponseHolderListener</display-name>
+    <listener-class>org.apache.deltaspike.servlet.impl.produce.RequestResponseHolderListener</listener-class>
+</listener>
+
+<filter>
+    <display-name>RequestResponseHolderFilter</display-name>
+    <filter-name>RequestResponseHolderFilter</filter-name>
+    <filter-class>org.apache.deltaspike.servlet.impl.produce.RequestResponseHolderFilter</filter-class>
+</filter>
+<filter-mapping>
+    <filter-name>RequestResponseHolderFilter</filter-name>
+    <url-pattern>/*</url-pattern>
+</filter-mapping>
+
+<filter>
+    <display-name>EventBridgeFilter</display-name>
+    <filter-name>EventBridgeFilter</filter-name>
+    <filter-class>org.apache.deltaspike.servlet.impl.event.EventBridgeFilter</filter-class>
+</filter>
+<filter-mapping>
+    <filter-name>EventBridgeFilter</filter-name>
+    <url-pattern>/*</url-pattern>
+</filter-mapping>

Injectable Servlet objects

The DeltaSpike Servlet module contains producers for many objects of a +Servlet environment. All produces are using the special qualifier +@DeltaSpike for compatibility with CDI 1.1, which supports the +injection of some Servlet objects out of the box.

The following code shows the general injection pattern to use for all objects.

@Inject @DeltaSpike
+private ServletObject servletObject;

ServletContext

The ServletContext is made available in the application scope. It can +be injected into any CDI bean like this:

@Inject @DeltaSpike
+private ServletContext servletContext;

ServletRequest / HttpServletRequest

The ServletRequest is made available in the request scope. The current +request can be injected into a CDI bean like this:

@Inject @DeltaSpike
+private ServletRequest request;

In case of HTTP requests you can also inject the HttpServletRequest:

@Inject @DeltaSpike
+private HttpServletRequest request;

ServletResponse / HttpServletResponse

The ServletResponse is made available in the request scope. The +current response can be injected into a CDI bean like this:

@Inject @DeltaSpike
+private ServletResponse response;

In case of HTTP requests you can also inject the HttpServletResponse:

@Inject @DeltaSpike
+private HttpServletResponse response;

HttpSession

The HttpSession is made available in the session scope. You can inject +the current session of a user into a CDI bean like this:

@Inject @DeltaSpike
+private HttpSession session;

Please note that injecting the session this way will force the creation +of a session.

Principal

The Principal is made available in the request scope. The current +principal can be injected into a CDI bean like this:

@Inject @DeltaSpike
+private Principal principal;

The Principal is obtained by calling getUserPrincipal() on the +HttpServletRequest.

Servlet event propagation

The DeltaSpike Servlet module will propagate a number of Servlet object +lifecycle events to the CDI event bus. This allows regular CDI beans to +observe these events and react accordingly.

In most cases the event type is the object whose lifecycle is observed. +To distinguish between construction and destruction of the corresponding +object, DeltaSpike uses the qualifiers @Initialized and @Destroyed.

The following sections will show which concrete Servlet objects are +supported and how their lifecycle can be observed.

Servlet context lifecycle events

The Servlet module supports initialization and destruction events for +the ServletContext. These events can for example be used to detect +application startup or shutdown. The following code shows how these +events can be observed:

public void onCreate(@Observes @Initialized ServletContext context) {
+    System.out.println("Initialized ServletContext: " + context.getServletContextName());
+}
+
+public void onDestroy(@Observes @Destroyed ServletContext context) {
+    System.out.println("Destroyed ServletContext: " + context.getServletContextName());
+}

The events are emitted from a ServletContextListener called +EventBridgeContextListener. You can disable lifecycle events for the +ServletContext by deactivating the following class:

org.apache.deltaspike.servlet.impl.event.EventBridgeContextListener

If you manually registered the required filters and listeners, you can +also simply remove the entry for the EventBridgeContextListener from +your web.xml to disable the events.

Request and response lifecycle events

The Servlet module also supports initialization and destruction events +for the HttpServletRequest and HttpServletResponse. These events can +for example be used for initialization work like invoking +setCharacterEncoding on the request.

The following example shows how to observe lifecycle events for the +request:

public void onCreate(@Observes @Initialized HttpServletRequest request) {
+    System.out.println("Starting to process request for: " + request.getRequestURI());
+}
+
+public void onDestroy(@Observes @Destroyed HttpServletRequest request) {
+    System.out.println("Finished processing request for: " + request.getRequestURI());
+}

Observing lifecycle events for the response works the same way:

public void onCreate(@Observes @Initialized HttpServletResponse response) {
+    System.out.println("HttpServletResponse created");
+}
+
+public void onDestroy(@Observes @Destroyed HttpServletResponse response) {
+    System.out.println("HttpServletResponse destroyed");
+}

All events of this category are emitted from a servlet filter called +EventBridgeFilter. If you want to disable events for this category, +just use DeltaSpike’s deactivation mechanism to deactivate the following +class:

org.apache.deltaspike.servlet.impl.event.EventBridgeFilter

If you manually registered the required filters and listeners you can +also simply remove the entry for the EventBridgeFilter from your +web.xml to disable the events.

Session lifecycle events

The last category of events supported by the DeltaSpike Servlet module +are the lifecycle events for the user’s HTTP session. The following +example shows how these events can be observed from a regular CDI bean.

public void onCreate(@Observes @Initialized HttpSession session) {
+    System.out.println("Session created: " + session.getId());
+}
+
+public void onDestroy(@Observes @Destroyed HttpSession session) {
+    System.out.println("Session destroyed: " + session.getId());
+}

The lifecycle events for the HTTP session are sent from a +HttpSessionListener called EventBridgeSessionListener. To disable +this event category, deactivate the following class:

org.apache.deltaspike.servlet.impl.event.EventBridgeSessionListener

If you manually registered the required filters and listeners you can +also simply remove the entry for the EventBridgeSessionListener from +your web.xml to disable the events.

+ +

+ + + +

+ + + + \ No newline at end of file Added: deltaspike/site/trunk/content/documentation/staging/snapshots.html URL: http://svn.apache.org/viewvc/deltaspike/site/trunk/content/documentation/staging/snapshots.html?rev=1633803&view=auto ============================================================================== --- deltaspike/site/trunk/content/documentation/staging/snapshots.html (added) +++ deltaspike/site/trunk/content/documentation/staging/snapshots.html Thu Oct 23 13:00:33 2014 @@ -0,0 +1,267 @@ + + + + + + + + + +Use DeltaSpike Snapshots + + + + + + + + + + + + + + + + +

Use DeltaSpike Snapshots

+ +

Configure Maven to Use the Apache Snapshot Repository
Configure Your Project with the Snapshot Version

+ +

If you want to be at the bleeding edge, you can work with DeltaSpike snapshots. These are available from the Apache Snapshot Repository for use in Maven-based projects. To begin using them, you must configure Maven with the repository location and your projects with the snapshot version.

Warning: Snapshots provide previews of DeltaSpike during development. Snapshots are subject to change and may not yet include all expected features of the final release. Snapshots should not be used in production environments.

Configure Maven to Use the Apache Snapshot Repository

You must add the Apache Snapshot Repository to your Maven configuration settings.xml file. This ensures Maven can find the repository when it searches for your project DeltaSpike dependencies.

+
Open Maven configuration settings.xml file for editing
+

Add the Apache Snapshot Repository to the list of repositories

<repositories>
+    <repository>
+        <id>apache-snapshot-repository</id>
+        <url>http://repository.apache.org/snapshots/</url>
+        <releases>
+            <enabled>false</enabled>
+        </releases>
+        <snapshots>
+            <enabled>true</enabled>
+        </snapshots>
+    </repository>
+</repositories>

+
Save the settings.xml file changes
+

Configure Your Project with the Snapshot Version

With Maven configured for the Apache Snapshot Repository, you can specify DeltaSpike snapshot versions in your Maven-based projects.

+
Open the project pom.xml file for editing
+

Add the DeltaSpike snapshot version to the list of properties

<properties>
+    <deltaspike.version>1.0.3-SNAPSHOT</deltaspike.version>
+</properties>

+
Save the pom.xml file changes
+

+ +

+ + + +

+ + + + \ No newline at end of file Added: deltaspike/site/trunk/content/documentation/staging/source.html URL: http://svn.apache.org/viewvc/deltaspike/site/trunk/content/documentation/staging/source.html?rev=1633803&view=auto ============================================================================== --- deltaspike/site/trunk/content/documentation/staging/source.html (added) +++ deltaspike/site/trunk/content/documentation/staging/source.html Thu Oct 23 13:00:33 2014 @@ -0,0 +1,308 @@ + + + + + + + + + +Get Source and compile it + + + + + + + + + + + + + + + + +

Get Source and compile it

+ +

Introduction
SCM / Repository +
- Initial 'checkout'
- Update existing clone
- Read-only Mirrors +
  - GitHub-Mirror
  +
- GIT Workflow
+
Build
Tools / IDE +
- IntelliJ
- Eclipse
+

+ +

Introduction

+ +

SCM / Repository

We are using GIT as a Version Control System. The official GIT +repository of the project is available +here.

Initial 'checkout'

git clone https://git-wip-us.apache.org/repos/asf/deltaspike.git

Update existing clone

git pull --rebase

Read-only Mirrors

GitHub-Mirror

git clone https://github.com/apache/deltaspike

More information can be found here.

GIT Workflow

We follow an unified GIT workflow to +keep the commit history straight and therefore simple and clean. General +details about GIT at Apache are available +here and at +http://git-wip-us.apache.org.

Hint:

If you are new to Git you might like to try the +Git guide for subversion users or have +a look at the Git community book.

Build

So now you probably want to build the code. So follow the +instructions here

Tools / IDE

Commits (and in the best case also patches), have to follow our +"formatting rules". The following section provides settings for IDEs +used by us.

IntelliJ

Attached you can find the settings +for formatting the source code. Import them via File | Import +Settings…

Eclipse

For Eclipse you can use this +Code Formatter Profile. Import it via Window | Preferences | Java | Code Style | Formatter

+ +

+ + + +

+ + + + \ No newline at end of file