[jira] [Created] (FLINK-1578) Overhaul BLOB manager
Stephan Ewen created FLINK-1578: --- Summary: Overhaul BLOB manager Key: FLINK-1578 URL: https://issues.apache.org/jira/browse/FLINK-1578 Project: Flink Issue Type: Bug Components: JobManager Affects Versions: 0.8, 0.9 Reporter: Stephan Ewen Assignee: Stephan Ewen Fix For: 0.9, 0.8 The BLOB manager need improvements: - Decent failure tests - Better error handling (letting the client know what happened) - Better error logging - Retries upon failed fetches - A bit of control over the maximum number of concurrent connections and the backlog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLINK-1577) Misleading error messages when cancelling tasks
Ufuk Celebi created FLINK-1577: -- Summary: Misleading error messages when cancelling tasks Key: FLINK-1577 URL: https://issues.apache.org/jira/browse/FLINK-1577 Project: Flink Issue Type: Improvement Components: Distributed Runtime Affects Versions: master Reporter: Ufuk Celebi A user running a Flink version before bec9c4d ran into a job manager failure (fixed in bec9c4d), which lead to restarting the JM and cancelling/clearing all tasks on the TMs. The logs of the TMs were inconclusive. I think part of that has been fixed by now, e.g. there is a log message when cancelAndClearEverything is called, but the task thread (RuntimeEnvironment) always logs an error when interrupted during the run method -- even if the task gets cancelled. I think these error messages are misleading and only the root cause is important (i.e. non-failed tasks should be silently cancelled). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLINK-1581) Configure DeathWatch parameters properly
Till Rohrmann created FLINK-1581:
Summary: Configure DeathWatch parameters properly
Key: FLINK-1581
URL: https://issues.apache.org/jira/browse/FLINK-1581
Project: Flink
Issue Type: Bug
Reporter: Till Rohrmann
We are using Akka's DeathWath mechanism to detect failed components. However,
the interval until an {{Instance}} is marked dead is currently very long.
Especially, in conjunction with the job restarting mechanism we should devise a
mechanism which either quickly detects dead {{Instance}}s or set the interval,
pause and threshold values such that the detection does not take longer than
the Akka ask timeout value. Otherwise, all retries might be consumed before an
{{Instance}} is recognized being dead.
Further investigation of the correct failure behavior is necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Scala Style Template
We could help this by having shorter local and input argument names and
better timing for the line wrapping.
We already have separate code style for java, for example keeping tabs
instead of spaces, and scala because java code more verbose and declarative
compare to scala.
I am ok with Java do not have max char per line rule but would like to keep
Scala max line rule, at least for now. If 100 too restrictive we could try
relax it to 120 or 140 to see if it helps.
On Wednesday, February 18, 2015, Robert Metzger rmetz...@apache.org wrote:
I don't want to remove the rule to encourage people to write ugly scala
code ;)
Also, I hope its the exception to use more than 100 chars.
But there are some cases where it is really okay to have longer lines (for
example exception messages or method signatures in some cases).
I agree with Stephan that its sometimes harder to understand the Scala code
due to the rule. For example:
def startActorWithConfiguration(hostname: String, taskManagerName: String,
configuration: Configuration,
localAkkaCommunication: Boolean,
localTaskManagerCommunication: Boolean)
(implicit system: ActorSystem) = {
val (connectionInfo, jobManagerURL, taskManagerConfig,
networkConnectionConfiguration) =
parseConfiguration(hostname, configuration, localAkkaCommunication,
localTaskManagerCommunication)
startActor(taskManagerName, connectionInfo, jobManagerURL,
taskManagerConfig,
networkConnectionConfiguration)
}
Would be nicer like this:
def startActorWithConfiguration(hostname: String, taskManagerName: String,
configuration: Configuration,
localAkkaCommunication: Boolean,
localTaskManagerCommunication: Boolean)
(implicit system: ActorSystem) = {
val (connectionInfo, jobManagerURL, taskManagerConfig,
networkConnectionConfiguration) =
parseConfiguration(hostname, configuration,
localAkkaCommunication, localTaskManagerCommunication)
startActor(taskManagerName, connectionInfo, jobManagerURL,
taskManagerConfig, networkConnectionConfiguration)
}
The Java checkstyle isn't very strict as well and I have the impression
that our code is still very readable.
Also, we have our pull-request reviewing system for spotting exactly such
cases.
So I'm hereby voting to remove the rule.
On Wed, Feb 18, 2015 at 4:09 PM, Henry Saputra henry.sapu...@gmail.com
javascript:;
wrote:
Ah seemed like kafka has taken out the max line rule.
I prefer to keep the max char lines, maybe making it larger than 100,
especially with Scala code.
On Wednesday, February 18, 2015, Henry Saputra henry.sapu...@gmail.com
javascript:;
wrote:
I would argue it is helpful especially if you use text editor like vim
or
even GitHub diff page.
Most modern scala projects like spark and kafka also enforce the rule.
- Henry
On Wednesday, February 18, 2015, Stephan Ewen se...@apache.org
javascript:;
javascript:_e(%7B%7D,'cvml','se...@apache.org javascript:;');
wrote:
It is true, you can write endless chains of functions in Scala that
become
hard to read, which should be prevented.
In my opinion, line length limits are not a good tool to do that. In
most
cases they simply introduce linebreaks between constant names and
parameters
which hurt code readability more than they help.
On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra
henry.sapu...@gmail.com javascript:;
wrote:
Sorry Robert and all, pressed Send button too early =(
One of the main reasons to keep the max 100 chars line (or 120) is
to
make sure that the code is readable an understandable, which in
Scala
you can easily get the code to be complicated and in a single line.
- Henry
[1] http://www.scalastyle.org/rules-0.1.0.html
On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra
henry.sapu...@gmail.com javascript:;
wrote:
Stephan was taking about imports statements.
I want to keep line length to 100 or 120.
Code that is longer than 100 char per line need to be revisited.
On Tuesday, February 17, 2015, Robert Metzger
rmetz...@apache.org javascript:;
wrote:
I agree with Stephan that we should remove the scalastyle rule
enforcing
lines of 100 characters length.
On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra
henry.sapu...@gmail.com javascript:;
wrote:
@Stephan - sure I could work on it. Been wanting to do it for a
while.
No, it is not the checkstyle issue.
- Henry
On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org
javascript:;
wrote:
Yes, the hadoopcompatibility is a bit long, I agree
Re: [SUGGESTION] Push latest doc to Flink website
This is a must-have. I would like to take a look at the automatic doc build infrastructure next week. Basically we have to write some buildbot rules which issue a build and upload of the docs on a daily basis. On Wed, Feb 18, 2015 at 4:53 PM, Robert Metzger rmetz...@apache.org wrote: Thats indeed a great idea and we had support for that. We also have already the infrastructure to do it in place, I just had not enough time to figure out how ASF's buildbot works. (I know how it should work theoretically but I haven't tried it) This is the respective JIRA: https://issues.apache.org/jira/browse/FLINK-1370. On Wed, Feb 18, 2015 at 4:34 PM, Márton Balassi balassi.mar...@gmail.com wrote: +1 We used to have this a couple of releases ago. On Wed, Feb 18, 2015 at 4:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: Hi All, I am thinking of pushing latest doc in master ((i.e the snapshot build) to Flink website to help people follow the latest change and development without manually build the doc. I think some projects like Apache Tajo, Apache Twill, and AmpLab Tachyon have this and so far I have seen it is helpful for new contributors. Thoughts? - Henry
Re: [DISCUSS] Create a shaded Hadoop fat jar to resolve library version conflicts
I'm also in favor of shading commonly used libraries to resolve this issue for our upstream users. I recently wrote this distributed TPC-H datagenerator, which had a hard dependency on a newer guava version. So I needed to shade guava in my project to make it work. Another candidate to shade is the ASM library. So you have my +1 for doing this. On Tue, Feb 17, 2015 at 4:26 PM, Stephan Ewen se...@apache.org wrote: I think the way we shaded Guava is a problem for the way IntelliJ uses maven (compile dependency projects, not package them). Since we do not apply relocation to our code for this, it should have no effect on the IDE usability. On Tue, Feb 17, 2015 at 3:37 PM, Ufuk Celebi u...@apache.org wrote: On 17 Feb 2015, at 09:40, Stephan Ewen se...@apache.org wrote: Hi everyone! We have been time and time again struck by the problem that Hadoop bundles many dependencies in certain versions, that conflict either with versions of the dependencies we use, or with versions that users use. The most prominent examples are Guava and Protobuf. One way to solve this is to create ourselves a custom Hadoop dependency: We build a fat jar from Hadoop (with all its dependencies) and in this fat jar shade Guava and Protobuf. We can use the flink-shading project for this - it is already used to build a custom (shaded) version of Guava for Flink. Any opinions on this? I'm not familiar with all the details, but from past experience I recall that this has been an issue for various users. I don't see all implications of such a change (are there any down sides?), but in general I think that it will improve the overall user experience. Hence: +1.
Re: [DISCUSS] Scala code style - explicit vs implicit code behavior
Moved this to the Wiki: https://cwiki.apache.org/confluence/display/FLINK/Coding+Guidelines+for+Scala On Mon, Feb 16, 2015 at 4:29 PM, Paris Carbone par...@kth.se wrote: +1 Good point. In general, keeping the common/runtime as simple as possible is quite important On 16 Feb 2015, at 16:05, Till Rohrmann trohrm...@apache.org wrote: +1 On Mon, Feb 16, 2015 at 3:38 PM, Aljoscha Krettek aljos...@apache.org wrote: +1 On Mon, Feb 16, 2015 at 3:18 PM, Fabian Hueske fhue...@gmail.com wrote: +1 2015-02-15 17:47 GMT+01:00 Stephan Ewen se...@apache.org: I thought about adding a wiki page for that. On Sat, Feb 14, 2015 at 7:16 PM, Henry Saputra henry.sapu...@gmail.com wrote: +1 to the idea I suppose no really action item for FLINK-1548? Maybe add doc about contributing to Scala portion? On Saturday, February 14, 2015, Stephan Ewen se...@apache.org wrote: Hi everyone! Since a sizable portion of the Flink code is now in Scala (and more is coming in the API projects), I think we need to define a few guidelines for Scala programming. Scala is very powerful and has a lot of magic features that allow you to design killer nice APIs, but also make reasoning about code harder. Through the use of implicit parameters, lazy parameters, overriding of base operators, functions that take code blocks, etc, you can easily write code that does something entirely different than what it looks like initially. For APIs, I think we should embrace the power of these features to make the APIs nice, convenient, and with intuitive syntax. After all, the elegance of the API matters a lot. For the runtime or anything below the APIs, I propose to refrain to a large extend from the magic features. For those parts, I think it matters most that the code is predictable, it is easy to understand the implications for also non-expert Scala programmers, and it is possible to peer review it through GitHub (where you do not see a difference between a lazy or an eager parameter). One example of such a change would be https://issues.apache.org/jira/browse/FLINK-1548 Summary: Be magic in the APIs, be explicit and simple in the runtime. Greetings, Stephan
Re: Scala Style Template
It is true, you can write endless chains of functions in Scala that become hard to read, which should be prevented. In my opinion, line length limits are not a good tool to do that. In most cases they simply introduce linebreaks between constant names and parameters which hurt code readability more than they help. On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra henry.sapu...@gmail.com wrote: Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: [DISCUSS] Dedicated streaming mode and start scripts
+1 I agree it’s a proper way to go. On 18 Feb 2015, at 10:41, Max Michels m...@apache.orgmailto:m...@apache.org wrote: +1 On Tue, Feb 17, 2015 at 2:40 PM, Aljoscha Krettek aljos...@apache.orgmailto:aljos...@apache.org wrote: +1 On Tue, Feb 17, 2015 at 1:34 PM, Till Rohrmann trohrm...@apache.orgmailto:trohrm...@apache.org wrote: +1 On Tue, Feb 17, 2015 at 1:34 PM, Kostas Tzoumas ktzou...@apache.orgmailto:ktzou...@apache.org wrote: +1 On Tue, Feb 17, 2015 at 12:14 PM, Márton Balassi mbala...@apache.orgmailto:mbala...@apache.org wrote: When it comes to the current use cases I'm for this separation. @Ufuk: As Gyula has already pointed out with the current design of integration it should not be a problem. Even if we submitted programs to the wrong clusters it would only cause performance issues. Eventually it would be nice to have an integrated cluster. On Tue, Feb 17, 2015 at 11:55 AM, Ufuk Celebi u...@apache.orgmailto:u...@apache.org wrote: I think this separation reflects the way that Flink is used currently anyways. I would be in favor of it as well. - What about the ongoing efforts (I think by Gyula) to combine both the batch and stream processing APIs? I assume that this would only effect the performance and wouldn't pose a fundamental problem there, would it?
[jira] [Created] (FLINK-1579) Create a Flink History Server
Robert Metzger created FLINK-1579: - Summary: Create a Flink History Server Key: FLINK-1579 URL: https://issues.apache.org/jira/browse/FLINK-1579 Project: Flink Issue Type: New Feature Affects Versions: 0.9 Reporter: Robert Metzger Right now its not possible to analyze the job results for jobs that ran on YARN, because we'll loose the information once the JobManager has stopped. Therefore, I propose to implement a Flink History Server which serves the results from these jobs. I haven't started thinking about the implementation, but I suspect it involves some JSON files stored in HDFS :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [SUGGESTION] Push latest doc to Flink website
Thats indeed a great idea and we had support for that. We also have already the infrastructure to do it in place, I just had not enough time to figure out how ASF's buildbot works. (I know how it should work theoretically but I haven't tried it) This is the respective JIRA: https://issues.apache.org/jira/browse/FLINK-1370. On Wed, Feb 18, 2015 at 4:34 PM, Márton Balassi balassi.mar...@gmail.com wrote: +1 We used to have this a couple of releases ago. On Wed, Feb 18, 2015 at 4:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: Hi All, I am thinking of pushing latest doc in master ((i.e the snapshot build) to Flink website to help people follow the latest change and development without manually build the doc. I think some projects like Apache Tajo, Apache Twill, and AmpLab Tachyon have this and so far I have seen it is helpful for new contributors. Thoughts? - Henry
Re: [SUGGESTION] Push latest doc to Flink website
+1 We used to have this a couple of releases ago. On Wed, Feb 18, 2015 at 4:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: Hi All, I am thinking of pushing latest doc in master ((i.e the snapshot build) to Flink website to help people follow the latest change and development without manually build the doc. I think some projects like Apache Tajo, Apache Twill, and AmpLab Tachyon have this and so far I have seen it is helpful for new contributors. Thoughts? - Henry
[SUGGESTION] Push latest doc to Flink website
Hi All, I am thinking of pushing latest doc in master ((i.e the snapshot build) to Flink website to help people follow the latest change and development without manually build the doc. I think some projects like Apache Tajo, Apache Twill, and AmpLab Tachyon have this and so far I have seen it is helpful for new contributors. Thoughts? - Henry
Re: Snapshot broken?
I mean the snapshots obtained from https://repository.apache.org/content/repositories/snapshots/ On Wed, Feb 18, 2015 at 1:26 PM, Robert Metzger rmetz...@apache.org wrote: Hi, do you mean the maven snapshot repository or the nightly build? On Wed, Feb 18, 2015 at 1:14 PM, Arvid Heise arvid.he...@gmail.com wrote: Dear Flinker, can anyone try to build a Flink program against the 0.9-SNAPSHOT? I receive the following maven error [ERROR] error: error while loading root, invalid CEN header (bad signature) [ERROR] error: scala.reflect.internal.MissingRequirementError: object scala.runtime in compiler mirror not found. According to https://groups.google.com/forum/#!msg/scala-user/A-aejw44XGs/QomJ5_Chd0sJ any faulty jar may be responsible for the error. Since Flink is the only snapshot that I build against, it is very likely that something broke here. Best, Arvid
Re: Scala Style Template
I would argue it is helpful especially if you use text editor like vim or even GitHub diff page. Most modern scala projects like spark and kafka also enforce the rule. - Henry On Wednesday, February 18, 2015, Stephan Ewen se...@apache.org wrote: It is true, you can write endless chains of functions in Scala that become hard to read, which should be prevented. In my opinion, line length limits are not a good tool to do that. In most cases they simply introduce linebreaks between constant names and parameters which hurt code readability more than they help. On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org javascript:; wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org javascript:; wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org javascript:; wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org javascript:; wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com javascript:; wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org javascript:; wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
Re: Scala Style Template
Ah seemed like kafka has taken out the max line rule. I prefer to keep the max char lines, maybe making it larger than 100, especially with Scala code. On Wednesday, February 18, 2015, Henry Saputra henry.sapu...@gmail.com wrote: I would argue it is helpful especially if you use text editor like vim or even GitHub diff page. Most modern scala projects like spark and kafka also enforce the rule. - Henry On Wednesday, February 18, 2015, Stephan Ewen se...@apache.org javascript:_e(%7B%7D,'cvml','se...@apache.org'); wrote: It is true, you can write endless chains of functions in Scala that become hard to read, which should be prevented. In my opinion, line length limits are not a good tool to do that. In most cases they simply introduce linebreaks between constant names and parameters which hurt code readability more than they help. On Wed, Feb 18, 2015 at 3:48 AM, Henry Saputra henry.sapu...@gmail.com wrote: Sorry Robert and all, pressed Send button too early =( One of the main reasons to keep the max 100 chars line (or 120) is to make sure that the code is readable an understandable, which in Scala you can easily get the code to be complicated and in a single line. - Henry [1] http://www.scalastyle.org/rules-0.1.0.html On Tue, Feb 17, 2015 at 6:03 PM, Henry Saputra henry.sapu...@gmail.com wrote: Stephan was taking about imports statements. I want to keep line length to 100 or 120. Code that is longer than 100 char per line need to be revisited. On Tuesday, February 17, 2015, Robert Metzger rmetz...@apache.org wrote: I agree with Stephan that we should remove the scalastyle rule enforcing lines of 100 characters length. On Mon, Jan 5, 2015 at 10:21 AM, Henry Saputra henry.sapu...@gmail.com wrote: @Stephan - sure I could work on it. Been wanting to do it for a while. No, it is not the checkstyle issue. - Henry On Mon, Jan 5, 2015 at 1:16 AM, Stephan Ewen se...@apache.org wrote: Yes, the hadoopcompatibility is a bit long, I agree to change it to hadoop. Henry, do you want to do this? But the reason is not checkstyle here, is it? On Mon, Jan 5, 2015 at 9:27 AM, Henry Saputra henry.sapu...@gmail.com wrote: Yeah, automated tools can only do so much. I always turn off the automatic line wrapping since it cant tell for imports and regular code. And BTW I think we need to shorten some of Flink package and class names. For example, hadoopcompatibility can just be changed to hadoop package. - Henry On Sun, Jan 4, 2015 at 11:33 PM, Till Rohrmann trohrm...@apache.org wrote: I just checked and in fact this option is already turned on. The problem was that I activated automatic line wrapping if a line is longer than 100 characters in order to comply with the scalastyle plugin. Since Intellij cannot distinguish between Imports and code it also wrapped the import statements. I guess then the only viable option is to manually wrap the lines. On Sun, Jan 4, 2015 at 10:34 PM, Stephan Ewen se...@apache.org wrote: Excluding the imports sounds like a good idea. On Sun, Jan 4, 2015 at 10:30 PM, Henry Saputra henry.sapu...@gmail.com wrote: I think we could add exclude for imports statements line length checking. Without limit of line length we need to be very careful when coding long lines to keep the code easy to read and understand, hence the line length style safe guard. Some if the java code has very long lines that make it hard to read. On Sunday, January 4, 2015, Stephan Ewen se...@apache.org wrote: Hi all! I would suggest to remove the line length limitation in the scala-style definition. It leads to very awkward formattings (see for example TaskManager imports) and at this point I am not sure it helps us in any way. Greetings, Stephan
