JH_COMPILEFEATURES(1)

πŸ’… JH_COMPILEFEATURES(1) β€” aka jh_compilefeatures, bestie edition

okay so you found jh_compilefeatures(1), the manual page for the little javahelper queen that compiles eclipse features with pde-build. she's chill, she's powerful, and she has ✨opinions✨ about build order (spoiler: she does not fix it for you, and we'll get to that).


🌸 NAME 🌸

jh_compilefeatures β€” compiles eclipse features using pde-build. that's it, that's the vibe. πŸ¦‹


✨ SYNOPSIS ✨

jh_compilefeatures [debhelper options] [options] [--pde-build-dir=dir]
[feature [...]]

πŸ’– DESCRIPTION πŸ’–

okay so <pink>jh_compilefeatures</pink> is a javahelper girlie and her whole job is handling the compiling of features using pde-build. which features, you ask? you can list them either in debian/eclipse.features or straight up on the command line. your choice, no cap. πŸ’…

she's running debhelper behind the scenes, so she's subject to the compat level β€” like, for example, when she's parsing the eclipse.features file. iykyk.

when you're specifying the dependencies for a feature, she'll look and see if that feature has just been compiled, and if it is among the results, she'll use that dependency. 🫢 this is the whole reason she pairs so cutely with debian/eclipse.features.

dependencies are always resolved the same way, in this order:

  1. first she checks if it's a recently built feature
  2. if not, then the system installed eclipse's dropins folders get checked

ngl, here's the messy part: currently jh_compilefeatures does not clean up between builds, which means the dependencies from previous builds are still hanging around for the current build. nevertheless β€” do not rely on this, because this behavior is subject to change. it's giving "don't get attached". 😭

note: jh_compilefeatures will not rearrange the build order for you in order to do any of this. she is not a project manager. she is not going to reorder your to-do list. do it yourself bestie.
note: also she will not error out if she can't find a missing dependency. πŸ’€ that's because the underlying builder is literally unable to detect it. so like, don't expect a crash-out; expect silence. πŸ™ˆ

πŸŽ€ FILES πŸŽ€

  • debian/eclipse.features β€” this is where you list the eclipse features to compile and their dependencies. the first item on the line is the feature to compile, and everything after that on the line is treated as dependencies.

a dependency can either be a dropins folder or a previously built feature. jh_compilefeatures will find it as long as it's installed in the system eclipse's dropins folder, or it has just been compiled. ✨


πŸ‘‘ OPTIONS πŸ‘‘

  • --pde-build-dir=dir β€” tells her which dir to run pde-build from. defaults to debian/.eclipse_build. 🏠
  • --feature-deps=deps β€” a space separated list of deps. these get used to compile all features passed on the command line. features read from debian/eclipse.features? unaffected by this, bestie, they're doing their own thing. πŸ™…β™€οΈ
  • --build-opts=args β€” passes args to the underlying builder. these options get passed to all features built.

defaults to -DjavacTarget=1.5 -DjavacSource=1.5 if you don't set it. and if you want it gone? just pass the empty string. poof. πŸͺ„

  • --jvm-args=args β€” passes args to the JVM. again, these options go to all features built. β˜•
  • --orbit-dir=dir β€” says where the Orbit dependencies can be found. you only need this if the orbit dir is in some unusual location. πŸͺ
  • --pde-build=cmd β€” use a non-standard cmd as the pde-build command to compile the features. go off, custom command. πŸ”₯
  • --pde-args=args β€” passes args directly to pde-build. ⚠️ but heads up: jh_compilefeatures has specialised options for some of pde-build's options, and those should be used whenever possible. these options are passed to all features built.
  • --ignore-java-home β€” skips the check of JAVA_HOME. why does she check at all? because the underlying builder uses ant (and therefore java), so the build should make sure it always uses the expected java implementation. ✨ use this if you (for whatever reason) need to declare the specific java implementation without being able to use JAVA_HOME.
note: you still have to tell the underlying builder which java to use. this flag does not do that for you. πŸ’€

🌈 EXAMPLE 🌈

here's a sample debian/eclipse.features, cute right:

org.eclipse.tm.terminal emf
org.eclipse.rse.sdk

so org.eclipse.tm.terminal depends on emf, which is expected to be found in eclipse's dropins folder. and org.eclipse.rse.sdk? she has no dependencies beyond the eclipse platform. independent queen. πŸ‘‘

and if needed, you can also specify a previously built feature as a dependency:

org.eclipse.some.feature
org.eclipse.another.feature org.eclipse.some.feature rse

here org.eclipse.another.feature depends on org.eclipse.some.feature, which was just built, and also rse, which is expected to be in the system installed eclipse's dropins. slay. πŸ’…


πŸ¦‹ SEE ALSO πŸ¦‹

this program is a part of javahelper and uses debhelper as backend. also, there are tutorials in /usr/share/doc/javahelper. go read them, they're free. πŸ“š


🫢 AUTHOR 🫢

Niels Thykier <niels@thykier.net>


Copyright 2010 by Niels Thykier

this tool is free software; you may redistribute it and/or modify it under the terms of GNU GPL 2.


and that's the whole page bestie!! πŸŽ€ you've been reading version 0.82, dated 2026-05-17, of JH_COMPILEFEATURES(1). drink some water, go compile a feature, and remember: don't rely on the no-cleanup thing, it's literally subject to change. bye bestieee πŸ’–βœ¨πŸŒΈ

πŸ“¦ where this page comes from