Build updates
Tuesday, June 2nd, 2009 | No Comments
A recent release of our parent poms, v9, introduces the following changes and improvements:
* 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,
Winstoned !
Tuesday, December 23rd, 2008 | No Comments
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:
./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.
Growing and shrinking
Wednesday, December 10th, 2008 | No Comments
Two exciting things happening at once !
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.
IE6 on OSX
Wednesday, October 22nd, 2008 | No Comments
Yes, some people still have to go through the pain of using Internet Explorer … 6. Tonight, that’s me. After loosing (too much) time getting a virtual machine or a remote desktop to a windows machine, and then on said machine getting an IE6 to actually work (Multiple_IE never really worked for me, and Microsoft’s 400mb of disk image for doing the same with a single version of IE is still downloading…), I stumbled accross Darwine (Wine for OSX) and … yes, IEs4osx.
So, without further ado, if you have to suffer, but are no masochist, it’s a simple as that: http://www.kronenberg.org/ies4osx/ !
Codepress for Magnolia ?
Tuesday, October 7th, 2008 | 11 Comments
I was looking for a simple way to get line numbers in html textareas - amongst other things to edit css, javascript and templates from within Magnolia, making my whole layout activatable/versionable ! - and I just stumbled upon Codepress ! Man, that thing is sweet ! (if you use Firefox, that is)
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 ?
News from Bob !
Thursday, September 4th, 2008 | No Comments
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
On code readability
Monday, June 23rd, 2008 | No Comments
It’s always been a subject for long and sterile debates. And yet, every now and then, I feel the itch and need to scratch it a little: coding style. Coding conventions. Javadoc usage. And whenever this comes up, it mostly ends up in “let’s update the eclipse/idea configuration files” or just “hum, yeah, we should look into this at some point” sort of reactions.
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. › Continue reading
Updating to Maven 2.0.9
Friday, June 20th, 2008 | No Comments
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.
Startup tasks, voters and irony
Wednesday, May 14th, 2008 | No Comments
A recent spike a rewriting the cache module ironically has me looking at startup tasks again; a feature I’ve never been too fond of, even though I clearly see the need. (My take on this is that these tasks should be executed through the ModuleLifecycle instead of this patchy wooden leg, but that would require some more work which we’re not ready to do right now.)
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. › Continue reading
Search
Recent Comments
Wordle :)
