sfuhrm / capsula Goto Github PK

Check whether it makes sense to add a shutdown hook that kills docker processes

Redirect docker output to slf4j

Test installation of packages on each platform. This is a little difficult
because a package could require other apt sources (like capsula does for docker).

Documentation for YAML format.

Could somehow tag which Git commit was used for building.

Support app icons

Basically this can be done with a run/command xdg-desktop-menu --mode system foo.desktop
But the images are lacking xdg-utils which points again towards different profiles, see also #12

This is an indicator for build dependencies.

See also https://portland.freedesktop.org/xdg-utils-1.1.0-rc1/scripts/html/xdg-desktop-menu.html

Maven keeps downloading the plugins / dependencies over and over again. This takes quite long.

Ideas:

• Reusing .m2 directory from first container that builds.
• Reusing of users .m2 directory for speeding up maven runs a lot. The .m2 directory would go to /root/.m2 but should not contain any special settings.
• Won't work because of non-root: Union fs mount the .m2 directory somewhere accessible.
• Won't work because of HTTPS: Adding a caching proxy and configuring it in the containers could speed up also downloading package dependencies.

Other source fetching methods than Git:

• SVN
• CVS (RCS? LOL?)
• ZIP/Tar.(gz|bz2|xz) Archive

Create include-mechanism usable by multiple targets, i.e. for creating gar.gz out of git

Optionally use a fixed directory for targets instead of inside JAR.
This would safe you the tool build cycle in plugin development.

Usage documentation.

YAML scaffolding using an existing pom file.

The could pre-fill:

• JDK version for build and run (see #12 )
• Package name
• Author(s)
• License

Help support for package search on multiple distributions.
This is usually a problem.

optdepends mapping to recommends / suggests?

https://wiki.archlinux.org/index.php/PKGBUILD#Dependencies

Support for different JDK/JRE depencendies.
At the moment this can be done using the relations.
Could add this when doing #9

Implementation idea: Have a mapping file somewhere which JDK/JREs mean what packages in the target distributions.

The dimensions can be:

• JDK/JRE top version (5, 6, 7, 8, 9)
• JDE or JRE (JDK/JRE)
• OpenJDK or Oracle
• Headless or not

Add support for Gradle, Ant (?) besides Maven.

Scaffolding of the YAML configuration for your program.

For Java this could be the dependencies:

The dimensions can be:

JDK/JRE top version (5, 6, 7, 8, 9)
JDE or JRE (JDK/JRE)
OpenJDK or Oracle
Headless or not

Debian Documentation says that urgency and distribution is only relevant for the top changelog entry.

Each upload needs to specify which distribution the package is intended for. The package build process extracts this information from the first line of the debian/changelog file and places it in the Distribution field of the .changes file.

From changelog.ftl:
${capsula.debian.packageName} (${version.version}-${version.release}) ${capsula.debian.distribution}; urgency=${capsula.debian.urgency}

Maybe this is just relevant for the topmost entry?

Support checking out specific git commits

git field in YAML is now there, but the commit field is ignored by the templates at the moment