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