* Maven 2.0.10 : we now require Maven 2.0.10 to build Magnolia, through the enforcer plugin. Eclipse and IDEA users, rejoice, however, because we’ve made the configuration laxer: regular Maven invocations will require Maven 2.0.10 or a more recent version (which includes Maven 2.1 which Eclipse and IDEA use internally); only when performing a release will the enforcer plugin strictly require Maven 2.0.10.

* If you’ve had Clover license issues recently while attempting to build/release Magnolia, a module or project, rejoice. You now have two options:
1) live with the evaluation license that’s bundled in the Clover Maven plugin itself - this should work for a little while now, as I’ve just updated the pom to use the latest version of Clover.

2) use your own license: the parent pom configures the plugin so that it uses a cloverLicenseLocation property. You can, for instance, define it in your ~/.m2/settings.xml file, using a profile, such as :
 <profiles>
   <profile>
     <id>my-default-profile</id>
     <activation>
       <activeByDefault>true</activeByDefault>
     </activation>
     <properties>
       <cloverLicenseLocation>${user.home}/.m2/clover.license</cloverLicenseLocation>
     </properties>
[...]
Provided that your license key is indeed in ~/.m2/clover.license

If the property isn’t defined in your settings.xml file, the plugin will fall back to the evaluation license. On the other hand, you’ll get an explicit error message if you define the property but make it point to an non-existent or invalid file.

Next step will be to provide a valid license for our open-source projects.

* We now keep track of the parent pom changes in Jira: see http://jira.magnolia-cms.com/browse/BUILD

* Magnolia 4.1 will require Java 1.5, but some modules might still be happy with 1.4, or might want to go ahead and use 1.6: we’ve introduced a ${javaVersion} property. If you want to build your project/module against 1.5, simply add a <javaVersion>1.5</javaVersion> property. The default is still 1.4, so that all modules can update to the new version of the parent pom without breaking compatibility. The main Magnolia project and some modules have this set to 1.5 now. Ideally, we won’t update this property to 1.5 for modules that don’t depend on Magnolia 4.1 yet.

* Projects and modules using the info.magnolia:magnolia-parent-pom-enterprise parent pom will now be deployed to http://repo.magnolia-cms.com/enterprise/. The transition is insured as all relevant other parent poms (-internal and -project) now have both the new /enterprise repo and the old /restricted repo (which shouldn’t be used anymore - contact me if doubts about this)

One final remark: there are still people out there who extend info.magnolia:magnolia-project in their own project. Don’t ! There is no good reason to do so. Likewise, if your project or module is not meant to be hosted here, there’s probably no good reason to use our parent poms (although if you do, please contact me or send a mail to the users list, I’d like to hear about it). What you want to do is probably build a project that *depends* on Magnolia. If you’re building a webapp with Maven (<packaging>war</packaging>), here’s an (outdated) example of how to do it: http://svn.magnolia-cms.com/view/community/modules/magnolia-webapp-documentation/trunk/pom.xml?revision=19481&view=markup If you are buliding a module, just have a look at any of the up-to-date modules under http://svn.magnolia-cms.com/view/community/modules

Until next time,

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:
./lib
./lib/commons-logging-api-1.1.1.jar
./lib/jasper-compiler-jdt.jar
./lib/jasper-compiler.jar
./lib/jasper-runtime.jar
./lib/jsp-api.jar

(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.

One, we’re finally getting rid of a bunch of old “stuff” in Magnolia’s main codebase. A very welcome diet, as some of that code has been lying around unused or deprecated for two years or more. It’s also a relief to see that this will incidentally increase our code coverage and/or help making some classes a little more testable. There’s still a long way to go in that area though !

Second, we’re moving a bunch of modules, which have been nurtured internally, to the community space. Watch out for

• In place templating - yes! You’ll be able to edit (Freemarker) templates directly from inside Magnolia ! Support for JSP isn’t impossible, but involved some much hassle (JSPs have to be on the file system) that we decided to leave that as an exercise for the reader. I’m pretty convinced everyone will love the Freemarker support we’ve introduced though. It takes a bit getting used to, but once you get the hang of it, it’s so much cleaner than JSP… <insert bad-taste pun about never coming back>.
• Resources - a simple module that allows one to handle web resources in a separate workspace and within Magnolia. CSS is currently supported, we’re hoping to add support for Javascript and images soonish, making this a one-stop shop for all your layout/design resources.
• Form - build simple forms within Magnolia, and process them. Elegant css-based layout for your forms, a simple API for processing the results.
• Webdav support - still experimental, but we’re hoping to get this to work for DMS, templates, and so on.

So, without further ado, if you have to suffer, but are no masochist, it’s a simple as that: http://www.kronenberg.org/ies4osx/ !

Unfortunately, their main site (codepress.org) seems down at the moment, and the Google-cached changelog page seems to tell me there’s been no release since a year. Does anybody what the real status is and/or is there’s any alternative ?

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.

• The Subversion repository structure has been completely overhauled. It’s now much easier to navigate AND to maintain. It is even documented !
• Checkout helper scripts have been unified and overhauled. Check ‘em ! Documentation above.
• Pom files have been overhauled too. Here’s a quick diagram of their structure.
• All poms inherit from a common parent which define a bunch of generic properties, plugins, and dependencies. Everything can be overridden, but it provides a stable basis.
• The lower level of parent poms (magnolia-parent-pom-community-module and so on) share a common site descriptor and skin (provided by magnolia-parent-pom-abstract) and provide the specific repositories and deployment locations.
• Thanks to the above, projects extending these poms now deploy their artifacts and sites in different locations without any hassle.
• Javadoc is now generated in both aggregated and non-aggregated forms ! This means that on the main Maven generated website, you can find aggregated Javadoc (includes Javadoc for all sub-modules) and non-aggregated Javadoc (Javadoc for a single module)
• All our projects now include a Clover report. (Which hopefully will become greener!)
• Archetypes for easily generating skeletons for Magnolia-based projects and modules are being overhauled as well !
• Our Maven repository should soon be synchronized with the central Maven repository. Follow MAVENUPLOAD-2194 and SYS-19 to be updated on this ! For starters, we might only have our parent poms synchronized, but that should be enough to be able to build any Magnolia module without struggling with pom inheritance.

Setting up code conventions is all about code readability. Readability being all but subjective, these can hardly be completely enforced by software. I’d rather rely on common sense, but too many factors (like the food you had for lunch) have an effect on your common sense. The few points I’m about to mention can probably not be enforced reliably by any kind of tool, other than yourself. In general, Sun’s coding conventions work for me, except for their “indentation” notes. Well, the note about indentation is absolutely correct is the one I’m actually the most anal about (indent on 4 spaces, a tab character is to be represented by 8 spaces, thank you eclipse, and please don’t use the tab character in the first place anyway), but their notes about line length and line wrapping, are just plain out of scope. Generally long lines will be harder to read, yes, but wrapping them won’t help. Wrapped statements are just impossible to read. We’re not in the 70s anymore, and nobody ever has to actually work in an 80 columns terminal. So don’t enforce line length, but factor your code instead ! I’d almost be in favor of enforcing a rule that would say that 1 statement == 1 line.

Related to the above, try avoiding complex statements. Introduce variables, even if they’re to be used only once in a if statement. Give them a meaningful name, and all of sudden your code almost becomes like natural language.

Consider the following statement:

if (parent != null && parent.getLevel() > level && parent.getChildren(//..blah).size()==0) {
 
 // .. do something
 
}

No, it is not *that* complex to read. Now consider the following:

final boolean hasChildren = (parent != null && parent.getLevel() > level &&  parent.getChildren(//..blah).size()==0);
 
if (hasChildren) {
 
 // .. do something
 
}

It was not simpler to write, but way simpler to read. Why, you ask? Most probably because you didn’t even read what was assigned to the hasChildren variable. Because it has a meaningful name, you don’t need to know how the value is assigned - unless there’s a bug, which your unit tests surely have covered.

If your code is readable, why clutter it with log statements? I am not about to run a war against logging here, because I see how it can sometimes be useful, but if a 10 lines methods is cluttered with 4 lines of logging, I am going to ask questions. I don’t have very specific examples or guidelines for this, but avoiding splitting log statements in multiple lines, or wrapping them in if statements would already be a good start. Always question their need before adding them. Well tested code is likely to require less logging, because the tests will give you the confidence that your code works the way you expect it to work; the debug log statements would only be there as a reassurance for when your less tested code will eventually fail.

One last point that has buggered me for a while: why clutter your code with javadoc comments that had absolutely no value and just duplicates what your code already says ? A few examples to illustrate my point:

/**
 * Logger.
 */
private static Logger log = LoggerFactory.getLogger(SomeRandomClass.class);

The variable name and its type said it all. Why waste 3 lines of my precious attention ? (remember most computer people suffer from ADD)

/**
 * Gets the foo value.
 */
public String getFoo() {

The method name told me that.

/**
 * Does something valuable for your business.
 * @throws SomeException when something is wrong with the business.
 * @throws SomeOtherException
 */
public void doSomething() throws SomeException, SomeOtherException {

Succinct method description: check. First @throws tag tells me in what condition the exception is thrown: this is useful; check. Second @throws tag: useless. Of course, in reality, this will rarely happen, and I’ll be more often that not baffled by some eclipse-generated javadoc like this:

/**
 * 
 * @throws SomeException
 * @throws SomeOtherException
 */
public void doSomething() throws SomeException, SomeOtherException {

… which is utterly useless. (In case you weren’t sure, yes, the generated javadoc will still document these exceptions if you omit the @throws tags.)

In short: javadoc is useful when you make it useful. In other cases, in just essentially makes the code unreadable. Class level javadoc often seems the most useful and less likely to get out of synch or irrelevant after 3 weeks. 

Well, this being now written for posterity, I feel much better. Hopefully this will help my point made whenever I bitch about code style and javadoc, and, woohoo, maybe, help improve the general quality and readability of our code.

So the only current usage of startup tasks in Magnolia itself is in the cache module. There are some projects out there who use the feature as well, most likely for sanity checks and recovery.These startup tasks were applying a sanity check, making sure the necessary minimal set of “voters” were in place for the cache. As the comment says, these could be disabled by setting their enabled flag to false. But there is no way to get rid of them. Every Magnolia restart would recreate them. Fair enough, especially since their configuration is not trivial.

Now, the cache module was rewritten. The decision of caching a page - or not - is done by the CachePolicy. The DefaultCachePolicy supports voters, just like the original DefaultCacheManager, hopefully in a less obscure manner: the voters list is populated using “content2bean”. But you could swap that policy for another. One which does not support voters. One which uses voters, but for a totally different purpose.

Given this, does it still make sense to force the existence of those voters in a specific location? (i.e. a specific node in the configuration workspace, which might or might not match the properties of the chosen CachePolicy implementation) Should the startup tasks check if the CachePolicy is the default one before possibly recreating the voters? I don’t think it should. If you mess up your configuration, 1) you can recreate it, 2) it can’t cause that much damage.

The only situation where this might get tricky is if you accidently remove the bypass on /.magnolia, since you won’t even be able to browse the configuration tree anymore. This can be overcome but is admittedly a bit tedious. Maybe Philipp’s recent spike at scripting could also help.

I’d vote (ha ha) for less magic(don’t fix stuff silently), more power to the user(let them do what they want), and better tools to fix user mistakes