New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FLINK-13748][S3][build] Fix jaxb relocation for S3. #9695
Conversation
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community Automated ChecksLast check on commit bc6537e (Wed Oct 16 08:24:31 UTC 2019) Warnings:
Mention the bot in a comment to re-run the automated checks. Review Progress
Please see the Pull Request Review Guide for a full explanation of the review process. The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commandsThe @flinkbot bot supports the following commands:
|
To reviewers: This is the build that verified that the change works: https://travis-ci.org/kl0u/flink/builds/585693473. As you can see something goes wrong during the building of the I will relaunch but at least the tests seem to work for java 8 as shown in https://api.travis-ci.org/v3/job/585693500/log.txt and https://api.travis-ci.org/v3/job/585693501/log.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening this PR @kl0u. I was wondering whether we can't solve the problem a little bit easier. Would it be possible to simply add the dependency jaxb-api
always to these two modules and relocate it?
</executions> | ||
</plugin> | ||
</plugins> | ||
</build> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of adding this rather complicated shade snippet, why don't we always add the jaxb-api
dependency via
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
</executions> | ||
</plugin> | ||
</plugins> | ||
</build> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. I think maintaining this shading logic can be quite a pain in the ass.
@tillrohrmann I agree but adding by default the dependency seems to be failing to compile as shown here: https://travis-ci.org/kl0u/flink/builds/586431721 (this is the branch this travis run refers to https://github.com/kl0u/flink/tree/fix-jaxb-alt) |
It may be just a versioning issue. Java 8 needs |
@kl0u, would it work to add |
@tillrohrmann I am running it on Travis to see |
We were planning to completely remove shading of the file systems for Flink 1.10 and put them into the plugins directory. Would this be the time to do that? It seems a bit like wasted effort to fix shading when we want to remove it soon anyways. |
@StephanEwen I agree that if this is the goal, then this effort is "instant legacy". That said, I do not feel comfortable doing the whole migration to the plugin mechanism for the filesystems myself. This is both due to time constraints, as I am already involved in other features, and because of non-familiarity with our plugin mechanism. I can close this PR if you think that we should not pursue this solution any further. |
If adding the Once we get to removing shading, this fix then becomes obsolete and can be removed. |
The status can be seen here https://travis-ci.org/kl0u/flink/builds/586896522 and the branch with the changes where we only use |
What is the purpose of the change
Fixes shading on Presto and Hadoop S3 FileSystems.
Brief change log
Changes the
pom.xml
in theflink-s3-fs-hadoop
andflink-s3-fs-presto
.Verifying this change
This change is already covered by existing tests, such as the s3 e2e tests and can be verified by running the cron jobs on Travis.
Does this pull request potentially affect one of the following parts:
@Public(Evolving)
: (yes / no)Documentation