[
https://issues.apache.org/jira/browse/HCATALOG-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497406#comment-13497406
]
Travis Crawford commented on HCATALOG-518:
------------------------------------------
Thanks for taking a look [~thejas]!
I agree the version number hard-coded in all the POM files is lame. My
understanding is maven POM files all have the version hard-coded, and when
making a release with the {{mvn}} command it updates those version strings for
you. For example, here's an
[example|https://github.com/kevinweil/elephant-bird/commit/c42cd1de35a8806a3275d40d0eaa185f388924cf]
showing the maven release plugin making a commit updating the version strings
when making a release.
In our case, where we build with ant, I think we need to grep for the version
and replace them all manually. Hopefully I can learn a way to parameterize the
version string and define it just once, in {{build.properties}}. That said, I
think the benefit of publishing artifacts with correct pom files (correct
parents, repos, deps, ...) makes this version string issue worth dealing with.
Minor testing note: Francis and I used this patch to publish artifacts to a
local Nexus instance, and with a fresh maven project were able to download the
HCatalog jars & deps from the repo. AFAICT the Oozie & Giraph folks will be
able to use these jars when published by our CI job.
> Refactor hcatalog-core as subproject
> ------------------------------------
>
> Key: HCATALOG-518
> URL: https://issues.apache.org/jira/browse/HCATALOG-518
> Project: HCatalog
> Issue Type: Improvement
> Components: build
> Reporter: Travis Crawford
> Assignee: Travis Crawford
> Attachments: HCAT-518-rebased_francis.patch,
> HCATALOG-518_core_submodule.1.patch, HCATALOG-518_core_submodule.2.patch
>
>
> In HCATALOG-132 and its linked issues we made a number of build changes,
> breaking apart the monolithic HCatalog source tree into a number of
> subprojects. The goal was publishing separate artifacts for components that
> pull in large dependencies. For example, only the pig adapter should depend
> on pig, only the server extensions should depend on jms, etc.
> The last major change is refactoring the "core" code into a subproject. This
> will allow us to use the new build-common.xml system everywhere and have well
> defined lines between the components.
--
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