Java project is getting too big

Question

We have a large Java 8 Spring Hibernate Maven project that is getting bigger.

Problems:

• Build time is 10-12 minutes at best; 3 minutes without tests
• We already have a command line switch to skip rarely modified modules, which is a symptom of the build process, reaching practical limits.
• Eclipse is trying to manage the project (although IntelliJ is fine)
• It worsens more and more as the project grows, and as more and more scripts from the test team become integration tests in the code base.

How we work now

• The project is configured in approximately 20 Maven modules, for example:

  Parent
     | --- Tier1
     | --- Tier2
     | --- WebTier
          | ---- ModuleA
          | ---- ModuleB
          | ---- ModuleC
          | ---- ...
          | ---- Entities
          | ---- Shared
          | ---- Batch
          | ---- IntegrationTests

• Application built as one WAR
• Developers deploy one layer (usually WebTier ) as an artifact from Eclipse or IntelliJ to their local Tomcat
• Although the project seems well-separated in modules, there are many undesirable connection points between them. Especially in Shared , where modules requiring cross-module access host their services
• All integration tests are in a dedicated module (I don’t know why)

Ideas to make it better

• Add a MessageBroker module to provide a free connection, if necessary. Perhaps JMS or just a dumb component of memory for synchronous communication.
• Get rid of the Shared module
• Make sure the modules have coarse entry points.
• Remove unwanted communication between siblings and, if possible, prefer a message broker.
• You can save Entities . At least the main companies (Customer, CustomerFile, ...). But some objects obviously belong to the same module (information about the package will be in the Batch module)

Thus, anyone who makes changes to ModuleA will build and run tests in this module most of the time without fear of breaking the application.

Questions

• Does this sound like a good plan? Fortunately, I mean future evidence that has good chances to improve the situation and does not require excessive workload, given the situation.
• If we have 1 Eclipse / IJ project per level, let the IDE build an artifact and deploy it to Tomcat, or do we have 1 project per module and Nexus dependencies? Or maybe the last option is redundant?
• Any other suggestions?

Some indicators

• Windows 7, Java 8, Maven 3.0.3, TestNG.
• SSD or 7200 rpm HDD (limited exposure)
• RAM 6 GB
• A bunch of 1Gb (maven)
• CI with Jenkins

Thanks a bunch!

Answer 1

CI will be the real answer, but it looks like your project is not modular, as it should be. Each time you do not build the whole project from scratch. You build banks, test them in different projects, and then use them as separate elements. Each project should be small enough and cover only one area. Do you think Java builds allow you to talk about security banks when they work with the io package? Divide and conquer - that's the whole idea of ​​OOP and encapsulation.

Answer 2

It may not be as bad as you think. Accepted projects with unit tests and static analysis take some time.

The company I worked with had> 1hr build + unitTest + CodeCoverage integration time. This does not take into account the time it takes to send an artifact to vSphere to automatically test end-to-end installer testing on supported OSs in 26 x 8 languages.