Finally got around to mapping all of the plugin issues that might constitute a Maven 1.0 release.

All of the functional issues are mapped for RC3, with further documentation issues and issues arising from RC3 to be done by 1.0.

As it stands there are 31 functional issues to fix...
The Roadmap
with the plugin issues listed here:
MAVEN-1244

Of course, plugin development will continue and plugins will be released individually through 1.0 and onwards.

I'm hoping that a bunch of people will test RC3 to its limits to ensure we have as complete a release as possible for Maven 1.0.

Among recent fixes was the second oldest open bug:
MAVEN-37
project.properties is now inherited along with your project.xml file.

After a long break, the Sydney JUG meeting was on again last night and had the privilege of seeing Mike Cannon-Brookes deliver another talk on SiteMesh (he originally spoke about it in the context of java.blogs at SJUG last July.

I gave a thought to investigating it at the time - and got as far as downloading 1.5 and reading the docs (the ones that weren't marked TODO at least!), but didn't see the advantages over Tiles.

However, it was good to see it given more attention last night and got to learn about some more advanced features like DecoratorMappers and inline decorators.

It is more obvious now that SiteMesh might be the better solution for us, even in a Struts environment.

The advantages I see in SiteMesh over Tiles are:
- a lot less configuration by applying layouts to a bunch of pages by a pattern, rather than having to cut and paste definitions for each page in tiles (even though they extend a common base, you still need 4 lines per page per skin)
- an easy way to skin by using a ParameterDecoratorMapper to pick a skin (this could easily be replaced with some other technique - we use the domain name of the request). Tiles could do this but I found it quite slow at the time because of the subrequest to select the template JSP, and have just dealt with copying all the defs for each skin up until now.
- the fact that it splits both the template/decorator and the page/fragment content as a complete HTML file that you can style is a big win when you work with a separate team of HTML designers that don't want to deal with JSP.
- I think it may be faster - I'll be taking this for a spin today and will report back :)

Good luck at the TSS Symposium Mike!

Mike Spille has written an article about Ant 1.6 at TSS (see post here).

One comment from the article:

And with any luck, maybe the <import> task will be the final nail in Maven's coffin!!

Ok, first I'll set my own position straight: I think Ant is fantastic at what it does and the basis of a lot of Maven's plugin functionality uses Ant to provide the tasks.

Apart from the truthfulness of this statement, it's obvious that Mike hates Maven, and that he's not alone. So why do you hate maven?

To be honest I hear complaints all the time but rarely see anything that gives a balanced reason for it, so I'd love to hear what really is the cause of such passion about it.

I can think of a few reasons and have taken a bit from those postings, and I'll start with the biggest one:

Because you hate Jelly

Well you're not alone! As has been mentioned, even the author has publicly apologised for it and moved on to better things.
It has its fair share of bugs and Maven bears the brunt of this a lot. Having said that, it does do some things pretty well once you get used to it and you can get by in Maven without ever needing to use the nasty bits.
And there is light at the end of the tunnel: future versions of Maven will support other scripting languages.
So is it just Jelly that disgusts you, or is it something else?

Because Maven doesn't improve on Ant

I've heard this too. Everyone seems to think that automatic dependency handling, unit testing and reusable components are easy in Ant (especially with the new 1.6 features),
Howeverm this is usually by cut-and-paste from some other build. Being able to &t;import> a custom component will only yield the same problems Maven has about customisation complaints (see below).
And I've seen too many bad Ant build scripts (and this example is by no means the worst)
to think this is true.

Because Maven doesn't let you customise your build

Ok, maybe this is a lack of documentation, but what sort of customisations do you want to do that you can do in Ant and not easily in Maven?
(the stumbling block in many cases here may be Jelly too, which is fair enough).

Because Maven just generates useless project sites

Yes, a lot of the documentation isn't used as often as it could be. And you may think the Maven web site is ugly and being inflicted on unsuspecting projects everywhere.
But it is achieving its purpose. I bet if you have used one of these sites, you know exactly where to go to find the CVS information, the developer list, or the javadocs on any other similar project.
The sites can definitely get better, but there are certainly worse out there too - it's better the devil you know in my opinion.
What would make the generated sites more useful to you?

Because it has a bad reputation of being slow and buggy

At least one poster commented that they hadn't used Maven but that it just has a bad reputation.
Is that what worries you? And what would put your mind at ease and give Maven a try?
Maven has been radically improved of late and is taking strides forward in this area.
It is now faster and uses less memory.
Most of the common bugs that have bitten people have been fixed. The few that haven't been fixed have a documented reason as to why they will be treated in a later version (this is always because there is a decent workaround and it doesn't fit the current schedule and architecture).
The team are actively working with large projects to help them overcome issues and take the tool forward.

Because of something else

Post a comment - let's not make this a flame war, but constructive criticism is welcome here.