Oh, yikes. It seems like https://github.com/gradle/gradle/issues/847 indicates
that the feature to use the default names in Gradle is practically
nonfunctional. If that bug is as severe as it looks, I have to retract my
position. Like we could never have sdks/java/core and sdks/py/core, right?
FWIW, hacked something as showcase for BEAM-4046 [1]
This is miserably broken, but a
./gradlew projects
or
./gradlew -p sdks/java build
should work. Anything else is likely to cause issues. If u hit stack
overflow exception, it's likely caused by
https://github.com/gradle/gradle/issues/847
FWIW --
On my (desired, not explicitly job-function) roadmap is to tap into a bunch
of our corporate Kafka queues to ingest that data to places I can use.
Those are 'stuck' 0.9, with no upgrade in sight (am told the upgrade path
isn't trivial, is very critical flows, and they are scared for it to
Hi Alexey,
We will use this website as a platform moving forward, and you will all the
information related to future Beam Summits. At the moment, we don't have
plans to include previous events (summit last year) but as we move forward,
the Beam Summits will all be featured on that website.
On
On Mon, Apr 1, 2019 at 2:20 PM Lukasz Cwik wrote:
>
>
> On Mon, Apr 1, 2019 at 2:00 PM Kenneth Knowles wrote:
>
>>
>> As to building an aggregated "Java" project, I think the blocker will be
>> supporting conflicting deps. For IOs like ElasticSearch and runners like
>> Flink the conflict is
This could be a backward-incompatible change, though that notion has many
interpretations. What matters is user pain. Technically if we don't break
the core SDK, users should be able to use Java SDK >=2.11.0 with KafkaIO
2.11.0 forever.
How are multiple versions of Kafka supported? Are they all
On Mon, Apr 1, 2019 at 2:00 PM Kenneth Knowles wrote:
>
> As to building an aggregated "Java" project, I think the blocker will be
> supporting conflicting deps. For IOs like ElasticSearch and runners like
> Flink the conflict is essential and deliberate, to support multiple
> versions of other
Yes, need to use the new fields everywhere and then deprecate the old
fields.
On Mon, Apr 1, 2019 at 1:33 PM Kenneth Knowles wrote:
>
>
> On Mon, Apr 1, 2019 at 8:59 AM Lukasz Cwik wrote:
>
>> To clarify, docker isn't the only environment type we are using. We have
>> a process based and
As to building an aggregated "Java" project, I think the blocker will be
supporting conflicting deps. For IOs like ElasticSearch and runners like
Flink the conflict is essential and deliberate, to support multiple
versions of other services. And that is not even talking about transitive
dep
On Mon, Apr 1, 2019 at 8:59 AM Lukasz Cwik wrote:
> To clarify, docker isn't the only environment type we are using. We have a
> process based and "existing" environment mode that don't fit the current
> protobuf and is being worked around.
>
Ah, understood.
> The idea would be to move to a
Hi,
I mean that I did change on a local branch to be able to do:
./gradlew :beam-sdks-java:build
and/or
./gradlew -p sdks/java build
Regards
JB
On 01/04/2019 19:47, Michael Luckey wrote:
> Hmm... now you lost me :(
>
> Currently I am not able to do a
>
> $./gradlew -p sdks/java build
> It
+1 thanks for noticing and raising yet another source of non-hermeticity
(plus the docker constraint)
On Mon, Apr 1, 2019 at 9:09 AM Andrew Pilloud wrote:
> +1 on this, particularly removing the dead link checker from default
> tests. It is effectively testing that ~20 random websites are up. I
+1 if possible, removing link checks would be nice too, if they are
unreliable and there is a way to disable them.
On Mon, Apr 1, 2019 at 10:33 AM Mikhail Gryzykhin wrote:
> +1 on this. I'd prefer to have this as pre-commit only.
>
> On Mon, Apr 1, 2019 at 9:09 AM Andrew Pilloud wrote:
>
>> +1
Hmm... now you lost me :(
Currently I am not able to do a
$./gradlew -p sdks/java build
It fails with error
Project directory '/Users/michel/GitHub/adude3141/beam/sdks/java' is not
part of the build defined by settings file
on my machine, which - again - should be expected.
Regarding the
+1 to remove 0.9 support.
I think it's more interesting to test and verify Kafka 2.2.0 than 0.9 ;)
Regards
JB
On 01/04/2019 19:36, David Morávek wrote:
> Hello,
>
> is there still a reason to keep Kafka 0.9 support? This unfortunately
> adds lot of complexity to KafkaIO implementation.
>
>
Hello,
is there still a reason to keep Kafka 0.9 support? This unfortunately adds
lot of complexity to KafkaIO implementation.
Kafka 0.9 was released on Nov 2015.
My first shot on removing Kafka 0.9 support would remove second consumer,
which is used for fetching offsets.
WDYT? Is this support
By the way, another reason is to have this clearly displayed in
./gradlew projects ;)
On 01/04/2019 18:49, Michael Luckey wrote:
> Hi,
>
> although I did not yet manage to get deeper involved into actual
> development, I think this ability would be a useful addition.
>
> But I would also like
Hi Michael,
Yes, I know the -p option and it's currently what I'm using.
However the proposal is also in order to have some more "consistent"
with other modules.
Regards
JB
On 01/04/2019 18:49, Michael Luckey wrote:
> Hi,
>
> although I did not yet manage to get deeper involved into actual
>
+1 on this. I'd prefer to have this as pre-commit only.
On Mon, Apr 1, 2019 at 9:09 AM Andrew Pilloud wrote:
> +1 on this, particularly removing the dead link checker from default
> tests. It is effectively testing that ~20 random websites are up. I wonder
> if there is a way to limit it to
During the gradle migration, we used to have something like:
include(":sdks:java:core")
include(":sdks:java:extensions:sql")
include(":sdks:python")
but we discovered the Maven module names that were used during publishing
were "core" / "sql" / ... (effectively the directory name) instead of
Hi,
although I did not yet manage to get deeper involved into actual
development, I think this ability would be a useful addition.
But I would also like to point out, that this is kind of implicit, as soon
we get https://issues.apache.org/jira/browse/BEAM-4046 included.
For instance, we would
Welcome!
On Mon, Apr 1, 2019 at 9:22 AM Ahmet Altay wrote:
> Welcome to the project!
>
> On Mon, Apr 1, 2019 at 6:23 AM Ismaël Mejía wrote:
>
>> You have now the Contributor role, and I assigned the ticket you asked
>> for.
>> Enjoy!
>>
>> Ismaël
>>
>> On Mon, Apr 1, 2019 at 12:35 PM
Welcome to the project!
On Mon, Apr 1, 2019 at 6:23 AM Ismaël Mejía wrote:
> You have now the Contributor role, and I assigned the ticket you asked for.
> Enjoy!
>
> Ismaël
>
> On Mon, Apr 1, 2019 at 12:35 PM Madhusudhan Reddy Vennapusa
> wrote:
> >
> > Hi,
> >
> > This is Madhu, I am
Personally, I would like to suppress the warnings globally. I think
requiring javadoc everywhere is already enough to remind someone to write
something meaningful. And I think @param rarely adds anything beyond the
function signature and @return rarely adds anything beyond the description.
Kenn
+1 on this, particularly removing the dead link checker from default tests.
It is effectively testing that ~20 random websites are up. I wonder if
there is a way to limit it to locally testing links within the beam site?
On Mon, Apr 1, 2019 at 3:54 AM Michael Luckey wrote:
> Hi,
>
> after
To clarify, docker isn't the only environment type we are using. We have a
process based and "existing" environment mode that don't fit the current
protobuf and is being worked around.
The idea would be to move to a URN + payload model like our PTransforms and
coders with a docker specific one.
Hi guys,
I would like to introduce a Gradle "meta" project for the build:
beam-sdks-java.
The idea is to simply build all Java SDK related resources (core, IO, ...).
The purpose is also to be aligned with the other SDKs which provide
beam-sdks-go and beam-sdks-python.
Thoughts ?
Regards
JB
--
Hi,
currently our console output gets cluttered by thousands of Javadoc
warnings [1]. Most of them are warnings caused by missinlng @return
or @param tags [2].
So currently, this signal is completely ignored, and even worse, makes it
difficult to parse through the log.
As I could not find a
You have now the Contributor role, and I assigned the ticket you asked for.
Enjoy!
Ismaël
On Mon, Apr 1, 2019 at 12:35 PM Madhusudhan Reddy Vennapusa
wrote:
>
> Hi,
>
> This is Madhu, I am interested to contribute to Apache Beam.
>
> Can someone please add me as contributor, I would like to
High Priority Dependency Updates Of Beam Python SDK:
Dependency Name
Current Version
Latest Version
Release Date Of the Current Used Version
Release Date Of The Latest Release
JIRA Issue
future
0.16.0
0.17.1
2016-10-27
Do not worry. It seems next to impossible to stumble upon this issue if
tests developed on 'prepared' machine. This seems to be a side effect of a
used library which seems difficult to expect.
Thanks for looking into that. FWIW I opened an issue and assigned it to you
[1]. Feel free to reach out
Hi,
after playing around with Gradle build for a while, I would like to suggest
to remove ':beam-website:testWebsite target from Gradle's check task.
Rationale:
- the task seems to be very flaky. In fact, I always need to add '-x
:beam-website:testWebsite' to my build [1]
- task uses docker,
Hi,
This is Madhu, I am interested to contribute to Apache Beam.
Can someone please add me as contributor, I would like to assign tasks
which i can work upon. My jira username is *sudhan499*
Also I am interested to start with starter task(
https://issues.apache.org/jira/browse/BEAM-3344). Can I
33 matches
Mail list logo
