High-performance dynamic image server in Java
Get started with a release build.
cp cantaloupe.properties.sample cantaloupe.properties
then edit cantaloupe.properties per your needs.mvn clean compile exec:java -Dcantaloupe.config=cantaloupe.properties
will build and run the
project using the embedded web server listening on the port(s) specified in
cantaloupe.properties
.mvn clean package -DskipTests
will build a release JAR in the target
folder, which can be run via:
java -cp cantaloupe-{version}.jar -Dcantaloupe.config=... edu.illinois.library.cantaloupe.StandaloneEntry
edu.illinois.library.cantaloupe.StandaloneEntry
and
add the -Dcantaloupe.config=cantaloupe.properties
VM option.Copy test.properties.sample
to test.properties
and fill in whatever info
you have.
The code tests are structured into three Maven profiles:
mvn clean test -Pnodeps
will run only the tests that have no dependencies
on third-party services and do not require any external tools or libraries.
mvn clean test -Pfreedeps
will run all of the above tests, plus any that
depend on open-source tools or libraries. These are the tests run in
continuous integration. The following dependencies are required:
mvn clean test
will run all tests including the ones above. The following
additional dependencies are required:
Because it can be a chore to install all of the dependencies needed to get all
of the tests in the freedeps
profile passing, there is a docker-compose.yml
file available that will spin up all needed dependencies in separate
containers, and run the tests in another container. From the project root
directory, invoke:
docker-compose -f docker/{platform}/docker-compose.yml up --build --exit-code-from cantaloupe
.
There is an output tester tool that enables visual inspection of image output.
Performance tests use JMH.
Run them with mvn clean test -Pbenchmark
.
The suggested process for contributing code changes is:
release/x.x
or develop
(see the "Versioning" section.)git commit -am 'Add some feature'
).git push origin feature/my-new-feature
).Different application versions may require different configuration file keys. It's good practice to use a dedicated configuration file for each version. Key changes are documented in UPGRADING.md.
Cantaloupe roughly uses semantic versioning. Major releases (n) involve major redesign that breaks backwards compatibility significantly. Minor releases (n.n) either do not break compatibility, or only in a minor way. Patch releases (n.n.n) are for bugfixes only.
Cantaloupe uses a basic version of the
Gitflow
branching model. develop
is the main branch that tracks the current state of
the next non-bugfix release. Significant features branch off of that into
feature branches (feature/feature-name
), from which they can be integrated
into a particular release.
When a major or minor version in develop
is ready for release, it merges into
a release/n.n
branch, where the release is tagged and the release archive is
created.
Bugfixes that would increment a minor version of a release are applied to its
release branch and merged back into develop
.
mvn verify -DskipTests=true
)mvn org.owasp:dependency-check-maven:check
)mvn clean compile spotbugs:spotbugs spotbugs:gui
)release/vX.X
pom.xml
and commit this changegit push origin release/x.x
git tag -a v{version} -m 'Tag v{version}'; git push --tags
Cantaloupe is open-source software distributed under the University of Illinois/NCSA Open Source License; see the file LICENSE.txt for terms.