Therefor Pustefix (since 0.18.10) can visualize the so-called target dependency model, showing you how the XSL stylesheets on each transformation level are composed, which XSL transforms which XML, what XML parts and images are included, etc.

Besides showing the dependency model Pustefix also lists the XSL templates available on the selected transformation level. All XML/XSL files can be directly viewed/downloaded (even if coming from a module archive).

This view is generated as part of the pfxinternals page (e.g. locally accessible in development mode under http://localhost:8080/pfxinternals/targets).

Pustefix 1.0.0 has been released. This groundbreaking new release offers full OSGi support, i.e. Pustefix not just can be run inside an OSGi runtime, but Pustefix itself is built on the principles of OSGi, empowering you to modularize all aspects of a webapplication (business logic, view components, etc.) using an OSGi service based extension point mechanism.

Today we officially postpone OSGi support. Actually development stood still for more than a year because of the lack of adoption by our user community. To be honest we have to state that our OSGi experiment has failed and there are evident reasons.

I still think OSGi is a great technology and I’m sure there are a lot of use cases where OSGi already works very well, but the web application development scenarios targeted by Pustefix do not fit (yet).

In a way OSGi offers much more than we need, and at the same time not enough to make it worth paying the price for the effort of introducing a new programming model, a more complex development process and managing the various pitfalls when developing within an environment which itself is not yet ready for OSGi (infrastructure, tools, third party libraries, etc.).

But postponed is not abandoned and we’re looking forward to the modularization support coming with JDK 8, Project Jigsaw and JSR 294.

Starting from today the Pustefix main development will take place in the SVN trunk again. The OSGi implementation was moved to a branch and will be further available for backreference.

One reason for dropping support is the proprietary annotation processing in 1.5 (Sun’s deprecated apt tool) and the new standardized way in 1.6 (JSR269 Pluggable Annotation Processing API and JSR199 Java Compiler API), which will replace the apt tool in upcoming Pustefix releases.

Switching to the new annotation processing standard Pustefix now is also ready for upcoming Java releases. In general Java SE 7 can be already used with older Pustefix versions. I have only encountered a problem with Pustefix’s JAXWS/AJAX services, which will be fixed in the next 0.18 release (whereas it’s recommended to use the lightweight JSON services instead anyway).

If you still want to use JAXWS/AJAX services with older Pustefix versions and Java 1.7, you will have to upgrade to a newer JAXWS version, because the used JAXWS version stumbles accross the new getSuppressed() property in java.lang.Throwable when generating Exception beans. Additionally you will have to adapt the tools.jar Maven dependency because the java.vendor property used to activate the dependency profile changed from “Sun Microsystems Inc.” to “Oracle Corporation”.

Thus you don’t have to rebuild your modules when you modify a resource. Modified static resources and view parts (XML, XSLT) are automatically reloaded by Pustefix, modified configuration files (Pustefix, Spring) only will require a Webapp reload or Tomcat restart (but no build).

Since Pustefix 0.16 the most simple way to enable the Live-JAR mechanism is by specifying the pustefix.liveroot system property. Its value is the root directory where Pustefix will look for the backing Maven projects. Pustefix will also search sub directories, but for performance reasons the default depth is limited to 4 (it can be changed using the pustefix.liveroot.maxdepth property).

Here’s the example commandline for a Maven multi project with a webapp subproject from which you start Tomcat, whereas the other subprojects are found by using the main project as root using the relative path ..:

[/tmp/mainproject/webapp]$ mvn tomcat:run-war -Dpustefix.liveroot=..

Alternatively you can specify an absolute path:

[/tmp/mainproject/webapp]$ mvn tomcat:run-war -Dpustefix.liveroot=/tmp/mainproject