Archive: September 2014

Gradle Goodness: Running Groovy Scripts as Application

Posted on by  
Hubert Klein Ikkink

In a previous post we learned how to run a Java application in a Gradle project. The Java source file with a main method is part of the project and we use the JavaExec task to run the Java code. We can use the same JavaExec task to run a Groovy script file.

A Groovy script file doesn't have an explicit main method, but it is added when we compile the script file. The name of the script file is also the name of the generated class, so we use that name for the main property of the JavaExec task. Let's first create simple Groovy script file to display the current date. We can pass an extra argument with the date format we wan't to use.

Continue reading →

Gradle Goodness: Adding Dependencies Only for Packaging to War

Posted on by  
Hubert Klein Ikkink

My colleague, Tom Wetjens, wrote a blog post Package-only dependencies in Maven. He showed a Maven solution when we want to include dependencies in the WAR file, which are not used in any other scopes. In this blog post we will see how we solve this in Gradle.

Suppose we use the SLF4J Logging API in our project. We use the API as a compile dependency, because our code uses this API. But in our test runtime we want to use the SLF4J Simple implementation of this API. And in our WAR file we want to include the Logback implementation of the API. The Logback dependency is only needed to be included in the WAR file and shouldn't exist in any other dependency configuration.

Continue reading →

Package-only dependencies in Maven

Posted on by  
Tom Wetjens

Sometimes you have a Maven project that needs dependencies for running tests that you do not want ending up in the final packaged WAR. We all know the test directive in the POM that accomplishes this. You might also have dependencies that are only required at runtime and need to be in the WAR but not on the compile classpath. Normally you would use the runtime directive in the POM. Consider a situation where we have a dependency that we want to be available at runtime (in the WAR), but not on the classpath during the execution of our tests. A nice example of this is logging implementations: we want to use the slf4j-simple implementation for running unit tests, but we want logback-classic to be packaged in the WAR. To accomplish this, you can use the maven-dependency-plugin as illustrated in the following POM snippet:

 org.slf4j
            slf4j-api
            1.7.7 

        
        junit
            junit
            4.11
            test 
        org.slf4j
            slf4j-simple
            1.7.7
            test 
    org.apache.maven.plugins
                maven-dependency-plugin
                package-only-deps
                        
                        prepare-package
                        copy 
                        ch.qos.logback
                                    logback-classic
                                    1.1.2 
                            ${project.build.directory}/${project.build.finalName}/WEB-INF/lib 

Continue reading →

Javascript oneliners: functions are attributes too

Posted on by  
Richard Rijnberk

Just a small reminder. Javascript allows you to call methods based on their name. So if a DOM element has a addClass and removeClass which both take the same argument we could write:

var someClass = 'some-class';
var hasClass = element.hasClass(someClass);
if(hasClass){
    element.addClass(someClass);
} else {
    element.removeClass(someClass);
}

Continue reading →

shadow-left