Many thanks for the answers!

So, basically, there is no use to cut the process to two parts: merge (with JsonA) and compile/build (with JsonB), so, if i'm doing it in two steps, i'm wasting time on the all build, right? since it compile on the merge stage (as well to the build stage)

The time is waste on the merging, over and over again, to the same PBLs that we merging, is there a way to avoid this merging?

The suggestion above is great solution, but all the legacy PBLs are too tighten for taking few of them as shared service (which is indeed, better architecture) 

Since my project is not on the GIT (yet, i have plans to move there) the ws_objects is not relevant, in this case, when no ws_objects present, it based on the PBG for every PBL?

Many thanks

Hi Amit,

The merge principle of AutoBuild is the same as PB IDE, both are based on the file structure in ws_objects. It has nothing to do with the list of PBLs in the project.

You can keep the

PBLs that do not need to be used can be stored in separate repositories.

Regards,

Kitty

Many thanks for the response,

The issue is that it's an old legacy spaghetti code.

Why does the merging process merge PBLs that are not mentioned on the JSON?

Thanks

Hi Amit;

  Just my $0.02 but I would remove all the shared PBLs from all your projects & create a separate shared framework App compiling those PBLs into PBDs.

  Then copy the shared logic to each app that uses them in PBD format. Then add those shared libraries to the main app library list as a PBD keeping the App logic in PBL format.

   Now you can deploy a new version of the shared logic when each App is ready to pickup a new release of that shared logic, each app has all the libraries within their domain and the shared project manages the shared code source control wise.

Food for thought.

Regards ... Chris