Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Mon, 8 Feb 2016 23:47:39 +0000 (UTC)
From: "Jason Altekruse (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.12935755.1454361125000.333969.1454975259781@Atlassian.JIRA>
In-Reply-To: <JIRA.12935755.1454361125000@Atlassian.JIRA>
References: <JIRA.12935755.1454361125000@Atlassian.JIRA>
 <JIRA.12935755.1454361125652@arcas>
Subject: [jira] [Comment Edited] (DRILL-4336) Fix weird interaction between
 maven-release, maven-enforcer and RAT plugins
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DRILL-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138022#comment-15138022 ] 

Jason Altekruse edited comment on DRILL-4336 at 2/8/16 11:47 PM:
-----------------------------------------------------------------

Update on this issue: after more investigation the real cause of the problem was determined to be the maven shade plugin. As a part of shading, a list of dependencies to exclude from the jdbc-all.jar is applied to make it smaller.

The resulting jar is expected to require no external dependencies, everything needed should be bundled within it and shaded to avoid conflicts with any shared dependencies used by a client application. To express the changed list of dependencies the plugin generates a dependency-reduced-pom.xml file, which contains an empty list of dependencies.

The issue came about with the location chosen for this new pom file. By default the shade plugin puts the file in the module root, which violates a maven design principle of keeping generated files in the 'target' directory, so that they will be cleared upon a 'mvn clean'. This is considered a known limitation of the shade plugin as stated here https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation. We had tried to follow best practices by overriding the default location and putting it in target.

Unfortunately this seemed to have a weird interaction with the maven-enforcer plugin added to enforce the JAR size, and the release maven profile. With the newly generated pom file in a directory below the jdbc-all module, maven was trying to run the 'target' directory as a submodule. This failed initially with a complaint that the newly-generated POM was lacking an apache header (from RAT), but beyond this the target directory is not going to be structured properly to run as a maven module and it isn't supposed to be. It hasn't been completely investigated to determine why this only happened when running the release profile.

The fix applied on the 1.5 release branch for this issue was to move the file back to it's default (but maven convention breaking) location. As part of the change the file needed to be added to the .gitignore and RAT files, as it was no longer excluded from either of these simply by being inside of a 'target' directory.


was (Author: jaltekruse):
Update on this issue: after more investigation the real cause of the problem was determined to be the maven shade plugin. As a part of shading, a list of dependencies to exclude from the jdbc-all.jar is applied to make it smaller.

The resulting jar is expected to require no external dependencies, everything needed should be bundled within it and shaded to avoid conflicts with any shared dependencies used by a client application. To express the changed list of dependencies the plugin generates a dependency-reduced-pom.xml file, which contains an empty list of dependencies.

The issue came about with the location chosen for this new pom file. By default the shade plugin puts the file in the module root, which violates a maven design principle of keeping generated files in the 'target' directory, so that they will be cleared upon a 'mvn clean'. This is considered a known limitation of the shade plugin as stated here https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation. We had tried to follow best practices by overriding the default location and putting it in target.

Unfortunately this seemed to have a weird interaction with the maven-enforcer plugin added to enforce the JAR size, and the release maven profile. With the newly generated pom file in a directory below the jdbc-all module, maven was trying to run the 'target' directory as a submodule. This failed initially with a complaint that the newly-generated POM was lacking an apache header (from RAT), but beyond this the target directory is not going to be structure properly to run as a maven module and it isn't supposed to be. It hasn't been completely investigated to determine why this only happened when running the release profile.

The fix applied on the 1.5 release branch for this issue was to move the file back to it's default (but maven convention breaking) location. As part of the change the file needed to be added to the .gitignore and RAT files, as it was no longer excluded from either of these simply by being inside of a 'target' directory.

> Fix weird interaction between maven-release, maven-enforcer and RAT plugins
> ---------------------------------------------------------------------------
>
>                 Key: DRILL-4336
>                 URL: https://issues.apache.org/jira/browse/DRILL-4336
>             Project: Apache Drill
>          Issue Type: Bug
>            Reporter: Jason Altekruse
>
> While trying to make the 1.5.0 release I ran into a bizarre failure from RAT complaining about a file it should have been ignoring according to the plugin configuration.
> Disabling the newly added maven-enforcer plugin "fixed" the issue, but we need to keep this in the build to make sure new dependencies don't creep into the JDBC driver that is supposed to be as small as possible.
> For the sake of the release the jdbc-all jar's size was checked manually.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)