Yep. Worked on application like that, too, albeit with only something like 140 modules maintained by team of 20.
It had a repository in subversion but modules were versioned by their owners by making copy of the code in a new folder with version in the name.
Builds were not automated and instead each module owner built it manually in Eclipse and "uploaded" them binaries to svn. Each module had a single owner, nobody else knew anything about the module except for the owner. Builds could not be executed when the owner was not available.
I was required to "prove myself" before I was given read access to module I was supposed to start my work on.
The application had a lot of problems in the form of "there was a bug a month ago and now it reappeared because somebody forgot to include the module in the updated version this deployment".
There was ostensibly a "database layer" but different versions of it were used throughout the application. The versions were really branches of it because they included workarounds for app-specific problems that they did not want to be present on other services for the reason of "stability". This of course made it a nightmare for me when I decided to create a proper Gradle build.
Each jar or class was updated separately. I spent a quarter trying to convince teams with their managers that just versioning everything together and deploying everything everywhere at the same time is going to be a better strategy. They said if updating single jars and classes causes so many problems then updating everything has no chance of working. 2 years after I made the change there was still not a single deployment that would fail.
It had a repository in subversion but modules were versioned by their owners by making copy of the code in a new folder with version in the name.
Builds were not automated and instead each module owner built it manually in Eclipse and "uploaded" them binaries to svn. Each module had a single owner, nobody else knew anything about the module except for the owner. Builds could not be executed when the owner was not available.
I was required to "prove myself" before I was given read access to module I was supposed to start my work on.
The application had a lot of problems in the form of "there was a bug a month ago and now it reappeared because somebody forgot to include the module in the updated version this deployment".
There was ostensibly a "database layer" but different versions of it were used throughout the application. The versions were really branches of it because they included workarounds for app-specific problems that they did not want to be present on other services for the reason of "stability". This of course made it a nightmare for me when I decided to create a proper Gradle build.
Each jar or class was updated separately. I spent a quarter trying to convince teams with their managers that just versioning everything together and deploying everything everywhere at the same time is going to be a better strategy. They said if updating single jars and classes causes so many problems then updating everything has no chance of working. 2 years after I made the change there was still not a single deployment that would fail.