Date: Fri, 29 Mar 2024 09:18:13 +0000 (UTC) Message-ID: <255069042.9.1711703893366@9c244d5e6733> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8_1880795010.1711703893366" ------=_Part_8_1880795010.1711703893366 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Fabric3 applications are packaged in one or more contributions.= The following contribution formats are supported:
Most SCA applications will be packaged as one or more JARs, which contai=
n application classes and artifacts. A JAR contribution requires an contribution manifest file (sca-contribut=
ion.xml ) in the META-INF
directory.
Fabric3 supports two ways of pac=
kaging and deploying libraries used by a contribution: embedding them in th=
e JAR; and importing them from another contribution. Similar to WARs, Fabri=
c3 allows contribution JARs to bundle libraries by placing their JARs in th=
e META-INF/lib
directory, which in turn will be made avai=
lable on the contribution classpath. Imports are discussed in The Contribution Manifest.
Fabric3 supports packaging contributions as WAR files. WAR contributions=
behave like JAR contributions except the SCA manifest in is placed in =
;WEB-INF
. In addition, libraries and classes in WEB=
-INF/lib
and WEB-INF/classes
respectively are plac=
ed on the contribution classpath. WAR contributions are used for deploying =
web applications to a domain.
ZIP contributions are identical to JAR= contributions.
Fabric3 also supports packaging contributions as OSGi bundles. In this c= ase, OSGi bundle manifests may be used to export and import packages from o= ther contributions. An SCA manifest file is not required.
Note Export-Package and Import-Package OSGi manifest headers are support= ed in a limited fashion. Specifically, attribute directives are not support= ed.
Fabric3 supports XML documents such as configuration files.
Contributions will often use third-party libraries. These libraries may = be packaged and deployed as separate contributions, which are then imported= into the using contribution via OSGi directives (see Contribution Modularity). The downside of this approach is th= at deployment is more complex since an application is spread across multipl= e archives. For applications that do not need this degree of modularity, Fa= bric3 provides Gradle and Maven plugins for packaging third-party libr= aries within the contribution that uses them.
The contribution plugin follows the same model as web application archiv=
es (WARs): it includes third-party library jars in META-INF/lib<=
/code>. At deployment, these libraries will be placed on the contribution c=
lasspath, thereby making them available to code bundled in the contribution=
.