HI Enrico Thanks for feedback. that's a side discussion for best approach for projects layouts. Monorepo has own own advocates and it is easy to find posts describing why google, microsoft or facebook go monorepo. Unlike of way of thought, we are ready to go globally in case of emergency scenario. If say zero-day vulnerability is discovered in some of low-level widely reused core libraries, we need just one click to build/test/deploy and safely go live globally with whole estate updated on scale of thousands of processes. And you know, there are people in the world who think that scattered across small repos codebase is difficult to maintain and snapshots are evil. It all depends. Honestly, i think it will be it's a kind of reversed approach them you build system defines how your software development processes work. Google has own vision and just implemented Bazel and this is correct approach. Btw Bazel is perfect for such scenario, but costly to migrate on for existing project.
So if you choose monorepo as we did it is normal to work just on a part of project. You just need a way to deal with scalability challenges: a) you hit hardware and infrastructure limitations and need to address them in some way. b) need to have incremental build so you can work on subpart of project but contribute to shared codebase Sincerely yours, Aleks On 2019/09/14 08:41:37, Enrico Olivelli <[email protected]> wrote: > I feel that in general having an huge monolithic project is kind of a > project-smell. > Btw I have some big project with 100+ modules so I can see your pain. > In the daywork experience a single developer doesn't work on all of the > modules but usually you touch 1-2 modules and maybe some integration/system > test. > If you need to rebuild the full project for every change maybe there is > something wrong with the overall design. > > I think you have you motivations for your layout, so let's talk about your > proposal. > > If you have a way to split your project in subsystems you can use some > shared remote repository for deploying snapshots in order to share > intermediate results with other developers > > If your goal is to be ready for releases I don't get your point. Usually > you work with snapshots and for a release you have to rebuild one time and > only once the full codebase in order to ensure that you a consistent build > of the project. > With all of this kind of temporary caches how do you ensure that the final > artifacts are the intended ones? > > > Beside note: this is not a real VOTE thread > > Just my 2 cents > > don't get me wrong, I admire your will to improve Maven ecosystem with this > cool feature! Thank you for contribution your work. We will try to get the > best > > Enrico > > Il sab 14 set 2019, 08:29 Laird Nelson <[email protected]> ha scritto: > > > On Fri, Sep 13, 2019 at 11:01 PM Alexander Ashitkin < > > [email protected]> wrote: > > > > > This feature is true incremental build – you don’t build modules which > > > were not changed at all and build only modified/changed ones. > > > > > > > Suppose module B depends on module A and I change A. Does B get rebuilt in > > your system? > > > > Best, > > Laird > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
