Java Reference
In-Depth Information
manifest="org/gjt/sp/jedit/jedit.manifest"
compress="false">
<fileset dir="${build.directory}">
<include name="bsh/**/*.class"/>
<include name="com/**/*.class"/>
<include name="gnu/**/*.class"/>
<include name="org/**/*.class"/>
</fileset>
<fileset dir=".">
<include name="bsh/commands/*.bsh"/>
<include name="gnu/regexp/MessagesBundle.properties"/>
<include name="org/gjt/sp/jedit/**/*.dtd"/>
<include name="org/gjt/sp/jedit/icons/*.gif"/>
<include name="org/gjt/sp/jedit/icons/*.jpg"/>
<include name="org/gjt/sp/jedit/icons/*.png"/>
<include name="org/gjt/sp/jedit/*.props"/>
<include name="org/gjt/sp/jedit/actions.xml"/>
<include name="org/gjt/sp/jedit/browser.actions.xml"/>
<include name="org/gjt/sp/jedit/dockables.xml"/>
<include name="org/gjt/sp/jedit/services.xml"/>
<include name="org/gjt/sp/jedit/default.abbrevs"/>
</fileset>
</jar>
</target>
The jar task is configured to take a static manifest file: org/gjt/sp/jedit/jedit.mani-
fest. If you don't want to change the build process but still want an OSG i-enabled man-
ifest, you can take the jEdit binary, run it through an analyzer like bnd, and add the
generated OSG i headers to this static manifest. As we mentioned back in section 6.1.3,
this approach is fine for existing releases or projects that don't change much. On the
other hand, integrating a tool such as bnd with your build means you get feedback
about the modularity of your application immediately rather than when you try to
deploy it.
REPLACING THE JAR TASK WITH BND
Let's make things more dynamic and generate OSG i metadata during the build. This is
the recommended approach because you don't have to remember to check and regen-
erate the metadata after significant changes to the project source. This is especially use-
ful in the early stages of a project, when responsibilities are still being allocated.
There are several ways to integrate bnd with a build:
Use bnd to generate metadata from classes before creating the JAR file.
Create the JAR file as normal and then post-process it with bnd.
Use bnd to generate the JAR file instead of using the Ant jar task.
If you need certain features of the jar task, such as indexing, you should use the first
or second option. If you're post-processing classes or need to filter resources, choose
either the second or third option. Let's go with the third option to demonstrate how
easy it is to switch your build over to bnd. It will also help you later, in section 6.2.2,
when you start partitioning the application into separate bundles.
Search WWH ::




Custom Search