Custom Plugin that require external libs


(Gianluca Valentini) #1

Hi guys,
I’m developing a new Plugin that require a my internal project client lib to OrientDB for connection (generically say an external lib).
I don’t want to duplicate my code.

What is the best practice to built this plugin?
Create a jar including the extenal lib? If yes, how to manage manifest conflicts?

Otherwise, is there a possibility to set the classpath during graylog startup to set a folder to place that external libs?

To complete my scenario I need to tell you that I’m using a Docker Graylog instance


(Jochen) #2

See http://docs.graylog.org/en/2.4/pages/plugins.html.


(Gianluca Valentini) #3

So the best way is to use webpack.vendor.js for each common libs that I want to use.
Thanks

Can you give me an example of it? Image that I need to use bouncycastle, what I should do?
Using maven I know:

<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-ext-jdk16</artifactId>

Create a file named webpack.org.bouncycastle?
Can you help me please?

Thanks a lot


(Jochen) #4

Webpack is only used for the browser/web parts of the plugin. The Java/JVM code itself is still being built by Maven or Gradle or whatever build system you’re using.


(Gianluca Valentini) #5

Ok Thanks.
I’m using maven.

In this case I don’t understand how I need to create my plugin that use external libs without Manifest conflicts.
Can you explain me hot to do it?

Still now I always create a unique jar with all classes in it using

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.1.0</version>

maven plugin. But if I include some libs, for example bouncycalste, I have errors on plugin deploy because my plugin jar contains RSA files.

For this reason I thought that maybe I wrong something in my development

Can you help me?


(Jochen) #6

Normally, you would use dependency exclusions in the Maven dependency declarations or in the Maven Shade configuration.

As for signed JARs, you’ll have to strip the signatures before building the fat JAR:
https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html

Do you have a specific example?


(Gianluca Valentini) #7

Yes,
In my plugin I need to have a dependency coming from my local project.
After adding it as dependency a needed to exclude elasticseach because in my plugin jar I found ECLIPSE.RSA file causing deployng fail.
So I needed to exclude some elasticseach lib from my external project dependency.

    <exclusion>
		<groupId>org.elasticsearch</groupId>
		<artifactId>elasticsearch</artifactId>
	</exclusion>
	<exclusion>
		<groupId>org.elasticsearch.client</groupId>
		<artifactId>transport</artifactId>
	</exclusion>

So, is this the correct way to build it?

here the plugin that I use to generate the Graylog Plugin

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-shade-plugin</artifactId>
			<version>3.1.0</version>
			<configuration>
				<minimizeJar>false</minimizeJar>
			</configuration>
			<executions>
				<execution>
					<phase>package</phase>
					<goals>
						<goal>shade</goal>
					</goals>
					<configuration>
						<transformers>
							<transformer
								implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
						</transformers>
					</configuration>
				</execution>
			</executions>
		</plugin>

	</plugins>
</build>

This is the only plugin that I use in my pom

Do you have some tips for me?

Thanks


(Gianluca Valentini) #8

Hi @jochen,
looking your link I added

  <filters>
      <filter>
        <artifact>*:*</artifact>
        <excludes>
          <exclude>META-INF/*.SF</exclude>
          <exclude>META-INF/*.DSA</exclude>
          <exclude>META-INF/*.RSA</exclude>
        </excludes>
      </filter>
  </filters>

in my plugin configuration and now the DSA, RSA and SF file are excluded from my plugin jar.

I will try to deploy the plugin to understand if I fixed the manifest problems.

So from what I understand, the correct plugin generation approach is to create an unique jar with all dependencies in it. Is this correct for you?

Thanks
Gianluca


(Jochen) #9

Yes, that’s the current approach.


(Gianluca Valentini) #10

Thanks a lot @jochen

you’ve been really helpful for me
Thanks again

Gianluca


(system) #11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.