On Wed, Oct 10, 2018 at 9:21 PM Kenneth Knowles wrote:
>
> I think Robert's initial question needs to be focused on a particular split.
Yes, thank for bringing this back to the original question.
> I agree that a "single project spanning multiple repos" does not make sense.
> But separate
I think Robert's initial question needs to be focused on a particular split.
I agree that a "single project spanning multiple repos" does not make
sense. But separate projects in separate repos is pretty widely used :-). The
point of separate repos IMO would be to empower (and force) them to act
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,
Hi,
I think the subtext here is that development is hard in general. I agree to
it. And a major cause of it is diversity of languages, complexity of the
project and legacy code.
To alleviate language related issues, we are trying to have modular code
which we already have to a certain extent.
On
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:
18 matches
Mail list logo
