Embed Size (px)
DESCRIPTION
Citation preview
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?
