Building bundles - OSGi in Action - page 518

■ $(if;condition;true;false) —Evaluates to the true section when the condi-
tion string is empty; otherwise, evaluates to the false section. This macro is
a bit counterintuitive: a condition string of false is treated as true, because
it's non-empty.
■ $(join;list;list;...) —Concatenates a series of comma-separated lists into
one list.
■ $(now) —Evaluates to the current date and time.
■ $(replace;list;regex;replacement) —Replaces any entries in the list that
match the regular expression with the replacement string. As with findname ,
the replacement string can contain references to matched segments.
■ $(sort;list) —Sorts the given comma-separated list according to lexicograph-
ical order.
■ $(toclassname;list) —Replaces entries (such as org/foo/Test.class) with
their class name equivalent (such as org.foo.Test).
■ $(toclasspath;list;extension) —Replaces class names (such as org.foo.Test)
with their path equivalent (such as org/foo/Test.extension).
■ $(version;mask;version) —Takes a version string and alters it according to
the given mask. The mask contains one to four characters, each representing a
segment of the version: major, minor, micro, and qualifier. An = character
means leave the segment unchanged , whereas + or - means increment or decrement the
segment value . Using fewer than four characters truncates the version. As you'll
see in the next section, you can use this macro to automatically create ranges
for any given version.

A.1.5 Choosing a version policy

As we mentioned at the end of section A.1.3, the default policy for generated import
versions is to keep the major and minor segments but drop the rest. Using the resolu-
tion rules from chapter 2, this means the bundle won't resolve against previous incom-
patible releases, but it will continue to resolve against any future release.
If the default version policy isn't for you, you can define your own with the help of
the version macro from the last section, with $(@) representing the detected import
version. To explicitly define the default policy, you write

-versionpolicy: $(version;==;$(@))
The default policy gives you maximum flexibility in the future while stopping the bun-
dle from accidentally resolving against older, incompatible releases. To strengthen the
lower bound further and only accept versions strictly older than the ones you built
and tested against, use the entire version and don't drop any segments:

-versionpolicy: $(@)
What if you want to guard against future breaking changes and exclude future versions
that aren't binary compatible? You can do this by adding an upper bound to the range:

-versionpolicy: [$(version;==;$(@)),$(version;+;$(@)))