Tibor, We understand your position.
We moved from separated SCM to one SCM. We can move back, but we don't want this. In single SCM we like: 1. Atomic commits 2. Single point of responsibility. If someone makes incompatible change in shared library, he is responsible to update all usages. At first look It can be considered as slowness in development, but it helps us to avoid growing of technical debt. We never get in situation when projects A, B, C, D... depends on different version of shared library and we need to make major upgrade, it can block release of some apps and etc... Now we releasing 20+ clients apps and 50+ backend components every week or even often. With multiple SCM we will need to hire a team of release managers and build engineers to coordinate and support this. Again, we are don’t selling our approach. We implemented the missing for us feature. PS. Just thing why commercial products like Gradle Maven Extensions appeared. From: Tibor Digana <tibordig...@apache.org<mailto:tibordig...@apache.org>> Date: Saturday, 14 Sep 2019, 9:43 PM To: Maven Developers List <dev@maven.apache.org<mailto:dev@maven.apache.org>> Subject: Re: [VOTE] Maven incremental build for BIG-sized projects with local and remote caching Alexander, Enrico is really right. Today it is Microservices and there every microservice is in a separate SCM repo. It was just only an example with Microservices but in my experiences you can always find the lower bound modules in the hierary which do not change so much and segragate them in another SCM repos. Those should undergo the release process, share release versions and avoid sharing SNAPSHOT versions. You can find the top roots which are actually applications. If you have 10 WAR files as a result of the build and all of them should be deployed, then there is a strong reason to separate them in separate SCM repos. Then this separation concept will guide you to isolate the middle layers into isolated services as JAR files. And then you endup with Microservices, SOA services and not JAR files or you will be much closer to them. the huge monolith project is gone. All the development process will be faster and more flexible than it was before. Just try! Cheers Tibor17 On Sat, Sep 14, 2019 at 5:23 PM Alexander Ashitkin <ashitkin.a...@gmail.com> wrote: > 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 <eolive...@gmail.com> 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 <ljnel...@gmail.com> ha scritto: > > > > > On Fri, Sep 13, 2019 at 11:01 PM Alexander Ashitkin < > > > alexander.ashit...@db.com> 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
