ust plain shell commands stitched together.
>> The only real problem that I face in my setup is the vendored java jars
>> which only impact java development.
>> Probably documenting separate environment specific setup for each language
>> is sufficient to address the issue.
>&
n
> tasks are just plain shell commands stitched together.
> The only real problem that I face in my setup is the vendored java jars
> which only impact java development.
> Probably documenting separate environment specific setup for each language
> is sufficient to address the issue.
Le mer. 10 oct. 2018 21:31, Robert Bradshaw a écrit :
>
>
> On Wed, Oct 10, 2018, 4:56 PM Romain Manni-Bucau
> wrote:
>
>>
>>
>>
>> Le mer. 10 oct. 2018 à 14:59, Maximilian Michels a
>> écrit :
>>
>>> Hi,
>>>
>>> I agree that splitting up Beam into separate repositories would cause
>>> more
On Wed, Oct 10, 2018, 4:56 PM Romain Manni-Bucau
wrote:
>
>
>
> Le mer. 10 oct. 2018 à 14:59, Maximilian Michels a
> écrit :
>
>> Hi,
>>
>> I agree that splitting up Beam into separate repositories would cause
>> more pain than gain.
>>
>> To a large degree we already have independent modules,
only real problem that I face in my setup is the vendored java jars
which only impact java development.
Probably documenting separate environment specific setup for each language
is sufficient to address the issue.
I also agree with Max that splitting the repo will cause more pain than
gain.
~Ankur
Le mer. 10 oct. 2018 à 14:59, Maximilian Michels a écrit :
> Hi,
>
> I agree that splitting up Beam into separate repositories would cause
> more pain than gain.
>
> To a large degree we already have independent modules, e.g. runners/* or
> sdks/*. Although this is not the case for the core. It
Hi,
I agree that splitting up Beam into separate repositories would cause
more pain than gain.
To a large degree we already have independent modules, e.g. runners/* or
sdks/*. Although this is not the case for the core. It would be
desirable to break it up further.
> possibly even with
This looks functionnal whereas the split is more about languages and making
the build smooth and efficient to work with to get back up to speed.
Runners can stay in java land/subproject while they are not in other
languages for instance so the api between core and runner can stay as it
for that
On Wed, Oct 10, 2018 at 10:25 AM Romain Manni-Bucau
wrote:
> On the split point: a mono-repo works for me as well. The main point is "N
> separate builds".
>
> On the portable thing: currently runner integrates with portable api. It
> impacts all runner. The needed code is the same everywhere
Yep for the split
For the clean point it is quite linked to the build tools and fake env for
not native modules for the build tool (go for gradle which is java first
for instance). This is why having a real build which is natural per
language would be beneficial IMO.
Le mer. 10 oct. 2018 11:38,
Correct, it's more "module splitting" than repositories indeed.
Regards
JB
On 10/10/2018 10:35, Robert Bradshaw wrote:
> Gotcha. So this is more about dividing the code (particularly core) into
> finer modules, rather than splitting the modules into separate
> repositories, right?
>
> On Wed,
On Wed, Oct 10, 2018 at 10:35 AM Romain Manni-Bucau
wrote:
> Also we can get a more adapted build tool by area and not break the repo
> for each build. Go and python build always need a git clean for java users
> which is a big issue so let's build each subproject - that is what beam is
> today
Gotcha. So this is more about dividing the code (particularly core) into
finer modules, rather than splitting the modules into separate
repositories, right?
On Wed, Oct 10, 2018 at 10:29 AM Jean-Baptiste Onofré
wrote:
> The purpose is that we have a monolithic core today mostly providing
>
Also we can get a more adapted build tool by area and not break the repo
for each build. Go and python build always need a git clean for java users
which is a big issue so let's build each subproject - that is what beam is
today - as they should with an adapted tool.
It requires very few
The purpose is that we have a monolithic core today mostly providing
abstract classes.
The idea is to have something more API oriented with interface/SPI.
Our users would then be able to pick the part of the core they want,
resulting with lighter artifacts, and for us, it gives a more flexible
My question was not whether we should split the repo, but why? (Dividing
things into more (or fewer) modules withing a single repo is a separate
question.) Maybe I'm just not following what you mean by "more API
oriented." It would force stabler APIs.
On Wed, Oct 10, 2018 at 10:18 AM
On the split point: a mono-repo works for me as well. The main point is "N
separate builds".
On the portable thing: currently runner integrates with portable api. It
impacts all runner. The needed code is the same everywhere since it is
mainly a DoFn at the end (a bit caricatural but that is the
Hi,
+1, even I think we could split the core even deeper.
I discussed with Luke and Reuven to introduce core-sql, core-schema,
core-sdf, ...
It's not a huge effort, and would allow us to move forward on Beam "more
API oriented" approach.
Regards
JB
On 10/10/2018 10:12, Robert Bradshaw wrote:
Hi everyone,
While IMHO it's too early to even be able to split the repo, it's not to
early to talk about it, and I wanted to spin this off to keep the other
thread focused.
In particular, I am trying to figure out exactly what is hoped to be gained
by splitting things up. In my experience, a
19 matches
Mail list logo