130511 stop wasting_your_time

Stop wasting your time with Java build tools

Henning Blohm

Henning.blohm@zfabrik.de – ZFabrik Software KG

Part 1:

No need for build infrastructure

–

In particular not for large projects

What‘s missing?

Why would you need more than that?

Source code and configuration

Execution Environment

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!

This is also how Z2 works!

Z2-Environment:

• Pull from various sources

• Do whatever is needed to run

Development with Z2

Scale out

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

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

Does this work … really?

Can you do normal Java Apps with that?

Absolutely!

Just wait a few minutes…

Part 2:

Why build tools are actually harmful

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

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

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 + You

vs.

A structural mismatch!

Yet another case of impedance mismatch

Project 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 versioned small projects easily

• Productivity goes down

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!

Part 3:

Z2 & a demonstration

Overcome the impedance mismatch

In Z2:

• Repository structure = runtime model

• Deploy becomes Synchronize

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.

Demo

Now, let’s take a look (demo)

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 • …

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

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

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!

Powered-by

Wiki & Forum:

http://redmine.z2-environment.net/

Blog:

http://www.z2-environment.net/blog/

Where would you rather be?