Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tidy:pom concatentes original and tidied POM, producing invalid XML #19

Open
sewe opened this issue Nov 13, 2017 · 2 comments
Open

tidy:pom concatentes original and tidied POM, producing invalid XML #19

sewe opened this issue Nov 13, 2017 · 2 comments
Labels

Comments

@sewe
Copy link

sewe commented Nov 13, 2017

The following self-contained pom.xml is completely broken by tidy:pom (version 1.0.0):

<?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>example</artifactId>
    <version>1.0.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.apache.maven.indexer</groupId>
            <artifactId>indexer-core</artifactId>
            <version>5.1.1</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.1.0</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                            <relocations>
                                <relocation>
                                    <pattern>org.apache.lucene</pattern>
                                    <shadedPattern>org.apache.maven.indexer.lucene</shadedPattern>
                                </relocation>
                            </relocations>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

The resulting POM consists of two POMs concatenated together:

…
    </build>
</project>
  <?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
…

Also, the resulting POM contains this sequence of broken formatting:

<relocations>
    <relocation><pattern>org.apache.lucene</pattern>
        <shadedPattern>org.apache.maven.indexer.lucene</shadedPattern>
    </relocation>
</relocations>
@sewe
Copy link
Author

sewe commented Nov 20, 2017

Just checked the above test case with version 1.1.0 of the tidy-maven-plugin: tidy:check no longer complains about the pom.xm and tidy:check leaves it alone.

While this is nice, I wouldn’t close this issue yet; the effect of the bug is so strange (the pom.xml being concatenated with its tidied form) that it is probably worth debugging version 1.0.0 just to figure out how on earth this could happen at all – and whether it still can happen with other inputs.

@larslindq
Copy link
Contributor

larslindq commented Dec 13, 2017

This was an issue with plugins that uses configuration elements with the same name as the pom. See #8 and #14.

As to why the pom is concatenated, it's a couple of things that seems to cause it. The first of which is that the formatter finds the element (#14) and tries to format the 3 expected nodes (groupId, artifactId, version) inside. Nothing has been formatted at this point if my understanding is correct but the formatter continues (the "wrong" nodes are appended in the result - unchanged).

Next, the formatter should concatenate the rest of the pom after the last node inside . It does so by calculating the start/end positions of the 3 nodes (see calculateStartsAndEnds) to find the very last position.

These nodes are never found, thus start/end are left with their initialized values; Integer.MAX and -1 respectively. Apparently all the nodes inside ends at position -1, which the formatter defaults to 0. Instead of concatenating from the last node, the formatter concatenates from 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants