1. Stop wasting your time with Java build tools
Henning Blohm
Henning.blohm@zfabrik.de – ZFabrik Software KG

2. Part 1:
No need for build infrastructure
–
In particular not for large projects

3. What‘s missing?
Why would you need more than that?
Source code and
configuration
Execution Environment

4. Just works!
You do not! In fact, this is how
• Large business solutions (SAP ABAP),
• Your favorite scripting language,
• Even stuff like Apache OfBiz
work.
Note: I did not say compile-free!

5. This is also how Z2 works!
Z2-Environment:
• Pull from various sources
• Do whatever is needed to run

6. Development with Z2

7. Scale out
See also http://www.z2-environment.net/blog/2013/01/z2-deployment-potpourri/

8. Benefits
No build engineering
→ No local build config, fast dev setup
Smaller checkouts, no deploy
→ Less re-compiling, faster roundtrips
System-centric
→ Always up-to-date, always integrated
Pull-approach
→ Easy to scale-out

9. Does this work … really?
Can you do normal Java Apps with that?
Absolutely!
Just wait a few minutes…

10. Part 2:
Why build tools are actually harmful

11. Real world builds
Example: 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

12. Development workflow
1. Pull changes / clone the whole project
2. Make sure IDE can deploy & run the apps
3. Change & Commit
4. Rebase, re-build, re-deploy, re-test
5. Push
6. Wait for CI to show a green light

13. 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?

14. What is happening here?
Build tool + IDE + You
vs.
A structural mismatch!

15. Yet another case of impedance mismatch
Project Structure
≠
Execution & Deployment Model

16. 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 versioned
small projects easily
• Productivity goes down

17. So Maven does not deliver?
Maven solves an important
collaboration problem:
Sharing assets among
independent organizations
The re-use mechanisms stop
working well at more complex
solutions.
It does not scale that well within
one organization what works
collaboratively on one solution!

18. Part 3:
Z2 & a demonstration

19. Overcome the impedance mismatch
In Z2:
• Repository structure = runtime model
• Deploy becomes Synchronize

20. For example:
A Java component that holds
implementation and API types of the module
com.zfabrik.sample.digester.admin
A Web app component that will be loaded
by the Web container. In this case a Vaadin
Application with Spring.
Another Java component. This one holds
domain definitions and is re-used from
other modules.

21. Demo
Now, let’s take a look (demo)

22. Is there a technology barrier?
Typically, Java frameworks are coming along
nicely with Z2. For example:
• Spring
• Spring AspectJ
• Hibernate
• Hadoop & HBase
• Groovy
• Jax-WS
• Vaadin
• RAP
• BIRT
• …

23. Modes of Operation
• Full-fletched w/ Worker Processes
• Most-flexible, most powerful
• Inside another Web Container
• If that’s a given
• Command line
• Extends solution with CLII

24. Summary
Java Build tools for business solutions are a
remnant of the past
If you do not need to deploy on Websphere
et al, consider leaving that past behind

25. Want to be involved?
Z2 is Open-Source Software
If you think this interesting and useful, if you
want to participate, adapt, or improve:
Get in touch with us!

26. Powered-by

27. Wiki & Forum:
http://redmine.z2-environment.net/
Blog:
http://www.z2-environment.net/blog/

28. Where would you rather be?