Yeah, was the issue that it had to be built vs Maven to show the error
and this uses SBT -- or vice versa? that's why the existing test
didn't detect it. Was just thinking of adding one more of these non-PR
builds, but I forget if there was a reason this is hard. Certainly not
worth building for
There are many Jenkins jobs besides the pull request builder that
build against various Hadoop combinations, for example, in the
background. Is there an obstacle to building vs 2.11 on both Maven and
SBT this way?
On Mon, Oct 12, 2015 at 2:55 PM, Iulian Dragoș
wrote:
It's really easy to create and modify those builds. If the issue is that we
need to add SBT or Maven to the existing one, it's a short change. We can
just have it build both of them. I wasn't aware of things breaking before
in one build but not another.
- Patrick
On Mon, Oct 12, 2015 at 9:21 AM,
On Fri, Oct 9, 2015 at 10:34 PM, Patrick Wendell wrote:
> I would push back slightly. The reason we have the PR builds taking so
> long is death by a million small things that we add. Doing a full 2.11
> compile is order minutes... it's a nontrivial increase to the build
I would push back slightly. The reason we have the PR builds taking so long
is death by a million small things that we add. Doing a full 2.11 compile
is order minutes... it's a nontrivial increase to the build times.
It doesn't seem that bad to me to go back post-hoc once in a while and fix
2.11
That is correct !, I have thought about this a lot of times. The only
solution is to implement a "real" cross build for both version. I am going
to think more in this. :)
Prashant Sharma
On Sat, Oct 10, 2015 at 2:04 AM, Patrick Wendell wrote:
> I would push back slightly.
Sorry for not being clear, yes, that's about the Sbt build and treating
warnings as errors.
Warnings in 2.11 are useful, though, it'd be a pity to keep introducing
potential issues. As a stop-gap measure I can disable them in the Sbt
build, is it hard to run the CI test with 2.11/sbt?
iulian
How about just fixing the warning? I get it; it doesn't stop this from
happening again, but still seems less drastic than tossing out the
whole mechanism.
On Fri, Oct 9, 2015 at 3:18 PM, Iulian Dragoș
wrote:
> Sorry for not being clear, yes, that's about the Sbt build
>
> How about just fixing the warning? I get it; it doesn't stop this from
> happening again, but still seems less drastic than tossing out the
> whole mechanism.
>
+1
It also does not seem that expensive to test only compilation for Scala
2.11 on PR builds.
+1, much better than having a new PR each time to fix something for scala-2.11
every time a patch breaks it.
Thanks,
Hari Shreedharan
> On Oct 9, 2015, at 11:47 AM, Michael Armbrust wrote:
>
> How about just fixing the warning? I get it; it doesn't stop this from
>
Interesting
https://amplab.cs.berkeley.edu/jenkins/view/Spark-QA-Compile/job/Spark-Master-Scala211-Compile/
shows green builds.
On Thu, Oct 8, 2015 at 6:40 AM, Iulian Dragoș
wrote:
> Since Oct. 4 the build fails on 2.11 with the dreaded
>
> [error]
Since Oct. 4 the build fails on 2.11 with the dreaded
[error] /home/ubuntu/workspace/Apache Spark (master) on
2.11/core/src/main/scala/org/apache/spark/rpc/netty/NettyRpcEnv.scala:310:
no valid targets for annotation on value conf - it is discarded
unused. You may specify targets with
I tried building with Scala 2.11 on Linux with latest master branch :
[INFO] Spark Project External MQTT SUCCESS [
19.188 s]
[INFO] Spark Project External MQTT Assembly ... SUCCESS [
7.081 s]
[INFO] Spark Project External ZeroMQ .. SUCCESS
The problem only applies to the sbt build because it treats warnings as
errors.
@Iulian - how about we disable warnings -> errors for 2.11? That would seem
better until we switch 2.11 to be the default build.
On Thu, Oct 8, 2015 at 7:55 AM, Ted Yu wrote:
> I tried
14 matches
Mail list logo