[ 
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

Reply via email to