Hi guys,
I just noticed while testing the TableAPI on the cluster that it is not
part of the dist module. Therefore, programs using the TableAPI will only
run when you put the TableAPI jar directly on the cluster or if you build a
fat jar including the TableAPI jar. This is nowhere documented.
We should have a nightly cluster test for every library. Let's keep that in
mind for the future. Very nice find, Till!
Since there were not objections, I cherry-picked the proposed commits from
the document to the release-0.9 branch. If I understand correctly, we can
create the new release
@Till: This also apples to the streaming connectors.
On Fri, Jun 12, 2015 at 9:45 AM, Till Rohrmann trohrm...@apache.org wrote:
Hi guys,
I just noticed while testing the TableAPI on the cluster that it is not
part of the dist module. Therefore, programs using the TableAPI will only
run when
I have another fix, but this is just a documentation update (FLINK-2207)
and will be done soon.
2015-06-12 10:02 GMT+02:00 Maximilian Michels m...@apache.org:
We should have a nightly cluster test for every library. Let's keep that in
mind for the future. Very nice find, Till!
Since there
As for outstanding issues I think streaming is good to go as far as I know.
I am personally against including all libraries - at least speaking for the
streaming connectors. Robert, Stephan and myself had a detailed discussion
on that some time ago and the disadvantage of having all the libraries
What about the shaded jars?
On Fri, Jun 12, 2015 at 11:32 AM Ufuk Celebi u...@apache.org wrote:
@Max: for the new RC. Can you make sure to set the variables correctly
with regard to stable/snapshot versions in the docs?
On 12 Jun 2015, at 09:45, Till Rohrmann trohrm...@apache.org wrote:
Hi guys,
I just noticed while testing the TableAPI on the cluster that it is not
part of the dist module. Therefore, programs using the TableAPI will only
run when you put the TableAPI jar directly on the cluster or if you
After thinking about it a bit more, I think that's fine.
+1 to document and keep it as it is.
Well I think the initial idea was to keep the dist jar as small a possible
and therefore we did not include the libraries. I'm not sure whether we can
decide this here ad-hoc. If the community says that we shall include these
libraries then I can add them. But bear in mind that all of them have
On 12 Jun 2015, at 10:44, Till Rohrmann trohrm...@apache.org wrote:
Yes you're right Ufuk. At the moment the user has to place the jars in the
lib folder of Flink. If this folder is not shared then he has to do it for
every node on which Flink runs.
OK. I guess there is a nice way to do this
On 12 Jun 2015, at 10:29, Till Rohrmann trohrm...@apache.org wrote:
Well I think the initial idea was to keep the dist jar as small a possible
and therefore we did not include the libraries. I'm not sure whether we can
decide this here ad-hoc. If the community says that we shall include these
I think I found a real release blocker. Currently we don't add license
files to our shaded jars. For example
the flink-shaded-include-yarn-0.9.0-milestone-1.jar shades hadoop code.
This code also includes the `org.apache.util.bloom.*` classes. These
classes are licensed under The European
On 12 Jun 2015, at 00:40, Ufuk Celebi u...@apache.org wrote:
On 11 Jun 2015, at 20:04, Fabian Hueske fhue...@gmail.com wrote:
How about the following issues?
1. The Hbase Hadoop Compat issue, Ufuk is working on
I was not able to reproduce this :( I ran HadoopInputFormats against
I'm currently going through the license file and I discovered some
skeletons in our closet. This has to be merged as well. But I'm still
working on it (we have a lot of dependencies).
Cheers,
Till
On Fri, Jun 12, 2015 at 12:51 AM Ufuk Celebi u...@apache.org wrote:
On 12 Jun 2015, at 00:49,
I'm in favour of option b) as well.
On Fri, Jun 12, 2015 at 12:05 PM Ufuk Celebi u...@apache.org wrote:
Yes, the LICENSE files are definitely a release blocker.
a) Either we wait with the RC until we have fixed the LICENSES, or
b) Put out next RC to continue with testing and then update it
+1 for b)
I'm organizing + merging the commits that need to go the new candidate
right now. Will let you know, when I am done.
2015-06-12 14:03 GMT+02:00 Till Rohrmann till.rohrm...@gmail.com:
I'm in favour of option b) as well.
On Fri, Jun 12, 2015 at 12:05 PM Ufuk Celebi u...@apache.org
Regarding the discussion with including ML, Gelly, streaming connectors
into flink-dist.
I'm strongly against adding those into our jar because they blow up the
dependencies we are shipping by default.
Also, the maven archetype sets up everything so that the dependencies are
packaged into the
I agree mostly with Robert. However, one could also argue that by not
including the libraries in the dist package, the user code jar will also be
blown up by the dependencies added by the library. This will slow down job
submission, because it has to be distributed on the cluster. Furthermore, I
+1 for linking from DataSet's transformations.
On Jun 12, 2015 5:27 PM, Fabian Hueske fhue...@gmail.com wrote:
Linking from the DataSet Transformations page would be good, IMO.
2015-06-12 17:11 GMT+02:00 Andra Lungu lungu.an...@gmail.com:
Thanks for the replies!
I will add the two
Hi guys,
I just updated our LICENSE of the binary distribution and noticed that we
also list dependencies which are licensed under Apache-2.0. As far as I
understand the ASF guidelines [1], this is not strictly necessary. Since it
is a lot of work to keep the list up to date, I was wondering
Linking from the DataSet Transformations page would be good, IMO.
2015-06-12 17:11 GMT+02:00 Andra Lungu lungu.an...@gmail.com:
Thanks for the replies!
I will add the two methods in a DataSetUtils separate class. Where would
you put the documentation for this? I think users should be able to
Thanks for the replies!
I will add the two methods in a DataSetUtils separate class. Where would
you put the documentation for this? I think users should be able to easily
access it. This means that it, IMO, it shouldn't go in a separate zip page,
but rather in the programming guide. Or there
22 matches
Mail list logo
