There's 2 changes here (they can be split into 2 PRs if needed):
1. avoid shadow-ing dependencies
the shadow repackages dependencies into the logstash-input-tcp-X.Y.Z.jar, meaning e.g. classes from netty-all-4.1.65.Final.jar will all end up as part of the plugin jar on $CLASSPATH. this is bad and if we would to have any kind of feature detection based on a class present would lead to issues:
here's what happens when 2 plugins load the same dependency (one shadowed):
require_jar('io.netty', 'netty-all', '4.1.65.Final') and require_jar('org.logstash.plugins.input.http', 'logstash-input-http', '3.4.2') we end up with 2 jars on the $CLASSPATH
require_jar('org.logstash.inputs', 'logstash-input-tcp', '6.2.5') adds one jar to the $CLASSPATH that contains either the same or a different version of classes already loaded (depending on whether Netty version is the same)
after shadowing removed here's what happens:
require_jar('io.netty', 'netty-all', '4.1.65.Final') and require_jar('org.logstash.plugins.input.http', 'logstash-input-http', '3.4.2') we end up with 2 jars on the $CLASSPATH
require_jar('io.netty', 'netty-all', '4.1.65.Final') and require_jar('org.logstash.inputs', 'logstash-input-tcp', '6.2.5') will only add the later to the $CLASSPATH (even if netty's version was different jar-dependencies only loads one dependency with the same name)
2. make log4j-api a 'provided' dependency
the log4j-api should be considered a transitive dependency of logstash-core.
we need the log4j-api jar for compiling but should not package the .jar into the plugin - LS lacks abstraction of custom logger impl for Java plugins thus the log4j-api should simply be considered a provided dependency.
There's 2 changes here (they can be split into 2 PRs if needed):
1. avoid shadow-ing dependencies
the shadow repackages dependencies into the
logstash-input-tcp-X.Y.Z.jar, meaning e.g. classes fromnetty-all-4.1.65.Final.jarwill all end up as part of the plugin jar on$CLASSPATH. this is bad and if we would to have any kind of feature detection based on a class present would lead to issues:here's what happens when 2 plugins load the same dependency (one shadowed):
require_jar('io.netty', 'netty-all', '4.1.65.Final')andrequire_jar('org.logstash.plugins.input.http', 'logstash-input-http', '3.4.2')we end up with 2 jars on the$CLASSPATHrequire_jar('org.logstash.inputs', 'logstash-input-tcp', '6.2.5')adds one jar to the$CLASSPATHthat contains either the same or a different version of classes already loaded (depending on whether Netty version is the same)after shadowing removed here's what happens:
require_jar('io.netty', 'netty-all', '4.1.65.Final')andrequire_jar('org.logstash.plugins.input.http', 'logstash-input-http', '3.4.2')we end up with 2 jars on the$CLASSPATHrequire_jar('io.netty', 'netty-all', '4.1.65.Final')andrequire_jar('org.logstash.inputs', 'logstash-input-tcp', '6.2.5')will only add the later to the$CLASSPATH(even if netty's version was different jar-dependencies only loads one dependency with the same name)2. make log4j-api a 'provided' dependency
the log4j-api should be considered a transitive dependency of
logstash-core. we need thelog4j-apijar for compiling but should not package the .jar into the plugin - LS lacks abstraction of custom logger impl for Java plugins thus the log4j-api should simply be considered a provided dependency.