artemis-plugin
Used in:
components
- OverviewOverview
- VersionsVersions
- DependentsDependents
- DependenciesDependencies
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-plugin</artifactId>
<version>2.39.0</version>
</dependency><?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-hawtio-pom</artifactId>
<version>2.39.0</version>
</parent>
<artifactId>artemis-plugin</artifactId>
<name>ActiveMQ Artemis HawtIO Plugin</name>
<description>Artemis plugin module for the HawtIO web console</description>
<!-- hawtio plugins are almost always war files -->
<packaging>war</packaging>
<properties>
<activemq.basedir>${project.basedir}/../..</activemq.basedir>
<!-- filtered plugin properties, we don't define plugin-scripts here
as we build that dynamically using maven-antrun-plugin below. -->
<!-- plugin-context is what context this plugin will handle requests on
in the application server -->
<plugin-context>/artemis-plugin</plugin-context>
<!-- plugin-name is the name of our plugin, affects the name used for
the plugin's mbean -->
<plugin-name>${project.artifactId}</plugin-name>
<!-- plugin-domain is currently unused, we just define it to an empty
string -->
<plugin-domain />
<!-- this lets this plugin deploy nicely into karaf, these get used
for the ImportPackage directive for maven-bundle-plugin -->
<osgi.import>
javax.servlet;version="2.6",
*;resolution:=optional
</osgi.import>
<webapp-dir>${project.artifactId}-${project.version}</webapp-dir>
<webapp-outdir>${basedir}/target/${webapp-dir}</webapp-outdir>
<schema-outdir>${basedir}/src/main/webapp/lib</schema-outdir>
<appjs-outfile>${webapp-outdir}/app/app.js</appjs-outfile>
</properties>
<dependencies>
<!-- we only need to embed this dependency in the war, this contains
a nice helper class that our plugin can use to export it's plugin
mbean -->
<dependency>
<groupId>io.hawt</groupId>
<artifactId>hawtio-plugin-mbean</artifactId>
</dependency>
<!-- servlet API is provided by the container -->
<dependency>
<groupId>org.eclipse.jetty.toolchain</groupId>
<artifactId>jetty-servlet-api</artifactId>
<scope>provided</scope>
</dependency>
<!-- logging -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<!-- we want to ensure src/main/resources/WEB-INF/web.xml is being filtered
so that it picks up all of our javascript files -->
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
<plugins>
<!-- We use maven-antrun-plugin to build up a list of
javascript files for our plugin mbean, this means
it needs to run before the maven-resources-plugin
copies and filters the web.xml, since for this
example we use contextParam settings to configure
our plugin mbean -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<!-- we run this early in the build process before
maven-resources-plugin is run. We're exporting the
plugin-scripts property from here, so we need to
use maven-antrun-plugin 1.6 or up -->
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo>Building plugin javascript file list</echo>
<!-- javascript-files will contain all of the javascript in
our project -->
<fileset id="javascript-files" dir="${basedir}/src/main/webapp">
<include name="**/*.js" />
</fileset>
<!-- we need to strip out the top level path which is
our source directory and be sure to change the directory
separators to forward slashes -->
<pathconvert pathsep="," dirsep="/" property="plugin-scripts" refid="javascript-files">
<map from="${basedir}/src/main/webapp/" to="" />
</pathconvert>
<echo>Files: ${plugin-scripts}</echo>
</target>
<!-- this exports plugin-scripts to the maven build, without
this line ${plugin-scripts} in the web.xml file won't be
replaced -->
<exportAntProperties>true</exportAntProperties>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<!-- defining this maven plugin in the same phase as the
maven-antrun-plugin but *after* we've configured the
maven-antrun-plugin ensures we filter resources *after*
we've discovered the plugin .js files. -->
<id>copy-resources</id>
<phase>generate-sources</phase>
<goals>
<goal>resources</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- maven-bundle-plugin config, needed to make this war
deployable in karaf, defines the context that this bundle
should handle requests on -->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
<configuration>
<manifestLocation>${webapp-outdir}/META-INF</manifestLocation>
<supportedProjectTypes>
<supportedProjectType>jar</supportedProjectType>
<supportedProjectType>bundle</supportedProjectType>
<supportedProjectType>war</supportedProjectType>
</supportedProjectTypes>
<instructions>
<Webapp-Context>${plugin-context}</Webapp-Context>
<Web-ContextPath>${plugin-context}</Web-ContextPath>
<Embed-Directory>WEB-INF/lib</Embed-Directory>
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
<Export-Package>${osgi.export}</Export-Package>
<Import-Package>${osgi.import}</Import-Package>
<DynamicImport-Package>${osgi.dynamic}</DynamicImport-Package>
<Private-Package>${osgi.private.pkg}</Private-Package>
<Bundle-ClassPath>.,WEB-INF/classes</Bundle-ClassPath>
<Bundle-Name>${project.name}</Bundle-Name>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Implementation-Title>HawtIO</Implementation-Title>
<Implementation-Version>${project.version}</Implementation-Version>
</instructions>
</configuration>
</plugin>
<!-- We define the maven-war-plugin here and make sure it uses
the manifest file generated by the maven-bundle-plugin. We
also ensure it picks up our filtered web.xml and not the one
in src/main/resources -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<outputFileNameMapping>@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@</outputFileNameMapping>
<packagingExcludes>**/classes/OSGI-INF/**</packagingExcludes>
<failOnMissingWebXml>false</failOnMissingWebXml>
<archive>
<manifestFile>${webapp-outdir}/META-INF/MANIFEST.MF</manifestFile>
</archive>
<webResources>
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
<includes>
<include>**/*.*</include>
</includes>
<excludes>
<exclude>log4j.properties</exclude>
</excludes>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</build>
</project>
Open source consumption has exploded, with estimates placing this year’s downloads at over 6.6 trillion. This reliance on open source components, now making up to 90% of the modern software application, has ushered in both unprecedented innovation and complex challenges for software supply chains.
View the Report