Changes

in the XQuery module repository, and how new packages are built and deployed.

One of the reasons why languages such as Java or Perl have been so successful is the vast amount of libraries that are available to developers.

# The [[#EXPath Packaging|EXPath Packaging]] system provides a generic mechanism for adding XQuery modules to query processors. A package is defined as a {{Code|.xar}} archive, which encapsulates one or more extension libraries.

Library modules can be imported with the {{Code|import module}} statement,

</pre>

There are various ways to handle your packages:

You can even manually add and remove packages in the repository directory; all changes will automatically be detected by the query processor.

A module or package can be installed with the {{Code|REPO INSTALL}} command. The path to the file has to be given as a parameter:

The installation will only succeed if the specified file conforms to the constraints described below. If you know that your input is valid, you may as well copy the files directly to the repository directory, or edit its contents in the repository without deleting and reinstalling them.

All currently installed packages can be listed with the <code>REPO LIST</code> command. It will return the names of all packages, their version, and the directory in which they are installed:

1 package(s).

A package can be deleted with the command REPO DELETE and an additional argument, containing its name or the name suffixed with a hyphen and the package version:

REPO DELETE <nowiki>http://www.functx.com-1.0</nowiki>

If an XQuery file is specified as input for the install command, it will be parsed as XQuery library module. If parsing was successful, the module URI will be [[#URI Rewriting|rewritten]] to a file path and attached with the {{Code|.xqm}} file suffix, and the original file will be renamed and copied to that path into the repository.

</pre>

Suitable JAR archives may contain one or more class files. One of them will be chosen as main class, which must be specified in a {{Code|Main-Class}} entry in the manifest file ({{Code|META-INF/MANIFEST.MF}}). This fully qualified Java class name will be rewritten to a file path by replacing the dots with slashes and attaching with the {{Code|.jar}} file suffix, and the original file will be renamed and copied to that path into the repository.

Please be aware that the execution of Java code can cause side effects that conflict with the functional nature of XQuery, or may introduce new security risks. The article on [[Java Bindings]] gives more insight on how Java code is handled from the XQuery processor.

The [http://expath.org/spec/pkg EXPath specification] defines how the structure of a .xar archive shall look like. The package contains at its root a package descriptor named <code>expath-pkg.xml</code>. This descriptor presents some meta data about the package as well as the libraries which it contains and their dependencies on other libraries or processors.

Apart from the package descriptor, a {{Code|.xar}} archive contains a directory which includes the actual XQuery modules. For example, the [http://www.functx.com/ FunctX XQuery Library] is packaged as follows:

</pre>

In case you want to extend BaseX with a Java archive, some additional requirements have to be fulfilled:

On our [http://files.basex.org/modules/ file server], you can find some example libraries packaged as XML archives (xar files). You can use them to try our packaging API or just as a reference for creating your own packages.

If modules are looked up in the repository, their URIs are rewritten to a local file path. The URI transformation has been inspired by [http://www.zorba.io/documentation/3.0/zorba/architecture/uriresolvers Zorba]:

* {{Code|a:b:c}} → not supported (''no path component'')

;Version 7.2.1