Please note that the package command must have been executed before the capsule:build command can be run.
The only requirement is to have the <appClass> attribute in the configuration. This is the class of your app that contains the main method which will be fired on startup. You must include the package path along with the class name (hello is the package and HelloWorld is the class name above).
It is recommended to have specified the capsule.version property in your pom so that the capsule plugin knows which version of capsule to use.
If none is specified, the default version of Capsule will be used as specified at the top of the readme (which may not be the latest).
You can also set the capsule.maven.version property to tell the plugin which version of CapsuleMaven to use.
Building Automatically
It is recommended to have an execution setup to build the capsules, thus eliminating you to run an additional maven command to build them.
By default the build goal runs during the package phase.
So now if you were to run simply mvn package then the build goal will execute which will build the capsules into your build directory.
Or alternatively you could use the maven-exec-plugin to run your app (as you develop), and then only build the capsule(s) when you want to deploy to a server. This plugin integrates nicely with the maven-exec-plugin, see here.
Capsule Contents
Essentially Capsule can be packaged with as much or as little as you want.
Two things you need to think about to make up a capsule are, the app jar and the dependency jars. And these, as you will see, can be optionally included!
The source of dependencies is taken from two places. Firstly, from the <dependencies> tag defined under the root <project> tag, namely the app dependencies. Secondly the dependencies defined under the <dependencies> tag within the <plugin> tag for this plugin, also known as the plugin dependencies.
You have the option to include all, none or some of the dependencies.
This can be done with various flags as you will see later, based on their source, scope, their optional flag and if they are direct (root) or indirect (transitive) dependencies.
The Simple Types
Generally, the most common types of capsules are the following three:
fat: This capsule jar will contain your app's jar as well as all its dependencies. When the fat-jar is run, then Capsule will simply setup the app and run it.
thin: This capsule jar will contain your app's classes but no dependencies. Capsule will resolve these dependencies at runtime (in the cache).
empty: This capsule will not even include your app, or any of its dependencies. It will only contain the name of your app declared in the jar's manifest, along with capsule's classes. Capsule will read the manifest entry Application and resolve the app and its dependencies in Capsule's own cache (default ~/.capsule).
These are just the popular types that fit neatly into a box, and thus the plugin provides a simple flag to build these. Namely the <type> field can be set to fat, thin or empty.
To build a fat capsule simply include the following:
Note that the three simple types apply to only the compile and runtime scoped dependencies (but cover the transitive dependencies). More on this later.
If none of these quite fit, then the plugin can accommodate a wide range of different setups, it is encouraged you build the capsule with your own specific requirements without being bogged down on the three specific types listed above.
Custom Builds
(Note, to make a custom build, the <type> tag must not be set!)
If the types defined in the <type> don't quite fit your needs and you need something a little different, then you can easily customise the jar to a vast array of options.
Essentially it comes down to the following scenarios; whether or not to include the app or resolve it at runtime; what dependencies to include based on their source, scope etc and which to resolve at runtime; and same question for the transitive dependencies.
So to cover all these ideas, you have the following flags:
These includeXYZ flags essentially tell the plugin what to include/embed in the jar. Of course if there are any of these that you exclude from the capsule jar, and in turn they are needed for the launch, then runtime resolution will be needed by marking some resolveXYZ to true.
A fat capsule essentially is equivalent to having only the following set to true:
The source of dependencies is taken from two places. Firstly, from the <dependencies> tag defined under the root <project> tag, namely the app dependencies. Secondly the dependencies defined under the <dependencies> tag within the <plugin> tag for this plugin, also known as the plugin dependencies.
You can choose to include a source by using <includeAppDep>true</includeAppDep> or <includePluginDep>true</includeAppDep>.
Including Dependencies based on scope
You can include certain dependencies by setting the scope of the dependency to something that you will be including in the built capsule.
All possible options for scope are compile, runtime, provided, system or test.
Note that the plugin dependencies can only have scope compile, runtime or system.
So you could set your dependency to scope runtime like so:
Just make sure you have a source also set to true for example, <includeAppDep>true<includeAppDep> or <resolveAppDep>true<resolveAppDep>.
Understanding Dependency Scope
In maven, you can essentially define the following five scopes for your dependencies; compile, runtime, provided, system and test.
You set the scope on each of the project's direct dependencies. Although transitive dependencies will have defined scope also, this only applies specifically to their own project.
The scope of transitive dependencies in relation to the main project will be directly affected by the scope of its parent dependency. We call this the 'direct-scope'.
Also note, that transitive dependencies with scope other than compile or runtime are not applicable to the main project and thus are excluded always.
So for each direct dependency with scope:
compile
compile transitive dependencies have compile direct-scope.
runtime transitive dependencies have runtime direct-scope.
runtime
compile transitive dependencies have compile direct-scope.
runtime transitive dependencies have runtime direct-scope.
provided
compile & runtime transitive dependencies have provided direct-scope.
system
compile & runtime transitive dependencies have system direct-scope.
test
compile & runtime transitive dependencies have test direct-scope.
So, all the includeXYZ and resolveXYZ follow the above rules.
Runtime Resolution
To perform the resolution at runtime (such as needed by the thin and empty types), the capsule will include the necessary code to do this (namely the MavenCaplet). This adds slightly to the overall file size of the generated capsule jar. This additional code is obviously mandatory if any dependencies (or the app itself) needs to be resolved at runtime.
To build the capsule without this additional code, make sure none of the resolveXYZ flags are set to true (by default all set to false or the <type> is set to fat).
If making a custom build and resolution is needed at runtime, then add the desired resolveXYZ tags in the <configuration> tag like so:
It is possible to chmod+x a jar so it can be run without needing to prefix the command with java -jar. You can see more info about this concept here and here.
The plugin can build really executable jars for you automatically!
Add the <chmod>true</chmod> to your configuration (default is false).
The plugin will then output the really executables with the extension .x.
target/my-app-1.0-cap.jar
target/my-app-1.0-cap.x
So normally you would run the capsule like so:
java -jar target/my-app-1.0-cap.jar
However with the really executable builds, you can alternatively run the capsule nice and cleanly:
./target/my-app-1.0-cap.x
or
sh target/my-app-1.0-cap.x
Trampoline
When a capsule is launched, two processes are involved: first, a JVM process runs the capsule launcher, which then starts up a second, child process that runs the actual application. The two processes are linked so that killing or suspending one, will do the same for the other. While this model works well enough in most scenarios, sometimes it is desirable to directly launch the process running the application, rather than indirectly. This is supported by "capsule trampoline". See more here at capsule.
Essentially the concept defines that that when you execute the built Capsule jar, it will simply just output (in text) the full command needed to run the app (this will be a long command with all jvm and classpath args defined). The idea is then to just copy/paste the command and execute it raw.
If you would like to build 'trampoline' executable capsules you can add the <trampoline>true</trampoline> flag to the plugin's configuration:
This will output the command which you then have to copy and paste and run it yourself manually, thus ensuring you have only one process for your app.
Providing your app System Properties
Capsule also supports providing your app with system properties. This can be done at runtime but its also convenient to define some properties at build time too.
Simply add the <properties> tag in the plugin's configuration and declare any properties.
Note you do not need Main-Class, Application-Class, Application, Dependencies and System-Properties as these are generated automatically by the plugin.
Custom File Name
The output capsule jar's name is as per the <finalName> tag with the appending of the -capsule, by default.
Essentially this is <finalName>-capsule.jar so for example your app might be app-capsule.jar.
If you wish to have custom text, then you can optionally set either of parameters fileName and fileDesc which make up the format:
<fileName><fileDesc>.jar
So for example if you'd like to have your output capsule jar like 'my-amazing-app-cap.jar' then you would do the following:
Capsule supports the concept of modes, which essentially means defining your app jar into different ways depending on certain characteristics.
You define different modes for your app by setting specific manifest and/or system properties for each mode. So for e.g you could have a test mode which will define a test database connection, and likewise a production mode which will define a production database connection.
You can then easily run your capsule in a specific mode by adding the -Dcapsule.mode=MODE argument at the command line. See more at capsule modes.
The maven plugin supports a convenient way to define modes for your capsule (include the below in the <configuration> tag).
A mode must have the <name> tag, and you may define two things for each mode, namely, <properties> and <manifest> (in exactly the same syntax as above).
If the mode is activated at runtime (-Dcapsule.mode=production) then the properties listed in the mode will completely override the properties set in the main configuration. Thus, only the properties listed in the mode section will be available to the app.
However, the mode's manifest entries will be appended to the existing set of entries defined in the main section (unless any match up, then the mode's entry will override).
Of course, you can define multiple modes.
FileSets
If you'd like to copy over specific files from some local folder then you can use the
assembly style <fileSets> in the <configuration> tag.
So from above we copy over the myconfig.yml file that we have in our config folder and place it within the config directory in the capsule jar (the plugin will create this folder in the capsule jar).
You specify a number of <fileSet> which must contain the <directory> (the location of the folder to copy), the <outputDirectory> (the destination directory within the capsule jar) and finally a set of <include> to specify which files from the <directory> to copy over.
The <include> tag supports a single wildcard *. So for example <include>*.yml</include>, <include>myconfig*</include> or <include>my*.yml</include> can work.
DependencySets
If you'd like to copy over specific files from files embedded in some dependency then you can use the
assembly style <dependencySets> in the <configuration> tag.
So from the above we pull the manifest file from within Google Guava's jar and place it within the config directory in the capsule jar (the plugin will create this folder in the capsule jar).
You specify a number of <dependencySet> which must contain the coords (<groupdId>, <artifactId>, <classifier>, <version>) of a project dependency (the classifier and version are optional), the <outputDirectory> (the destination directory within the capsule jar) and finally a set of <include> to specify which files from the dependency to copy over.
The <include> tag supports a single wildcard *. So for example <include>META-INF/*</include>, <include>*MANIFEST.MF</include> or <include>META-INF/*.MF</include> can work.
You could also copy over the whole dependency directly if you leave out the includes tag:
Ths plugin can support older or newer versions of capsule (at your own risk). You can specify a maven property for the capsule version (this will be the version of capsule to package within the build of the capsules).
Otherwise, the default version of capsule will be used automatically. This is recommended.
Caplets
Capsule supports defining your own Capsule class by extending the Capsule.class. If you want to specify your custom Capsule class, add a manifest entry pointing to it:
客服电话
APP下载
官方微信
请发表评论