CODEWITHSUNDEEP
javamaven
Xeperis
Xeperis

Reputation: 1459

Maven 2.2.1 optimizing project build times

I was pondering an idea and wanted to raise a question for developer community. As I work on a large scale JAVA project using maven in practice has an astonishing amount of benefits. However project is rapidly growing and more modules appear as days go by thus resulting in huge build times and what not that has an impact on continuous integration.

Question - is there some out of the box features that would allow a smart project building that could firstly check if a modules target jar differs from one located in local maven repository. If latter would be true maven could continue onto next module without rebuilding and redeploying identical one ?

Regards

Upvotes: 2

Views: 270

Answers (4)

Joop Eggen
Joop Eggen

Reputation: 109547

(Assumed: Team internal repositiory.)

Offline (if honored by the plugins) builds:

mvn -o ...

(Assumed: IDE builds bypassing maven (incremental compilation in the background.)

Limitation of cross module dependencies. It is so easy to import from other modules, that sometimes a tangled net of dependencies arise.

Upvotes: 0

MaDa
MaDa

Reputation: 10762

Question - is there some out of the box features that would allow a smart project building that could firstly check if a modules target jar differs from one located in local maven repository? [...]

The only "smartness" I know is to skip the "clean" phase in builds that you don't need — this way some sources won't be compiled, or resources needlessly regenerated. Still, project will be repackaged.

You might also consider excluding some modules into different development cycles (unless you really need to make changes in all of them in every release). Then the modules that change less often could be included as dependencies from the repository — they will need to be built and deployed separately.

Upvotes: 0

khmarbaise
khmarbaise

Reputation: 97389

Best thing is to switch to Maven 3 which supports parallel builds via 

mvn -T 3.0C clean package

what also can help is to build what has changed which can be achieved via Maven:

mvn -pl module -am package

also do many CI systems like jenkins support incremental build. Furthermore checking which kind of tests are running? Can you run unit tests in parallel ? (maven-surefire-plugin). Are these unit tests really unit tests or might some of them integration tests instead?

Upvotes: 2

Dan
Dan

Reputation: 1018

There's no panacea for this problem. It's a general one faced by many large scale projects.

The fact a CI is triggered is usually by a SCM commit so I'd suggest that something has always changed.

Without knowing what CI you are using, how the modules are configured etc I can't offer much advice beyond some basics.

1) Make sure the modules you configure in CI are as granular as possible - i.e. the smallest possible build-unit. This means that single commits don't require swathes of code to be rebuilt.

2) Developer Habits: Only commit a complete unit of work. This is kind of what Git is about. The developer commits locally and then only pushes to the master when the work-unit is completely finished. This reduces downstream CI builds.

3) Watch what reports and modules you use in Maven. Some take for ever to run. Do you really need them all?

Upvotes: 1

Related Questions