drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinfeng Ni <...@apache.org>
Subject Re: Contrib module not in root pom.xml?
Date Wed, 12 Sep 2018 02:26:38 GMT
Looking at the code change history, seems it's DRILL-1548 that removes
'contrib' models, and put it under 'build-contrib" profile.

1. https://issues.apache.org/jira/browse/DRILL-1548
2.
https://github.com/apache/drill/commit/a8b309a792dae2c85d5fa4d368136cd6e45178ea

On Tue, Sep 11, 2018 at 6:21 PM Paul Rogers <par0328@yahoo.com.invalid>
wrote:

> Hi All,
>
> I'm hoping someone can explain a mystery in the root pom.xml file. We have
> a list of modules:
>
>   <modules>
>     <module>tools</module>
>     <module>protocol</module>
>     <module>common</module>
>     <module>logical</module>
>     <module>exec</module>
>     <module>drill-yarn</module>
>     <module>distribution</module>
>   </modules>
>
> Note that contrib is not part of this list. The result is that, in a
> normal build, the contrib module gets built *after* we build the
> distribution. This is probably the problem that Charles asked about a week
> or so ago.
>
> [INFO] Packaging and Distribution Assembly ................ SUCCESS [
> 32.665 s]
> [INFO] contrib/sqlline .................................... SUCCESS [
>  1.525 s]
> [INFO] contrib/regex-format-plugin ........................ SUCCESS [
>  3.691 s]
> [INFO] BUILD SUCCESS
>
>
> In the above, "regex-format-plugin" is the example plugin I'm trying to
> build. Note it is built *after* we build the output directory.
>
> Seems the solution is to work around the missing dependency by adding an
> explicit dependency to the distribution pom.xml file. This works, but seems
> broken somehow. Also, do we want sqlline to be built *after* we build the
> output directory?
>
> Further, it seems we do all this so we can have a separate "build-contrib"
> profile. Yet, the contrib directories are always built because of the
> forced dependency via distribution.
>
> Is this design intentional? Should we fix it? Unless someone can explain
> why this is a "feature", I'll file a JIRA that claims it is a "bug."
>
> Thanks,
> - Paul
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message