Maven 2.x Release Plugin

during a release several elements are removed from the pom.xml (which should be left there)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0-beta-4
  • Fix Version/s: 2.0-beta-8
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

the following elements are removed from the pom.xml, during a release...

<?xml version="1.0" encoding="UTF-8"?>

<!-- SVN keywords
$Author: $
$Revision: $
$Date: $
-->

<!DOCTYPE project [
<!ENTITY auml "ä" >
<!ENTITY ouml "ö" >
<!ENTITY uuml "ü" >
<!ENTITY szlig "ß" >
]>

Issue Links

This issue relates to:
MRELEASE-266 Content outside root elements in pom are not transfered to the release poms Major Open
This issue is related to:
MRELEASE-221 XML header missing in modified POM after release:prepare Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Emmanuel Venisse added a comment -

Can you test with beta-5 or beta-6? I'm sure it's fixed since beta-5

Show
Emmanuel Venisse added a comment - Can you test with beta-5 or beta-6? I'm sure it's fixed since beta-5
Hide
Permalink
Roman Cerny added a comment - - edited

just tested with <version>2.0-beta-6</version>

the plugin still removes all three entries (xml, svn keywords and doctype)

the plugin also changed a <developer><name> containing an umlaut from "&ouml;" to "ö"
(which leads to an error in the team list (of the generated project site))

error takes place when executing the "mvn release:prepare" goal

Show
Roman Cerny added a comment - - edited just tested with <version>2.0-beta-6</version> the plugin still removes all three entries (xml, svn keywords and doctype) the plugin also changed a <developer><name> containing an umlaut from "&ouml;" to "ö" (which leads to an error in the team list (of the generated project site)) error takes place when executing the "mvn release:prepare" goal
Hide
Permalink
Carsten Ziegeler added a comment -

I can confirm that this is still a bug - under specific circumstances the plugin removes everything before the first xml element (the intro and outro parts).

After some testing, I found some problems: the main problem is that the pom is parsed into a dom and then compared with a string version to detect the intro and outro parts. If the underlying dom implementation or the serialization from the dom to a string is altering only one single character the comparison will fail, and intro and outro is removed!

One problem I noticed are the namespace and schema definitions:

If I have the following in my pom:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

everything before <project> is removed, if I use

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

(everything in one line and specific order) it works!

Imho, the current approach should be replaced with an approach which just replaces the changing elements in the pom, like a sax based approach which detects the locations and just changes them on the fly. A very simple approach would be to use an xslt stylesheet for this: it can match on the elements to change and just copy everything else. If you need help in such a solution, let me know.

Show
Carsten Ziegeler added a comment - I can confirm that this is still a bug - under specific circumstances the plugin removes everything before the first xml element (the intro and outro parts). After some testing, I found some problems: the main problem is that the pom is parsed into a dom and then compared with a string version to detect the intro and outro parts. If the underlying dom implementation or the serialization from the dom to a string is altering only one single character the comparison will fail, and intro and outro is removed! One problem I noticed are the namespace and schema definitions: If I have the following in my pom: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> everything before <project> is removed, if I use <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> (everything in one line and specific order) it works! Imho, the current approach should be replaced with an approach which just replaces the changing elements in the pom, like a sax based approach which detects the locations and just changes them on the fly. A very simple approach would be to use an xslt stylesheet for this: it can match on the elements to change and just copy everything else. If you need help in such a solution, let me know.
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r659603.

A very simple approach would be to use an xslt stylesheet for this: it can match on the elements to change and just copy everything else.

This seems like a major rewrite of the plugin. If you would go for it, we would be happy to review it

Show
Benjamin Bentmann added a comment - Fixed in r659603.
A very simple approach would be to use an xslt stylesheet for this: it can match on the elements to change and just copy everything else.
This seems like a major rewrite of the plugin. If you would go for it, we would be happy to review it
Hide
Permalink
Marcello Teodori added a comment -

I also see that empty properties get transformed from <property.name></property.name> to <property.name />, the version replace mechanism should definitely be more respectful of the original format of the XML.

Show
Marcello Teodori added a comment - I also see that empty properties get transformed from <property.name></property.name> to <property.name />, the version replace mechanism should definitely be more respectful of the original format of the XML.

People

Vote (11)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.