Maven 1

upgrade to dom4j 1.5 and see what breaks. We need to do this because Jelly has also upgraded and we are using CVS HEAD there in 1.1

this went smoothly... a little TOO smoothly if you ask me

I knew it was too good to be true... a lot of the JSL stuff is behaving strangely. Need to fix that, and also check xdoc still works with Maven 1.0.x.
Problems so far:

• CDATA content seems to be ignored instead of picked up as text(), even though doing it in the JSL test suite works (maybe it was inadvertantly using dom4j 1.4 through the running maven)
• some of the $nav stuff (menu headers and links) are not rendered, but their children are (for links, through the wrong template)

only the CDATA issue remaining. See JAXEN-67.
Other bug has been fixed post 1.5.2, so will need a 1.6 release of dom4j to use it.

no fix for the cdata bug in sight, and upgrading to jaxen 1.1-beta-6 made things go downhill (see the failure in gump of the jelly xml tag library - this affects basically every maven plugin in existence).

I don't really have time to bugger around with this any more, so I'm
going to see if the dom4j 1.4 release will work as before. My main
concern with sticking with 1.4-dev-8 is that there is no way to locate
the sources.

We can live with the bugs in 1.4 (as we already are).

If anyone with some knowledge of dom4j and jaxen wants to put their hand
up to work through it and get up to dom4j 1.6/jaxen 1.1, please say so.

Please do not use dom4j 1.4 or earlier. It has some license issues that weren't corrected until about 1.6. I have to check on the exact version, but I'm pretty sure 1.4 is too early to contain the fix.

OK. I checked. 1.5.2 is the first version that's kosher. You really shouldn't use anything earlier.

Elliotte - can you please elaborate on what the issues are. We can't use dom4j 1.5.2 because it is not backwards compatible and I was unable to get it to work with Jelly.

I suppose it is the use of the Aelfred2 parser that was removed in the 1.5.2 release (http://www.dom4j.org/changes-report.html#1_5_2).
But I have to agree with Brett, this is a complete blocker for us if CDATA sections are being swallowed. If we can't use it for licensing issues, what alternatives would we have?

If its the Aelfred2 parser, we don't use it. We can surgically remove it from the JAR. The dom4j project should also ask us to retract or update the releases from ibiblio.

We should just stay on 1.4, at least until Jaxen releases 1.1 and Jelly upgrades.

The AElfred parser is indeed the problem I was referring to. If you pull it out of the JAR file, dom4j 1.4 should be license-kosher.

if you've shipped this previosuly yourseld you shoudl probably delete or replace those archives when you get a minure.

dom4j 1.4 causes MPXDOC-188 (and MPXDOC-38.) (note that even though they are marked as closed, the issue isn't fixed yet.)

I just bootstrapped Maven-1.1-beta-3 with dom4j from cvs branch DOM4J_1_X_BRANCH which includes a fix for http://tinyurl.com/5c4l3 .
This seems to have fixed the CDATA bug mentioned above and AFAICT now, everything else works fine as well. Need to do some more testing though, and maybe someone else can confirm that independently before we commit.

This is a very good thing. Did you contact the dom4j team to see if a release planned ?

Yes, I left a request at the link above, but didn't get a response yet. I'm thinking about putting our own version on ibiblio, I have tested it since my comment above and haven't found any issues. WDYT?

I'm putting this to blocker status now as we have to resolve at least the licensing issue and also to mark it as something we really have to fix for beta-3 (contrary to most of what is scheduled now ). Note that if we manage to upgrade dom4j, we have to publish new versions of the changes and xdoc plugins which will need a dependency on jaxen too because of API changes in dom4j.

Upgraded to our custom version (see MAVENUPLOAD-953). Let's see how that works...