Dead-Simple Packaging and Deployment for JVM Apps

Overview

Capsule
Dead-Simple Packaging and Deployment for JVM Applications

Build Status Coverage Dependency Status Version License

Capsule is a packaging and deployment tool for JVM applications. A capsule is a single executable JAR that contains everything your application needs to run either in the form of embedded files or as declarative metadata. It can contain your JAR artifacts, your dependencies and resources, native libraries, the require JRE version, the JVM flags required to run the application well, Java or native agents and more. In short, a capsule is a self-contained JAR that knows everything there is to know about how to run your application the way it's meant to run.

One way of thinking about a capsule is as a fat JAR on steroids (that also allows native libraries and never interferes with your dependencies) and a declarative startup script rolled into one; another, is to see it is as the deploy-time counterpart to your build tool. Just as a build tool manages your build, Capsule manages the launching of your application.

But while plain capsules are cool and let you ship any JVM application -- no matter how complex -- as a single executable JAR, caplets make capsules even more powerful.

Documentation

Capsule website

Support

Discuss Capsule on the capsule-user Google Group/Mailing List

Getting Started

Download

or:

co.paralleluniverse:capsule:1.0.3

or:

Clone the repository and

gradle install

License

Copyright (c) 2014-2016, Parallel Universe Software Co. and Contributors. All rights reserved.

This program and the accompanying materials are licensed under the terms
of the Eclipse Public License v1.0 as published by the Eclipse Foundation.

    http://www.eclipse.org/legal/epl-v10.html

As Capsule does not link in any way with any of the code bundled in the JAR file, and simply treats it as raw data, Capsule is no different from a self-extracting ZIP file (especially as manually unzipping and examining the JAR's contents is extremely easy). Capsule's own license, therefore, does not interfere with the licensing of the bundled software.

In particular, even though Capsule's license is incompatible with the GPL/LGPL, it is permitted to distribute GPL programs packaged as capsules, as Capsule is simply a packaging medium and an activation script, and does not restrict access to the packaged GPL code. Capsule does not add any capability to, nor removes any from the bundled application. It therefore falls under the definition of an "aggregate" in the GPL's terminology.

Comments
  • Capsule doesn't unpack class files from /WEB-INF/classes

    Capsule doesn't unpack class files from /WEB-INF/classes

    I've constructed a war that looks something like below

    foo.war
    |-- Capsule.class
    `-- WEB-INF
         |-- lib
         `-- classes
              |-- logging.properties
              `-- package/with/classes/SomeClass.class
    

    Looking at the cache directory after running the application WEB-INF/classes only contans logging.properties and neither the directory structure nor classes within.

    capsule-0.7.1 / Windows 8.

    opened by draenor 38
  • Terminating app on Windows behaves differently than Linux

    Terminating app on Windows behaves differently than Linux

    ctrl-c on Linux gracefully terminates both JVMs and my app. ctrl-c on Windows CMD prompt terminates both JVMs but not gracefully AFAICS.

    My app has a JVM shutdown hook that produces many log lines. Intermittently I see the first log entry so perhaps Capsule shutdown is too aggressive? My app might be shutting down gracefully but silently, not sure.

    As a lesser issue, ctrl-c on Windows Babun/zsh/Cygwin terminates the Capsule JVM but leaves the app JVM orphaned & running.

    opened by gitblit 37
  • Thin capsule mode ignores missing dependancies

    Thin capsule mode ignores missing dependancies

    I'we made a thin jar using the maven plugin, and try to run it. During the download dependancies phase, I get error messages like these for a few dependencies:

    CAPSULE: Downloading: file:/Users/viktor/.m2/repository/com/thoughtworks/xstream/xstream/1.4.2/xstream-1.4.2.jar
    CAPSULE: Downloaded: file:/Users/viktor/.m2/repository/com/thoughtworks/xstream/xstream/1.4.2/xstream-1.4.2.jar (471 KB at 530.3 KB/sec)
    CAPSULE: Downloading: file:/Users/viktor/.m2/repository/org/hibernate/hibernate-core/3.3.2.GA/hibernate-core-3.3.2.GA.jar
    CAPSULE: Transfer failed: capsule.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.hibernate:hibernate-core:jar:3.3.2.GA in local (file:/Users/viktor/.m2/repository)
    capsule.org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.hibernate:hibernate-core:jar:3.3.2.GA in local (file:/Users/viktor/.m2/repository)
        at capsule.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
        at capsule.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
        at capsule.org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:744)
    CAPSULE: Downloading: file:/Users/viktor/.m2/repository/hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar
    CAPSULE: Downloaded: file:/Users/viktor/.m2/repository/hsqldb/hsqldb/1.8.0.7/hsqldb-1.8.0.7.jar (629 KB at 707.9 KB/sec)
    

    Then, at run time, I (predictably) get "methodNotFound" errors:

    Exception in thread "main" java.lang.NoSuchMethodError: org.hibernate.validator.HibernateValidatorConfiguration.addValidatedValueHandler(Lorg/hibernate/validator/spi/valuehandling/ValidatedValueUnwrapper;)Lorg/hibernate/validator/HibernateValidatorConfiguration;
        at io.dropwizard.setup.Bootstrap.<init>(Bootstrap.java:66)
        at io.dropwizard.Application.run(Application.java:67)
        at com.videoplaza.forecast.webservice.ForecastApiApplication.main(ForecastApiApplication.java:25)
    

    It's probably unwise to keep going after a dependancy has failed to resolve.. Also I would like to hide a bit of the capsule output as it is hard to pick up what is my application, what is capsule, and what went wrong right now.


    As for the actual error, I would appreciate any help on that too, obviously :p The local repository does indeed not contain the jar it's looking for, only a POM. I would assume the right thing to do in that case would be to check maven central too.. Or perhaps, for some reason, some dependancy only wants to see the POM but doesn't need the jar? I have no idea actually.

    This is the message I get when starting up:

    CAPSULE: Dependency manager initialized with repositories: [central, (central,, default, releases+snapshots), local (file:/Users/viktor/.m2/repository, default, releases+snapshots)]
    

    And my build step:

    <!-- BUILD CAPSULES -->
          <plugin>
             <groupId>com.github.christokios</groupId>
             <artifactId>capsule-maven-plugin</artifactId>
             <version>0.8.0-SNAPSHOT</version>
             <executions>
                <execution>
                   <phase>package</phase>
                   <goals>
                      <goal>capsule</goal>
                   </goals>
                   <configuration>
    
                      <!-- REQUIRED -->
                      <appClass>com.videoplaza.forecast.webservice.ForecastApiApplication</appClass>
    
                      <!-- OPTIONAL -->
                      <outputDir>target/</outputDir>
                      <!--<properties>-->
                         <!--<property>-->
                            <!--<name>propertyName1</name>-->
                            <!--<value>propertyValue1</value>-->
                         <!--</property>-->
                      <!--</properties>-->
                      <buildExec>true</buildExec>
                      <manifest>
                         <!--<property>-->
                            <!--<name>JVM-Args</name>-->
                            <!--<value>-Xmx512m</value>-->
                         <!--</property>-->
                         <property>
                            <name>Repositories</name>
                            <value>central, local</value>
                         </property>
                         <property>
                            <name>Allow-Snapshots</name>
                            <value>true</value>
                         </property>
                         <property>
                            <name>Min-Java-Version</name>
                            <value>1.8.0</value>
                         </property>
                      </manifest>
    
                   </configuration>
                </execution>
             </executions>
          </plugin>
    

    Thankful for your help!

    opened by rutchkiwi 36
  • Is it possible to set an app default for the cache dir ?

    Is it possible to set an app default for the cache dir ?

    I understand that the cache dir is configurable by env or system parameters and that the default location is the within a user's home directory. What I'd like is the option to set the default cache location to be co-located with the Capsule.

    /mycapsule.jar
    /lib/{extract/download dependencies here}
    

    It would be rather convenient to set something in the Capsule at build time that preferred this extraction point rather than relying on users to set an environment variable or providing a wrapper script.

    wontfix 
    opened by gitblit 33
  • Unable to set CAPSULE_CACHE_DIR env var in capsule manifest

    Unable to set CAPSULE_CACHE_DIR env var in capsule manifest

    Let me begin by saying that capsule is a great tool, that has many amazing features to streamline java app deployment and startup!

    My setup is the following:

    The gradle task looks like:

    task fatCapsule(type:FatCapsule) {
      applicationClass '######'
      capsuleManifest {
        environmentVariables = [
          'CAPSULE_CACHE_DIR': '######'
        ]
      }
    }
    

    The output capsule manifest looks like:

    Manifest-Version: 1.0
    Main-Class: Capsule
    Application-Class: #######
    Environment-Variables: CAPSULE_CACHE_DIR=#######
    

    I am working with capsule in a production system, in which it is not possible to write into the process' user home dir. I have tried the following approaches:

    • Set Extract-Capsule to false in the capsule manifest. I have verified that capsule no longer writes all the jars to the cache; however, capsule still creates the dir, which is undesirable. Also, when executing the capsule jar, there's an error that the capsule can't be found.
    • Set the 'Environment-Variables' manifest property to update the CAPSULE_CACHE_DIR. When I looked at the output of ps -ef | grep capsule, the second jvm process spawned is still using the default home dir setting.
    • Make a bash wrapper for my capsule-jar that will manually set the CAPSULE_CACHE_DIR, if it's not set, to avoid deployment overhead. This works; however, I would like to have this without a bash wrapper, for users that will interact with the capsule jar directly.
    opened by ryan-self 22
  • Capsule attribute ATTR_APP_CLASS_PATH does not allow custom directories to be added to the classpath

    Capsule attribute ATTR_APP_CLASS_PATH does not allow custom directories to be added to the classpath

    When extending the application CLASSPATH (overriding the attribute method and using the ATTR_APP_CLASS_PATH attribute) any directory path is automatically suffixed with a .jar extension by Capsule.

    This does not allow custom folders to be added to an application CLASSPATH.

    opened by pditommaso 17
  • Permissions issue when sharing the cache

    Permissions issue when sharing the cache

    Based off the conversation from #47, I decided to go with the approach of caching to /tmp; however, in that scenario, users would be sharing the same cache. I noticed that capsule keeps a .lock file, which is world-readable but not world-writable (obviously; just stating the case for completeness). The user who first generates the cache will be both user and group for the entire cache, including the .lock file; however, I noticed that the .lock file was not cleaned up after running the app via capsule.

    It looks like all of the files under the main cache dir are world-readable (without umask interfering, of course), so as long as capsule only does reads against the cache, there should not be a problem with the fact that the user/group are both the set to the user who first generated the cache. However, it appears there may be issues in capsule with keeping this .lock file in-sync when the cache is in a shared location.

    The main error we are getting for other users is the typical AccessDeniedException when trying to access the .lock file:

    CAPSULE EXCEPTION: java.nio.file.AccessDeniedException: /path/to/cache/apps/X/.lock (for stack trace, run with -Dcapsule.log=verbose)
    

    I can run with verbose on, if you think it would add additional info.

    opened by ryan-self 17
  • Closing an application occurred ConcurrentModificationException

    Closing an application occurred ConcurrentModificationException

    Hi @pron , I currently use capsule to build a executable application jar which embeded web server. When I close application, the exception randomizedly occurred, the message as follow:

    2016-01-23 19:50:14,384 [Thread-1] INFO  c.github.dolphineor.web.WebAppServer - Undertow web server on port 8081 stopped
    CAPSULE EXCEPTION: nullCAPSULE: Exception on thread cleanup: null
    CAPSULE EXCEPTION: null while processing null null: null while processing null null: null (for stack trace, run with -Dcapsule.log=verbose)
     (for stack trace, run with -Dcapsule.log=verbose)
    Exception in thread "cleanup" java.util.ConcurrentModificationException
            at java.util.ArrayList$Itr.checkForComodification(Unknown Source)
            at java.util.ArrayList$Itr.next(Unknown Source)
            at Capsule.cleanup0(Capsule.java:1417)
            at Capsule.cleanup(Capsule.java:1403)
            at Capsule.cleanup1(Capsule.java:1390)
            at Capsule.run(Capsule.java:1309)
            at java.lang.Thread.run(Unknown Source)
    

    Is there something wrong with me? Thanks in advance.

    opened by conchz 13
  • null while processing system property java.home

    null while processing system property java.home

    Getting this error after upgrading Capsule to version 0.10.0:

    CAPSULE: Launching app example.FooBarService_0.0.1
    CAPSULE: Locking /home/example/.capsule/apps/example.FooBarService_0.0.1/.lock
    CAPSULE: Extracting /usr/share/example-service/lib/example-service.jar to app cache directory /home/example/.capsule/apps/example.FooBarService_0.0.1
    CAPSULE: Error parsing Java version 1.8.0_31
    CAPSULE: Unocking /home/example/.capsule/apps/example.FooBarService_0.0.1/.lock
    CAPSULE EXCEPTION: null while processing system property java.home: /usr/lib/jvm/java-8-oracle/jre
    java.lang.NullPointerException
        at Capsule.getJavaHomes(Capsule.java:2998)
        at Capsule.findJavaHome(Capsule.java:2125)
        at Capsule.chooseJavaHome0(Capsule.java:2107)
        at Capsule.chooseJavaHome(Capsule.java:2098)
        at Capsule.getJavaHome(Capsule.java:2085)
        at Capsule.getJavaExecutable0(Capsule.java:1633)
        at Capsule.getJavaExecutable(Capsule.java:1625)
        at Capsule.buildJavaProcess(Capsule.java:1579)
        at Capsule.buildProcess0(Capsule.java:1153)
        at Capsule.buildProcess(Capsule.java:1144)
        at Capsule.prelaunch0(Capsule.java:1122)
        at Capsule.prelaunch(Capsule.java:1118)
        at Capsule.prepareForLaunch(Capsule.java:1033)
        at Capsule.launch(Capsule.java:974)
        at Capsule.main0(Capsule.java:296)
        at Capsule.main(Capsule.java:275)
    

    JAVA_HOME is set:

    $ echo $JAVA_HOME
    /usr/lib/jvm/java-8-oracle
    

    Here's the MANIFEST.MF for this application:

    Manifest-Version: 1.0
    Main-Class: Capsule
    Application-Class: example.FooBarService
    Application-Version: 0.0.1
    Min-Java-Version: 1.8
    JVM-Args:
    System-Properties: example.config=/etc/example-service/example.yml
    
    opened by ebridges 12
  • Wrapping a Capsule using launch4j

    Wrapping a Capsule using launch4j

    I successfully generated and ran a "fat" (fully contained) Capsule.

    I am now trying to distribute it as a launch4j executable.

    I then get the following error at run time: CAPSULE EXCEPTION: Not a JAR/ZIP file while processing environment variable LOCALAPPDATA: C:\Users\Olivier\AppData\Local (for stack trace, run with -Dcapsule.log=verbose)

    Considering that one of launch4j selling point is "Doesn't extract the jar from the executable", can a Capsule work in this environment?

    Regards.

    bug 
    opened by oparisy 11
  • Initial capsule build API (especially useful for build tools integration developers)

    Initial capsule build API (especially useful for build tools integration developers)

    Hi Ron,

    there are a couple of functions especially useful for Capsule plugin writers (egoistically speaking, https://github.com/circlespainter/lein-capsule, in my case especially helpful together with this https://github.com/cemerick/pomegranate/pull/69) I'd like to expose as public but they're part of a build-time Capsule API, which doesn't seem to exist yet (as far as I have seen).

    In order to reuse some information from the main capsule module I did some refactoring there too (mainly exposing constants in DependenciesManager but also some stdlib-level Java utilities).

    Do you think this could be merged or do you have any suggestions to improve it (or about other approaches)?

    TIA! - Fabio

    opened by circlespainter 11
  • Fails to find version when JAVA_TOOL_OPTIONS is set

    Fails to find version when JAVA_TOOL_OPTIONS is set

    For example, if we set the JAVA_TOOL_OPTIONS environment variable

    export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8
    

    then the first line is not the version:

    $ java -version                                
    Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
    openjdk version "1.8.0_322"
    OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-macos-aarch64) (build 1.8.0_322-b06)
    OpenJDK 64-Bit Server VM (Zulu 8.60.0.21-CA-macos-aarch64) (build 25.322-b06, mixed mode)
    

    The getActualJavaVersion looks only at the first line (see here).

    Ideally, it would skip over leading lines that start with Picked up. Related to https://github.com/nextflow-io/nextflow/issues/1716

    opened by nh13 0
  • Goint toward OpenJDK 17 compatibility

    Goint toward OpenJDK 17 compatibility

    Hello,

    capsule is packaged in Debian, where we are currently checking if building packages is still possible with OpenJDK 17, whereas we currently use OpenJDK 11. Hence the bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011924 concerning capsule. The current pull request solves the issue in the bug, but then I get 40 failing tests, please see the enclosed log. failingTests_openJDK17_20220529.txt

    I guess there are various reasons why the tests fail, for instance testWrapperCapsuleAgent certainly fails because of the illegal reflective access attempt in CapsuleTestUtils.accessible (which "only" issued a warning with previous JDKs). For other tests, I admit I have not gone into details that much.

    I will be happy to provide you with more details if I can and I would appreciate any help to achieve OpenJDK 17 compatibility if you have time for it,

    Best, Pierre

    opened by pgrt 0
  • Fix PAT_JAVA_VERSION Regex

    Fix PAT_JAVA_VERSION Regex

    The current regex fails to parse 11.0.9.1-internal due to the .1 "update" group. This version is coming from openjdk conda forge. See here for more details.

    This change allows for _<update> or .<update> in the version string.

    opened by sstadick 0
  • Capsule docs web site is gone

    Capsule docs web site is gone

    The capsule docs web site is not more accessible. http://www.capsule.io/

    Is there are any chance to restore it or to have access to any other copy of the docs?

    opened by pditommaso 4
  • Some potential NullPointerException bugs

    Some potential NullPointerException bugs

    Hi all, Our bug scanner has reported some NPE bugs.

    1.The first bug is at Jar.java#L459 . Since the variable zis may be null , a NPE bug may take place when zis invokes its method getNextEntry() .

    2.The second bug is at Capsule.java#L1715 . Since the variable server may be null , a NPE bug may take place when server invokes its method setSoTimeout() .

    A similar situation is at Capsule.java#L5362 . (The variable out may be null.)

    3.The third bug is at Capsule.java#L1229 . Since the variable defaultValue is checked for whether being null or not at Capsule.java#L1231 , a NPE bug may take place when defaultValue invokes its method equals() at Capsule.java#L1229 .

    4.The forth bug is at Capsule.java#L3341 . Since the variable type is checked for whether being null or not at Capsule.java#L3351 , a NPE bug may take place when defaultValue invokes its method equals() at Capsule.java#L3341 .

    5.The fifth bug is caused by the return null in method getAfter() . A NPE bug may take place when the return value of method getAfter() invokes its method substring() .

    6.The sixth bug is caused by the return value of the method getAttribute0(). Since the if statement block may be skipped, the method getAttribute0() may return null. A possible call chain is attribute00() => attribute0() =>getAttribute() =>isDependency() . A NPE bug may take place in isDependency() when the parameter lib invokes its method contains() .

    Some other NPE bugs are at Capsule.java#L2451 , Capsule.java#L843 , Capsule.java#L4001 , Capsule.java#L2514(when the method size() is invoked) .

    7.The seventh bug is caused by the return null in method accessible() . A NPE may take place when the return value of method accessible() invokes its method set().

    Some similar situations are at Capsule.java#L5637 , Capsule.java#L5476-5477 , Capsule.java#L5601 , Capsule.java#L5620

    Another possible call chain is Capsule.java#L4835 =>Capsule.java#L4826 =>Capsule.java#L608 . And a NPE bug may take place when the method getDeclaringClass() is invoked.

    The third possible call chain is Capsule.java#L4835 =>Capsule.java#L1311 . A NPE bug may take place when the method invoke() is invoked.

    8.The eighth bug is caused by the return null in method toAbsolutePath() . A possible call chain is Capsule.java#L2067 =>Capsule.java#L2073 . And a NPE bug may take place in method extractCapsule() when the parameter dir invokes its method toAbsolutePath().

    Another possible call chain is Capsule.java#L2067=>Capsule.java#L2070=>Capsule.java#L2104 . And a NPE bug may take place in method lockAppCache() when the parameter dir invokes its method resolve().

    The third possible call chain is Capsule.java#L2067=>Capsule.java#L2070=>Capsule.java#L2105 . And a NPE bug may take place in method testAppCacheUpToDate() when the parameter dir invokes its method resolve().

    Similar situations are at Capsule.java#L2072 => Capsule.java#L2088 , Capsule.java#L2070 => Capsule.java#L2107 => Capsule.java#L2173 .

    9.The ninth bug is caused by the return null in method resolve() . A possible call chain is Capsule.java#L2228=>Capsule.java#L2234. And a NPE bug may take place in method handleLongClasspath() when the parameter cp invokes its method size().

    Another call chain is Capsule.java#L2223=>Capsule.java#L2285=>Capsule.java#L4704 . A NPE bug may take place when the method iterator() is invoked.

    10.The tenth bug is caused by the return null in method firstOrNull() . A NPE bug may take place at Capsule.java#L3542 when the method toString() of the parameter p is invoked.

    11.The eleventh bug is caused by the return null in method name() . It may cause a NPE bug when the equals() method is invoked.

    12.The twelfth bug is caused by the return null in method getCacheDir() . It may cause a NPE bug when the resolve() method is invoked.

    13.The thirteenth bug is caused by the return null in method getProperty0() . A possible call chain is getProperty() =>Capsule.java#L218 . A NPE bug may take place when the method toLowerCase() is invoked.

    14.The fourteenth bug is caused by the return null in method shortJavaVersion() . A NPE bug may take place when the method split() is invoked.

    15.The fifteenth bug is caused by the return null in method lookupInAttribute() . A possible call chain is Capsule.java#L3181 => Capsule.java#L2735 => Capsule.java#L1492 . A NPE bug may take place when the booleanValue() method is invoked at Capsule.java#L1492.

    16.The sixteenth bug is caused by the return null in method simpleResolve() . A possible call chain is Capsule.java#L3525 => Capsule.java#L3533 . A NPE bug may take place when the getParent() method is invoked .

    17.The seventeenth bug is caused by the return null in method split() . A possible call chain is Capsule.java#L2445 => Capsule.java#L2446 . A NPE bug may take place when the remove() method is invoked .

    18.The eighteenth bug is caused by the return null in method getTempDir() . A possible call chain is Capsule.java#L5290 . A NPE bug may take place in method createPathingJar() when the toAbsolutePath() method is invoked since the parameter dir may be null.

    19.The nineteenth bug is caused by the return null in method getAppArtifactId() . A possible call chain is Capsule.java#L2655 =>Capsule.java#L2881 =>MyCapsule.java#L42 . And a NPE bug may take place when the method listIterator() is invoked.

    20.The twentyth bug is caused by the return null in method getAppArtifactId() . A possible call chain is Capsule.java#L2672 =>Capsule.java#L2881 =>MyCapsule.java#L36 . And a NPE bug may take place when the method put() is invoked.

    Thanks.

    opened by JulyChen728 1
Releases(v1.0.3)
  • v1.0.3(Aug 4, 2016)

  • v1.0.2(Apr 8, 2016)

  • v1.0.1(Oct 7, 2015)

    Improvements

    • Better JDK search.
    • The capsule process's MBeans (JMX) now reflect the application's.

    Closed issues

    • #90
    • Let caplet JARs as well be added to the classpath.
    • Allow using options in embedded caplets.
    • Fix 'liftoff'.
    • Fix exec(java -version)
    Source code(tar.gz)
    Source code(zip)
  • v1.0-rc1(Mar 7, 2015)

    New Features

    • Platform specific sections
    • JRE-version sections

    Breaking Changes

    • Maven dependency resolution separated into a different project
    • = instead of , used to separate renamed libs in the Native-Dependencies attribute
    • Unix-Script/Windows-Script abandoned in favor of Application-Script in platform specific sections
    • Native-Dependencies-Linux/Native-Dependencies-Win/Native-Dependencies-Mac abandoned in favor of Native-Dependencies in platform specific sections.
    • capsule-build project source moved to capsule-maven project
    Source code(tar.gz)
    Source code(zip)
  • v0.10.0(Nov 21, 2014)

    What's New

    • Caplet (custom capsule) chaining
    • More extension hooks for caplets
    • Capsule wrapping
    • Faster execution
    • Better error reporting
    • Class-Path attributes in embedded dependencies are now treated
    • Added capsule-build, utilities for build-tool plugins
    • Various bug fixes (like support for very long class paths on Windows)

    Release Announcement

    Source code(tar.gz)
    Source code(zip)
    capsule.jar(1.42 MB)
  • v0.9.0(Sep 22, 2014)

    New Features

    • New and improved methods for custom capsules
    • -Dcapsule.java.cmd to override Java executable selection

    Bug Fixes

    • Include default (empty) scope in POM when getting dependencies from POM.
    • Fixed capsule extraction when the capsule JAR was created on Windows
    Source code(tar.gz)
    Source code(zip)
    capsule.jar(1.41 MB)
  • v0.8.0(Sep 3, 2014)

    New Features

    • Capsule supports Maven's settings.xml for authentication of private repositories
    • A capsule's Maven repositories can be given ids (in the form id(url) rather than just url)
    • The CAPSULE_REPOS environment variable can now take a whitespace separated list (in addition to a comma-separated list)
    • Added a default log level attribute as well as a NONE log level
    • Programmatically set the capsule's mode in a custom capsule
    • The Args attribute can now address and reorder command line arguments with $*, $1, $2 etc.
    • Specify JVM arguments that apply only to the application on the command line via the capsule.jvm.args property
    • The application's (child) process pid is now published with a system property to be queried with jcmd or other tools.
    • Really executable capsules can now use "capsule trampolining" to execute the application directly in the parent process (the process launched at the command line) rather than in a child process.
    • The online documentation now includes Javadocs for all Capsule subprojects.

    Bug Fixes and Improvements

    • The Capsule JAR file size has been reduced from about 2MB to under 1.5MB (not relevant for fat capsules)
    • JARs in the Capsule's root are now added to the default classpath in lexical-order, to prevent different behavior on different platforms (the order can be explicitly specified with the App-Class-Path attribute)

    Breaking Changes

    • Repositories listed in the CAPSULE_REPOS environment variable are now prepended to the capsule's repositories rather than replace them
    • Some of Capsule's methods have changed names, which could affect custom capsules. See the Capsule class's Javadoc
    Source code(tar.gz)
    Source code(zip)
    capsule.jar(1.41 MB)
  • v0.7.1(Aug 20, 2014)

  • v0.7.0(Aug 18, 2014)

    Security

    New Features and Enhancements

    • The following repository aliases are recognized: central (Maven Central https), central-http(Maven Central http), jcenter (jCenter https), jcenter-http(jCenter http), and local (for the local repository).
    • Capsule supports local repositories with file:... URLs.
    • Capsule does not allow SNAPSHOT dependencies unless the Allow-Snapshots attribute is set to true.
    • Better JVM installation search on Windows.

    Bug Fixes

    • #14
    • -Dcapsule.resolve sometimes fails.
    Source code(tar.gz)
    Source code(zip)
    capsule.jar(1.98 MB)
  • v0.6.1(Aug 13, 2014)

  • v0.6.0(Aug 10, 2014)

  • v0.5.0(Jun 6, 2014)

    New Features

    • capsule.Jar is a simple API for editing JAR files in transit. It can be used by a web server serving capsules to edit the manifest or add entries (say, licenses etc.). This class will eventually move to a different package and be placed in a separate artifact.

    Bug Fixes

    • Capsule now returns the correct exit code in a non-interactive environment
    Source code(tar.gz)
    Source code(zip)
    capsule.jar(1.92 MB)
  • v0.4.2(May 24, 2014)

  • v0.4.1(May 22, 2014)

  • v0.4.0(May 15, 2014)

    New Features

    • Override Maven repository list with the CAPSULE_REPOS environment variable.
    • Uses the Implementation-Version manifest attribute if Application-Version is not found.
    • The JDK-Required attribute can specify that the capsule will (search and) run on a JDK installation.
    • The $JAVA_HOME variable can be used in the manifest.
    • -Dcapsule.version now also prints the application ID.
    • Dcapsule.resolve resolves (downloads) all external dependencies without launching the app.

    Bug Fixes

    • Fixed a bug that prevented the capsule from launching if the JVM-Args attribute was set to an empty value.
    • Capsule now builds without sonatype credentials set.
    Source code(tar.gz)
    Source code(zip)
    capsule.jar(1.91 MB)
  • v0.3.1(May 7, 2014)

  • v0.3.0(May 6, 2014)

  • v0.2.0(Apr 28, 2014)

Owner
Parallel Universe
Parallel Universe
JitPack is a novel package repository for JVM and Android projects.

JitPack is a novel package repository for JVM and Android projects. It builds Git projects on demand and provides you with ready-to-use artifacts (jar, aar).

JitPack 2.3k Nov 26, 2022
This simple Android Studio plugin includes keyboard shortcuts for many common actions.

Hotkeys This simple Android Studio plugin includes keyboard shortcuts for many common actions. Features • Build process • Contribute • License Feature

SACHIN KASARADDI 14 Apr 26, 2022
A simple but helpful fight plugin with rank support

RankFight A simple but helpful fight plugin with rank support HighLights PlceholderAPI Support %rankfight_rank% %rankfight_credit% %rankfight_shopCred

贺兰星辰 5 Nov 20, 2021
:package: Gradle/Maven plugin to package Java applications as native Windows, Mac OS X, or GNU/Linux executables and create installers for them.

JavaPackager JavaPackager is a hybrid plugin for Maven and Gradle which provides an easy way to package Java applications in native Windows, Mac OS X

Francisco Vargas Ruiz 647 Dec 6, 2022
Publish Jenkins performances metrics to an OpenTelemetry endpoint, including distributed traces of job executions and health metrics of the controller.

OpenTelemetry Introduction Architecture Features Getting Started Examples Configuration as Code Contributing Introduction Collect Jenkins monitoring d

Jenkins 71 Nov 18, 2022
Maven plugin to help creating CHANGELOG by keeping one format and solving merge request conflicts problem by extraction of new CHANGELOG entries to seperate files.

keep-changelog-maven-plugin CHANGELOG.md is one of the most important files in a repository. It allows others to find out about the most important cha

Piotr Zmilczak 22 Aug 28, 2022
HopLa Burp Suite Extender plugin - Adds autocompletion support and useful payloads in Burp Suite

HopLa ?? All the power of PayloadsAllTheThings, without the overhead. This extension adds autocompletion support and useful payloads in Burp Suite to

Synacktiv 517 Nov 28, 2022
Ask and replay plugin for Mirai-Console

EntryLib EntryLib 是一个基于 Mirai-Console 的插件,用于实现群词条、自定义回复或更多功能。 目录 声明 使用方法 基本指令列表 额外说明 配置项 控制台 数据库结构 To-Do List 插件依赖 声明 本插件仅作为学习交流等使用,请勿用于盈利,否则法律后果自负。 欢

Bill Yang 33 Oct 25, 2022
A proof-of-concept Android application to detect and defeat some of the Cellebrite UFED forensic toolkit extraction techniques.

LockUp An Android-based Cellebrite UFED self-defense application LockUp is an Android application that will monitor the device for signs for attempts

mbkore 301 Nov 30, 2022
Ghidra Wasm plugin with disassembly and decompilation support

Module to load WebAssembly files into Ghidra, supporting disassembly and decompilation. This plugin borrows loader functionality from this repo: https

Garrett Gu 54 Nov 22, 2022
The best plugin to protect anarchy servers and mc servers in general against op attacks.

AdminSecure The best plugin to protect anarchy servers and mc servers in general against op attacks How does it work? When the server detects a player

PK2_Stimpy 3 Sep 2, 2021
Ghidra Plugin for Texas Instrument CC 8051 SOC's especially CC1110 and CC2510

Texas Instruments CCxxxx Ghidra CPU Plugin Ghidra Plugin for Texas Instrument CC 8051 core SOC's especially CC1110 and CC2510 This helps to name the d

null 5 Sep 4, 2022
Dead-Simple Packaging and Deployment for JVM Apps

Capsule Dead-Simple Packaging and Deployment for JVM Applications Capsule is a packaging and deployment tool for JVM applications. A capsule is a sing

Parallel Universe 1.1k Sep 16, 2022
Model import deployment framework for retraining models (pytorch, tensorflow,keras) deploying in JVM Micro service environments, mobile devices, iot, and Apache Spark

The Eclipse Deeplearning4J (DL4J) ecosystem is a set of projects intended to support all the needs of a JVM based deep learning application. This mean

Eclipse Foundation 12.7k Nov 29, 2022
Android Auto Apps Downloader (AAAD) is an app for Android Phones that downloads popular Android Auto 3rd party apps and installs them in the correct way to have them in Android Auto.

Android Auto Apps Downloader (AAAD) is an app for Android Phones that downloads popular Android Auto 3rd party apps and installs them in the correct way to have them in Android Auto.

Gabriele Rizzo 822 Nov 28, 2022
A powerful open source test automation platform for Web Apps, Mobile Apps, and APIs

A powerful open source test automation platform for Web Apps, Mobile Apps, and APIs. Build stable and reliable end-to-end tests @ DevOps speed.

Testsigma Technologies Inc 430 Dec 1, 2022
Project on End to End CI/CD pipeline for java based application using Git,Github,Jenkins,Maven,Sonarqube,Nexus,Slack,Docker and Kuberenets with ECR as private docker registry and Zero Downtime Deployment

Project on End to End CI/CD pipeline for java based application using Git,Github,Jenkins,Maven,Sonarqube,Nexus,Slack,Docker and Kuberenets with ECR as private docker registry and Zero Downtime Deployment.

NITHIN JOHN GEORGE 10 Nov 22, 2022
An example spring boot app to try out with a Parca Agent deployment.

Spring boot example This repo is an example for how a Java application can be profiled with Parca Agent. First deploy Parca and Parca Agent as usual,

Parca 1 Mar 9, 2022
This project demonstrates reference deployment of OTP API.

Client Application to simulate OTP Request API flow Introduction This is a Spring boot application which can be used to generate OTP on the registered

UIDAI 4 Oct 27, 2021