honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/qa/smoke-test-plugins/pom.xml

479 lines
17 KiB
XML
Raw Normal View History

Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.elasticsearch.qa</groupId>
<artifactId>elasticsearch-qa</artifactId>
Move version to 3.0.0-SNAPSHOT
2015-09-03 04:43:28 -04:00
<version>3.0.0-SNAPSHOT</version>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
</parent>
<!--
This test unzips elasticsearch, installs each plugin,
starts elasticsearch, verifies loaded plugin count.
"expected plugin count" is computed from plugins/,
currently any folder having a pom.xml file.
our yaml file uses property filtering to populate it.
-->
<artifactId>smoke-test-plugins</artifactId>
<name>QA: Smoke Test Plugins</name>
<description>Loads up all of our plugins</description>
<properties>
<skip.unit.tests>true</skip.unit.tests>
<elasticsearch.integ.antfile>${project.basedir}/integration-tests.xml</elasticsearch.integ.antfile>
<tests.rest.suite>smoke_test_plugins</tests.rest.suite>
<tests.rest.load_packaged>false</tests.rest.load_packaged>
</properties>
Add basic tests for sharded JAR this commit adds a simple integration test that starts a node from a shaded jar, indexes a doc and retrieves it. It also has some basic unittests that try to load shaded classes and ensure that their counterpart is not in the classpath. Closes #12711
2015-08-07 08:14:33 -04:00
<dependencies>
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<type>test-jar</type>
<scope>test</scope>
</dependency>
<!-- Provided dependencies by elasticsearch itself -->
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-backward-codecs</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-analyzers-common</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-queries</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-memory</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-highlighter</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-queryparser</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-suggest</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-join</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-spatial</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-expressions</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.spatial4j</groupId>
<artifactId>spatial4j</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.vividsolutions</groupId>
<artifactId>jts</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.github.spullara.mustache.java</groupId>
<artifactId>compiler</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.carrotsearch</groupId>
<artifactId>hppc</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.joda</groupId>
<artifactId>joda-convert</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-smile</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-yaml</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-cbor</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.ning</groupId>
<artifactId>compress-lzf</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.tdunning</groupId>
<artifactId>t-digest</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<classifier>indy</classifier>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>apache-log4j-extras</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<scope>provided</scope>
</dependency>
<!-- Required by the REST test framework -->
<!-- TODO: remove this dependency when we will have a REST Test module -->
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>integ-setup-dependencies</id>
<phase>pre-integration-test</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
cleanup skipping everywhere
2015-08-05 21:45:09 -04:00
<skip>${skip.integ.tests}</skip>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<useBaseVersion>true</useBaseVersion>
<outputDirectory>${integ.deps}/plugins</outputDirectory>
<artifactItems>
<!-- elasticsearch distribution -->
<artifactItem>
<groupId>org.elasticsearch.distribution.zip</groupId>
<artifactId>elasticsearch</artifactId>
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
<outputDirectory>${integ.deps}</outputDirectory>
</artifactItem>
<!-- plugins -->
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>analysis-icu</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>analysis-kuromoji</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>analysis-phonetic</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>analysis-smartcn</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>analysis-stempel</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[cloud-azure] Split azure plugin in 3 plugins Until now we had a cloud-azure plugin which is providing 3 distinct features: * discovery on Azure * snapshot/restore on Aure * SMB store This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-09-03 13:12:52 -04:00
<artifactId>cloud-gce</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[cloud-azure] Split azure plugin in 3 plugins Until now we had a cloud-azure plugin which is providing 3 distinct features: * discovery on Azure * snapshot/restore on Aure * SMB store This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-09-03 13:12:52 -04:00
<artifactId>delete-by-query</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[cloud-azure] Split azure plugin in 3 plugins Until now we had a cloud-azure plugin which is providing 3 distinct features: * discovery on Azure * snapshot/restore on Aure * SMB store This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-09-03 13:12:52 -04:00
<artifactId>discovery-azure</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>discovery-ec2</artifactId>
Add multicast plugin to help and qa
2015-08-21 01:04:17 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
<artifactId>discovery-multicast</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>lang-javascript</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>lang-python</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
Move the `murmur3` field to a plugin and fix defaults. This move the `murmur3` field to the `mapper-murmur3` plugin and fixes its defaults so that values will not be indexed by default, as the only purpose of this field is to speed up `cardinality` aggregations on high-cardinality string fields, which only requires doc values. I also removed the `rehash` option from the `cardinality` aggregation as it doesn't bring much value (rehashing is cheap) and allowed to remove the coupling between the `cardinality` aggregation and the `murmur3` field. Close #12874
2015-08-17 06:47:14 -04:00
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[maven] change murmur3 plugin groupId and name
2015-08-18 07:43:10 -04:00
<artifactId>mapper-murmur3</artifactId>
Move the `murmur3` field to a plugin and fix defaults. This move the `murmur3` field to the `mapper-murmur3` plugin and fixes its defaults so that values will not be indexed by default, as the only purpose of this field is to speed up `cardinality` aggregations on high-cardinality string fields, which only requires doc values. I also removed the `rehash` option from the `cardinality` aggregation as it doesn't bring much value (rehashing is cheap) and allowed to remove the coupling between the `cardinality` aggregation and the `murmur3` field. Close #12874
2015-08-17 06:47:14 -04:00
<version>${elasticsearch.version}</version>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[maven] rename artifactIds from `elasticsearch-something` to `something` In plugins, we are using non consistent naming. We use `elasticsearch-cloud-aws` as the artifactId, which generates a jar file called `elasticsearch-cloud-aws-VERSION.jar`. But when you want to install the plugin, you will end up with a shorter name for the plugin `cloud-aws`. ``` bin/plugin install cloud-aws ``` This commit changes that and use consistent names for `artifactId`, so `finalName`. Also changed maven names.
2015-08-14 10:52:55 -04:00
<artifactId>mapper-size</artifactId>
Move the `_size` mapper to a plugin. This is one of our esoteric metadata mappers so I think we should distribute it in a plugin rather than in elasticsearch core. This introduces one limitation: the value of the `_size` parameter is not retrievable for documents that are only in the transaction log.
2015-07-31 12:22:37 -04:00
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
[cloud-azure] Split azure plugin in 3 plugins Until now we had a cloud-azure plugin which is providing 3 distinct features: * discovery on Azure * snapshot/restore on Aure * SMB store This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-09-03 13:12:52 -04:00
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
<artifactId>repository-azure</artifactId>
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
Move the `_size` mapper to a plugin. This is one of our esoteric metadata mappers so I think we should distribute it in a plugin rather than in elasticsearch core. This introduces one limitation: the value of the `_size` parameter is not retrievable for documents that are only in the transaction log.
2015-07-31 12:22:37 -04:00
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<artifactId>repository-s3</artifactId>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<version>${elasticsearch.version}</version>
This method on settings loaded a class, based on a setting value, using the default classloader. It had all kinds of leniency in how the classname was found, and simply cannot work with plugins having isolated classloaders. This change removes that method. Some of the uses of it were for custom extension points, like custom repository or discovery types. A lot were just there to plugin mock implementations for tests. For the settings that were legitimate, all now support plugins adding the given setting via onModule. For those that were specific to tests for mocks, they now use Classes.loadClass (a helper around Class.forName). This is a temporary measure until (in a future PR) tests can change the implementation via package private statics. I also removed a number of unnecessary intermediate modules, added a "jvm-example" plugin that can be filled in in the future as a smoke test for breaking plugins, and gave some documentation to "spawn" modules interface. closes #12643 closes #12656
2015-08-10 17:04:45 -04:00
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
[cloud-azure] Split azure plugin in 3 plugins Until now we had a cloud-azure plugin which is providing 3 distinct features: * discovery on Azure * snapshot/restore on Aure * SMB store This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-09-03 13:12:52 -04:00
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
<artifactId>store-smb</artifactId>
<version>${elasticsearch.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<!-- Internal plugins for test purpose only -->
This method on settings loaded a class, based on a setting value, using the default classloader. It had all kinds of leniency in how the classname was found, and simply cannot work with plugins having isolated classloaders. This change removes that method. Some of the uses of it were for custom extension points, like custom repository or discovery types. A lot were just there to plugin mock implementations for tests. For the settings that were legitimate, all now support plugins adding the given setting via onModule. For those that were specific to tests for mocks, they now use Classes.loadClass (a helper around Class.forName). This is a temporary measure until (in a future PR) tests can change the implementation via package private statics. I also removed a number of unnecessary intermediate modules, added a "jvm-example" plugin that can be filled in in the future as a smoke test for breaking plugins, and gave some documentation to "spawn" modules interface. closes #12643 closes #12656
2015-08-10 17:04:45 -04:00
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
[maven] rename artifactIds from `elasticsearch-something` to `something` In plugins, we are using non consistent naming. We use `elasticsearch-cloud-aws` as the artifactId, which generates a jar file called `elasticsearch-cloud-aws-VERSION.jar`. But when you want to install the plugin, you will end up with a shorter name for the plugin `cloud-aws`. ``` bin/plugin install cloud-aws ``` This commit changes that and use consistent names for `artifactId`, so `finalName`. Also changed maven names.
2015-08-14 10:52:55 -04:00
<artifactId>jvm-example</artifactId>
This method on settings loaded a class, based on a setting value, using the default classloader. It had all kinds of leniency in how the classname was found, and simply cannot work with plugins having isolated classloaders. This change removes that method. Some of the uses of it were for custom extension points, like custom repository or discovery types. A lot were just there to plugin mock implementations for tests. For the settings that were legitimate, all now support plugins adding the given setting via onModule. For those that were specific to tests for mocks, they now use Classes.loadClass (a helper around Class.forName). This is a temporary measure until (in a future PR) tests can change the implementation via package private statics. I also removed a number of unnecessary intermediate modules, added a "jvm-example" plugin that can be filled in in the future as a smoke test for breaking plugins, and gave some documentation to "spawn" modules interface. closes #12643 closes #12656
2015-08-10 17:04:45 -04:00
<version>${elasticsearch.version}</version>
[plugin] split cloud-aws in repository-s3 and discovery-ec2 Until now we had a cloud-aws plugin which is providing 2 disctinct features: * discovery on EC2 * snapshot/restore on S3 This commit splits the plugin by feature so people can use either one or the other or both features. Doc is updated accordingly.
2015-08-24 18:10:20 -04:00
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
<artifactItem>
<groupId>org.elasticsearch.plugin</groupId>
<artifactId>site-example</artifactId>
<version>${elasticsearch.version}</version>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<type>zip</type>
<overWrite>true</overWrite>
</artifactItem>
Move the `_size` mapper to a plugin. This is one of our esoteric metadata mappers so I think we should distribute it in a plugin rather than in elasticsearch core. This introduces one limitation: the value of the `_size` parameter is not retrievable for documents that are only in the transaction log.
2015-07-31 12:22:37 -04:00
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<!-- integration tests -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>count-expected-plugins</id>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<property name="plugins.dir" location="${project.basedir}/../../plugins"/>
<resourcecount property="expected.plugin.count">
<fileset dir="${plugins.dir}" includes="*/pom.xml"/>
</resourcecount>
<echo>Found ${expected.plugin.count} plugins in ${plugins.dir}</echo>
</target>
<exportAntProperties>true</exportAntProperties>
</configuration>
</execution>
<!-- start up external cluster -->
<execution>
<id>integ-setup</id>
<phase>pre-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<ant antfile="${elasticsearch.integ.antfile}" target="start-external-cluster-with-plugins">
Support jenkins randomization in integration tests
2015-08-06 14:48:27 -04:00
<property name="tests.jvm.argline" value="${tests.jvm.argline}"/>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
<property name="plugins.dir" value="${plugins.dir}"/>
<property name="expected.plugin.count" value="${expected.plugin.count}"/>
</ant>
</target>
cleanup skipping everywhere
2015-08-05 21:45:09 -04:00
<skip>${skip.integ.tests}</skip>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
</configuration>
</execution>
<!-- shut down external cluster -->
<execution>
<id>integ-teardown</id>
<phase>post-integration-test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<ant antfile="${elasticsearch.integ.antfile}" target="stop-external-cluster"/>
</target>
cleanup skipping everywhere
2015-08-05 21:45:09 -04:00
<skip>${skip.integ.tests}</skip>
Get plugin smoketester running in jenkins. We have a smoke_test_plugins.py, but its a bit slow, not integrated into our build, etc. I converted this into an integration test. It is definitely uglier but more robust and fast (e.g. 20 seconds time to verify). Also there is refactoring of existing integ tests logic, like printing out commands we execute and stuff
2015-08-05 20:24:36 -04:00
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>ant-contrib</groupId>
<artifactId>ant-contrib</artifactId>
<version>1.0b3</version>
<exclusions>
<exclusion>
<groupId>ant</groupId>
<artifactId>ant</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.ant</groupId>
<artifactId>ant-nodeps</artifactId>
<version>1.8.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>