Scale outSee also http://www.z2-environment.net/blog/2013/01/z2-deployment-potpourri/
BenefitsNo build engineering→ No local build config, fast dev setupSmaller checkouts, no deploy→ Less re-compiling, faster roundtripsSystem-centric→ Always up-to-date, always integratedPull-approach→ Easy to scale-out
Does this work … really?Can you do normal Java Apps with that?Absolutely!Just wait a few minutes…
Real world buildsExample: SaaS project in production• ca. 350 kLoC Java in 15 Maven modules• Full mvn rebuild (w/o tests) in 4.5 min• Full deploy and restart in roughly 15 min• Produces a few Web apps and some
Development workflow1. Pull changes / clone the whole project2. Make sure IDE can deploy & run the apps3. Change & Commit4. Rebase, re-build, re-deploy, re-test5. Push6. Wait for CI to show a green light
Lots of frequently broken assumptions:• Do you have the right runtime config?• Does you IDE produce the real output?• Are you changes incorporated elsewhere?Slow and error-prone!Gets harder and harder!What happened?
What is happening here?Build tool + IDE + Youvs.A structural mismatch!
Yet another case of impedance mismatchProject Structure≠Execution & Deployment Model
Is that really so bad?• Problem stays small if projects stay small• Successful applications however:• Do not stay small• Do not de-compose into independently versionedsmall projects easily• Productivity goes down
So Maven does not deliver?Maven solves an importantcollaboration problem:Sharing assets amongindependent organizationsThe re-use mechanisms stopworking well at more complexsolutions.It does not scale that well withinone organization what workscollaboratively on one solution!
For example:A Java component that holdsimplementation and API types of the modulecom.zfabrik.sample.digester.adminA Web app component that will be loadedby the Web container. In this case a VaadinApplication with Spring.Another Java component. This one holdsdomain definitions and is re-used fromother modules.