[
https://issues.apache.org/jira/browse/HADOOP-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472842#comment-13472842
]
Colin Patrick McCabe commented on HADOOP-8887:
----------------------------------------------
bq. plugin root package should be org.apache.hadoop if in Hadoop.
OK.
bq. source directory should be settable via an 'source' property which defaults
to ${basedir}/src/main/native
It is, via GenerateMojo#source
bq. build directory should be settable via an 'outputDirectory' property which
defaults to ${project.build.directory}/native if not set.
It is, via GenerateMojo#output and CompileMojo#output.
bq. what is the diff between the output and target params in the CompileMojo?
Do we need both? see prev comment on naming.
"Build target" would be something like Debug, Production, etc. "output" is a
directory. I will add a comment explaining this.
bq. CleanMojo, why do we need this one? 'mvn clean' already takes care of it.
'mvn clean' will delete the 'target' directory, but we don't enforce the
concept that the CMake-ng output directory is inside that directory. We could
enforce this, and then make get rid of the clean target? However, we also
might need this for when we're supporting Windows, maybe?
bq. what is the diff between cmake-generate and cmake-compile? Do we need 2
different Mojos? Do we gain something from it?
cmake-generate runs the cmake application to create the Makefiles.
cmake-compile actually runs Make on these generated files. It seems natural to
separate these two steps. However, I don't have a specific reason why it has
to be implemented this way -- we could combine both steps into one. I was
trying to go with the spirit of Maven, which separates code generation and
compilation.
> Use a Maven plugin to build the native code using CMake
> -------------------------------------------------------
>
> Key: HADOOP-8887
> URL: https://issues.apache.org/jira/browse/HADOOP-8887
> Project: Hadoop Common
> Issue Type: Improvement
> Components: build
> Affects Versions: 2.0.3-alpha
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Priority: Minor
> Attachments: HADOOP-8887.001.patch, HADOOP-8887.002.patch,
> HADOOP-8887.003.patch, HADOOP-8887.004.patch
>
>
> Currently, we build the native code using ant-build invocations. Although
> this works, it has some limitations:
> * compiler warning messages are hidden, which can cause people to check in
> code with warnings unintentionally
> * there is no framework for running native unit tests; instead, we use ad-hoc
> constructs involving shell scripts
> * the antrun code is very platform specific
> * there is no way to run a specific native unit test
> * it's more or less impossible for scripts like test-patch.sh to separate a
> native test failing from the build itself failing (no files are created) or
> to enumerate which native tests failed.
> Using a native Maven plugin would overcome these limitations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
