Search Gradle plugins

com.boxfuse.client

Boxfuse is the easiest way to deploy your JVM-based applications to AWS. Boxfuse builds minimal fully-provisioned images in seconds. These images are immutable and tailor-made to do only one thing: run your app as efficiently as possible on the cloud. There is no ssh, no general purpose operating system and no tedious provisioning. Boxfuse images are lean, secure and efficient. You can run them on VirtualBox for development and deploy them unchanged and with zero downtime on AWS for test and production. While Boxfuse works with any .jar or .war file, it is especially optimized for Spring Boot, Dropwizard, Tomcat and TomEE. All you need is a GitHub user to get started. The Boxfuse free plan aligns perfectly with the AWS free tier, so you can deploy your application to EC2 completely free. Find out more and get started at https://boxfuse.com

https://boxfuse.com/

Version 1.27.1.1353 (latest)

Created 07 June 2017.

Boxfuse is the easiest way to deploy your JVM-based applications to AWS. Boxfuse builds minimal fully-provisioned images in seconds. These images are immutable and tailor-made to do only one thing: run your app as efficiently as possible on the cloud. There is no ssh, no general purpose operating system and no tedious provisioning. Boxfuse images are lean, secure and efficient. You can run them on VirtualBox for development and deploy them unchanged and with zero downtime on AWS for test and production. While Boxfuse works with any .jar or .war file, it is especially optimized for Spring Boot, Dropwizard, Play, Tomcat and TomEE. All you need is a GitHub user to get started. The Boxfuse free plan aligns perfectly with the AWS free tier, so you can deploy your application to EC2 completely free. Find out more and get started at https://boxfuse.com

Build script snippet for use in all Gradle versions:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "gradle.plugin.com.boxfuse.client:client:1.27.1.1353"
  }
}

apply plugin: "com.boxfuse.client"

Build script snippet for new, incubating, plugin mechanism introduced in Gradle 2.1:

plugins {
  id "com.boxfuse.client" version "1.27.1.1353"
}

Why?

The new way to add plugins to a project is much more than a more convenient syntax. The new DSL is processed very differently to the old one. The new mechanism allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as:

  • Optimize the loading and reuse of plugin classes.
  • Allow different plugins to use different versions of dependencies.
  • Provide editors detailed information about the potential properties and values in the buildscript for editing assistance.

This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the rest of the build script. It also requires that the definition of plugins to use be somewhat static.

There are some key differences between the new plugin mechanism and the “traditional” apply() method mechanism. There are also some constraints, some of which are temporary limitations while the mechanism is still being developed and some are inherent to the new approach.

Constrained syntax.

The new plugins {} block does not support arbitrary Groovy code. It is constrained, in order to be idempotent (produce the same result every time) and side effect free (safe for Gradle to execute at any time).

The form is:

plugins {
    id «plugin id» version «plugin version»
}

Where «plugin version» and «plugin id» must be constant, literal, strings. No other statements are allowed; their presence will cause a compilation error.

The plugins {} block must also be a top level statement in the buildscript. It cannot be nested inside another construct (e.g. an if-statement or for-loop).

Can only be used in build scripts.

The plugins {} block can currently only be used in a project's build script. It cannot be used in script plugins, the settings.gradle file or init scripts.

Future versions of Gradle will remove this restriction.

Cannot be used in conjunction with subprojects {}, allprojects {} etc.

It is not possible to use the familiar pattern of applying a plugin to multiple projects at once using subprojects {} etc. at the moment. There is currently no mechanism for applying a plugin to multiple projects at once. At the moment, each project that requires a plugin must declare so in the plugins {} block in its buildscript.

Future versions of Gradle will remove this restriction.

If the current limitations of the new plugin mechanism are problematic for your build, the recommended approach is to use the “traditional” mechanism for the time being.