[
https://issues.apache.org/jira/browse/HCATALOG-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564915#comment-13564915
]
Sushanth Sowmyan commented on HCATALOG-601:
-------------------------------------------
Hi,
I've attempted a number of ways of trying to resolving this on 0.5 so that we
can compile the incubating candidate, the more successful ones of them being:
a) glassfish-repository disabling - already there, as-is, does not work, winds
up being redefined as usable when jersey is pulled in.
b) faking definition of glassfish-repository so that it actually points to
central - still fails trying to fetch dependencies from the non-fake glassfish
repo (also tried by indicating that central was a mirror of
glassfish-repository - same result)
c) furthering above, by excluding all dependencies of all jersey components,
and explicitly depending on them before jersey is resolved - makes the pom.xml
file really ugly, and in the end, still does not work because it fails at
fetching jvnet-parent v1 from the non-fake glassfish repo
d) continuing by trying to depend on jvnet-parent v1 explicitly, can't do that,
jvnet-parent v1 does not itself seem to have a pom file, is not a typical
"dependency", it's a parent marker for other projects such as jersey.
At this point, I'm sure that a maven guru reading my post is probably tearing
their hair off at how I'm brute-force bungling through trying to get it to work
on 0.5, but I'm mostly out of ideas on how to get it compile consistently.
Then I had a closer look at all the e2e tests we've run, to see how we managed
to compile and run them at all, and there, I noticed that we'd mostly
developed, and tested templeton (webhcat) against jersey-1.14. I'm not sure why
the webhcat contribution's jersey dependency was set to 1.9 when most of the
testing was done against 1.14.
Given this, I actually now see running against 1.9 as the riskier proposition,
and instead of bumping jersey version to 1.10, would actually like to see it
bumped to 1.14 if that's okay with others, in both 0.5 and trunk.
> fix hcatalog dependency resolution issues
> -----------------------------------------
>
> Key: HCATALOG-601
> URL: https://issues.apache.org/jira/browse/HCATALOG-601
> Project: HCatalog
> Issue Type: Bug
> Components: build
> Reporter: Travis Crawford
> Assignee: Travis Crawford
> Fix For: 0.6
>
> Attachments: HCATALOG-601.1.patch
>
>
> Currently HCatalog dependency resolution fails when starting with an empty
> cache. This often manifests itself as the build failing when trying to unzip
> a jar, but the file is actually an HTML error page stored in the local maven
> cache.
> I *think* this is because of our jersey dependency. Currently we depend on
> jersey 1.9.1, which contains the following in
> [jersey-project-1.9.1.pom|http://search.maven.org/remotecontent?filepath=com/sun/jersey/jersey-project/1.9.1/jersey-project-1.9.1.pom]:
> {code}
> <repository>
> <id>glassfish-repository</id>
> <name>Repository for Glassfish</name>
> <url>
> http://maven.glassfish.org/content/groups/glassfish
> </url>
> </repository>
> {code}
> However, visiting that URL gives you a 404 as its no longer a maven repo. I
> believe this transitive repo is getting pulled into our build and causing
> havoc. Looking in our root-level pom we attempt to disable it, but that does
> not appear to be effective.
> Starting in jersey 1.10 the glassfish repo was removed. I believe by bumping
> our jsersey version we can resolve this issue. There was a minor packaging
> change (we now need {{jersey-servlet}} but otherwise its a minor (local - not
> sure about jersey) change.
--
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
