Sounds good!
On Mon, Jun 26, 2017 at 4:36 PM, Chesnay Schepler
wrote:
> I do believe the full dependency version of, say guava, should be apparent
> from the dependency
> declaration of a Flink pom. Just for clarity purposes.
>
> We could still include the full version in the version of the modu
I do believe the full dependency version of, say guava, should be
apparent from the dependency
declaration of a Flink pom. Just for clarity purposes.
We could still include the full version in the version of the module though,
i.e
org.apache.flink flink-shaded-guava18
1.0-18.0
On 26.06.20
Sounds good.
If the libraries follow semantic versioning properly, we could try and only
have the major version in the module name?
On Mon, Jun 26, 2017 at 2:45 PM, Chesnay Schepler
wrote:
> You're raising good points, now i see why having the version in the name
> is useful.
>
> I'll adjust
You're raising good points, now i see why having the version in the name
is useful.
I'll adjust my PR accordingly. And yes, ideally we only release the
modified modules, not everything again.
On 26.06.2017 14:29, Stephan Ewen wrote:
How should it work when one of the shaded dependencies is u
How should it work when one of the shaded dependencies is updated? We
probably do not want to release all of them, just because the overall
version number is in their version number.
How about that:
- Under normal circumstances, we only increase the version of the root
project, when we add / bu
the guava version is already included in the version of the flink-shaded
module.
For example, for the first release of flink-shaded-guava the version
would be 1-18.0.
1 is the version of flink-shaded itself, 18.0 is the guava version.
On 26.06.2017 14:01, Stephan Ewen wrote:
Looks good, tha
+1 on including dependency version.
Original message From: Stephan Ewen Date:
6/26/17 5:01 AM (GMT-08:00) To: dev@flink.apache.org Subject: Re: [DISCUSS]
Changing Flink's shading model
Looks good, thanks Chesnay!.
How about including the dependency version names i
Looks good, thanks Chesnay!.
How about including the dependency version names in the module names, like
"flink-shaded-guava-18.0"?
On Mon, Jun 26, 2017 at 11:49 AM, Chesnay Schepler
wrote:
> The new repo was created and is accessible here:
> https://github.com/apache/flink-shaded
>
> I've alrea
The new repo was created and is accessible here:
https://github.com/apache/flink-shaded
I've already opened a PR to add a shaded guava module.
Once the shaded-guava module is merged I would like to do a first
release of flink-shaded,
only containing guava. I already have a branch with all the
Okay, I'll request a repo for the shading.
On Wed, Jun 21, 2017 at 1:38 PM, Chesnay Schepler
wrote:
> I like your suggestion Robert. A lot actually.
>
> Having the actual dependency version (i.e 18 for guava) in the version
> should improve clarity a lot.
>
> Originally i intended to release 1 a
I like your suggestion Robert. A lot actually.
Having the actual dependency version (i.e 18 for guava) in the version
should improve clarity a lot.
Originally i intended to release 1 artifact per Flink version, with the
normal versioning scheme
that we use. But given that the shaded dependenc
Its not completely clear to me how we want to version the shaded
dependencies, and where we are putting them.
One concern are the official apache release rules. If we want to release
something to maven central, we need to do a proper vote over a source
archive.
I would propose to create a new repo
I like this approach.
Two additional things can be mention here:
- We need to deploy these artifacts independently and not as part of the
build. That is a manual step once per "bump" in the dependency of that
library.
- We reduce the shading complexity of the original build and should thus
a
I would like to start working on this.
I've looked into adding a flink-shaded-guava module. Working against the
shaded namespaces seems
to work without problems from the IDE, and we could forbid un-shaded
usages with checkstyle.
So for the list of dependencies that we want to shade we current
@eron I would try to rely almost purely on the shade plugin
On Thu, May 11, 2017 at 7:53 PM, Eron Wright wrote:
> In my opinion, the ideal approach to mitigating conflicts between
> application code and Flink itself is to relocate all of Flink's
> dependencies. Rationale is to avoid placing th
In my opinion, the ideal approach to mitigating conflicts between
application code and Flink itself is to relocate all of Flink's
dependencies. Rationale is to avoid placing the burden of relocation on
the app developer, and ultimately to eliminate the need for an app uber-jar.
For example, imagi
On Thu, May 11, 2017 at 10:59 AM, Till Rohrmann wrote:
> Have we somewhere documented how to publish
> artifacts on Maven central?
Pulling in Robert who published frocks. @Robert: Would you like to
volunteer for this? Would really help to combine this with some docs
about publishing Maven artefac
I agree that shading is a nasty business it would make things a bit more
explicit to program directly against the relocated API of the
above-mentioned libraries. I assume that we should be able to follow the
examples of flakka and frocks. Have we somewhere documented how to publish
artifacts on Mav
@Ufuk - I have never set up artifact deployment in Maven, could need some
help there.
Regarding shading Netty, I agree, would be good to do that as well...
On Thu, May 11, 2017 at 10:52 AM, Ufuk Celebi wrote:
> The advantages you've listed sound really compelling to me.
>
> - Do you have time
The advantages you've listed sound really compelling to me.
- Do you have time to implement these changes or do we need a volunteer? ;)
- I assume that republishing the artifacts as you propose doesn't have
any new legal implications since we already publish them with our
JARs, right?
- We might
@chesnay: I used ASM as an example in the proposal. Maybe I did not say
that clearly.
If we like that approach, we should deal with the other libraries (at least
the frequently used ones) in the same way.
I would imagine to have a project layout like that:
flink-shaded-deps
- flink-shaded-asm
I like the idea, thank you for bringing it up.
Given that the raised problems aren't really ASM specific would it make
sense to create one flink-shaded module that contains all frequently
shaded libraries? (or maybe even all shaded dependencies by core
modules) The proposal limits the scope of
Hi!
This is a discussion about altering the way we handle dependencies and
shading in Flink.
I ran into quite a view problems trying to adjust / fix some shading issues
during release validation.
The issue is tracked under: https://issues.apache.org/jira/browse/FLINK-6529
Bring this discussion th
23 matches
Mail list logo
