In the previous episodes of this series of posts, we have built a Magnolia CMS-based project, and learnt about how to make it self-configurable. It’s deployable as-is, in your container of choice, but it is not production-ready: for example, you probably want to use an external database instead of the built-in Derby. In this article, we will see how to make this possible, without having to configure anything manually before each deployment. Continue reading
In the previous installment of this series of posts, we have created a new Magnolia-based project, including a reproducible build. We have a webapp that can be started in an IDE, or outside of it.
You might remember we added an STK theme to our project. And you might remember that it didn’t go all that well when we tried to view the first page we created. Continue reading
This is the first of a series of posts, where I will attempt to consolidate a set of practices for creating, building and deploying Magnolia projects.
Why, you ask ?
Over time, Magnolia has grown into a fairly complex, but beautifully flexible product. There are a number of features, techniques and tricks that can make one’s life much easier. Unfortunately, I still see a lot of folks building or deploying their projects in ways that make me cringe. Not that they’re doing awful things, no, but it seems it’s high time to gather a few tricks here that will hopefully make a few folks go “aaaaahhhh”, and perhaps even a few others cursing me for not telling them about all this earlier.
I’m happy to report that Magnolia seemingly works in Winstone !
With this simple command, it just worked (using the webapps of our latest 4.0 Milestone 2, as deployed in our current standard Tomcat-based bundle)
java -jar winstone-0.9.10.jar --useJasper --webappsDir=/Applications/MagnoliaEnterpriseEdition/apache-tomcat-5.5.27/webapps/
All that was needed is to have the following in a lib folder:
(which sadly adds 1.9mb to Winstone’s meager 300k)
A warning about tools.jar not being found can be safely ignored on OSX, at least if you have the developer tools installed.
Two worries left: 1) the JAAS configuration. I’m not sure if it’s handled properly. Magnolia itself needs improvement in this area anyway. 2) Performance. The performance in AdminCentral seems okayish, but browsing the demo site is utterly slow. It seems as slow as when Tomcat compiles JSPs… however there are no JSPs in these pages! Taglibs are used in FreeMarker templates, but we got rid of performance issues in that area ages ago, at least with Tomcat…
What’s next ? I’d love to see a clickable embedded version of Magnolia. With, say, a minimal Swing GUI or a CLI which would ask me what port I want to start it on, if I want to run an author or public instance, and if applicable, where the associated public instance is.
There has been some definitive construction work undergoing at Magnolia in the last few days, and this is what this post is all about: changes and improvements in our builds ! (Bob the Builder, geddit?)
It all started with a long standing need to restructure our Subversion repository, along with a desire to improve our Maven pom files. Both tasks were a bit daunting at first, but at some point, after long egg and chicken debates, it just became too itchy and I got started. Continue reading
There are a couple of cool improvements in there (most notably the fixed version of most plugins in the superpom – the end of our release plugin nightmares?), and now’s probably the best time to do this. (would admittedly have been even better prior to 3.6 M1, but hey) I’ll update the configuration of the maven-enforcer-plugin, so if you haven’t done so yet, and want to build Magnolia’s latest trunk, you’ll have to update your Maven installation too.