dweiss commented on a change in pull request #1905: URL: https://github.com/apache/lucene-solr/pull/1905#discussion_r498666120
########## File path: lucene/packaging/build.gradle ########## @@ -0,0 +1,160 @@ +/* + * 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. + */ + +// This project puts together a "distribution", assembling dependencies from +// various other projects. + +plugins { + id 'distribution' +} + +description = 'Lucene distribution packaging' + +// Declare all subprojects that should be included in binary distribution. +// By default everything is included, unless explicitly excluded. +def includeInBinaries = project(":lucene").subprojects.findAll {subproject -> + return !(subproject.path in [ + ":lucene:packaging", + ":lucene:analysis", + ":lucene:luke", // nocommit - Encountered duplicate path "luke/lib/log4j-core-2.13.2.jar" Review comment: This wasn't obvious. Here's what happened. We create a configuration with dependency on "full project", it looked like this: ``` handler.add(confFull, project(path: includedProject.path), {... ``` This in fact is a dependency on the configuration aptly named 'default', which includes all of project binaries and transitive dependencies (archives in general). Luke declared a separate configuration for dependencies called 'standalone' which added a few non-project dependencies (the 'implementation' extended from it so they were visible on runtime classpath). The core of the problem was in that luke also exported an extra artifact that belonged to this 'standalone' configuration - this was a set of JARs assembled under a folder. So when the packaging process was collecting files for inclusion, it encountered log4j twice: a copy in that 'standalone' folder and a copy from transitive project dependencies. I recall you asked why this 'fail' on double archive entries is needed. Well, it's useful to catch pearls like this one above... ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
