drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Altekruse (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DRILL-4336) Fix weird interaction between maven-release, maven-enforcer and RAT plugins
Date Mon, 08 Feb 2016 23:47:39 GMT

    [ 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)

Mime
View raw message