Add blank lines about sortpom

[GoogleCodeExporter]

Well, I have considered that the plugin could react to text inside the elements 
in the sort order files. That could place certain dependencies, names and 
scopes at the bottom or top when sorting.
Blank lines is a different beast though. 
1. It is somewhat hard to differentiate between blank lines and ordinary line 
endings (in different OS). 
2. The xml parser works by parsing element by element, it does not really have 
a notion of what happened earlier in the xml file.

That said; I can have a look at it and see if it is possible to do (within a 
finite amount of time).
Btw. If an repeatable element (such as the dependency element) have a blank 
line before in the sort order file, should all dependency elements in the pom 
file get blank lines before?

I would appreciate if you could attach some concrete examples of how the it 
would work. What would the sort order file look like and what would the 
resulting pom file look like.

Original comment by [email protected] on 12 Sep 2012 at 7:46

[GoogleCodeExporter]

For repeatable elements, I think I would expect them all to get blank lines 
before.

I'm attaching before and after versions of a POM that would be sorted using the 
default sort order. The "after" version is what it would look like with the 
blank lines inserted.

Original comment by [email protected] on 12 Sep 2012 at 8:11

Attachments:

• pom-before.xml
• pom-after.xml

[GoogleCodeExporter]

Regarding how it would work: Would really <dependencies> get blank line before? 
In the default_1_0_0.xml file, <dependencyManagement> has blank line before, 
not <dependencies>.

Regarding default sort orders: I would have to remove the blank lines from the 
default sort order files, otherwise the default behavior would change too much. 

Original comment by [email protected] on 12 Sep 2012 at 8:25

[GoogleCodeExporter]

I think the algorithm should work both when a blank space follows an element or 
when a blank space comes before an element. In the example above, since there 
is a blank space following the properties element in the default sort order, 
there should be a blank in the "after" file. The attached examples illustrate 
both cases - with a blank following the properties as well as a blank before 
the properties element even though it comes after the developers element (which 
doesn't have a blank following it in the default sort order file).

Regarding the default sort orders, I agree you'd probably want to remove the 
blank lines, except maybe for the "recommended_2008_06" profile since the 
conventions [1] recommend blank lines: "The blocks are voluntary separated by a 
new line to improve the readingness."

[1] http://maven.apache.org/developers/conventions/code.html

Original comment by [email protected] on 12 Sep 2012 at 8:44

[GoogleCodeExporter]

Attaching the new examples

Original comment by [email protected] on 12 Sep 2012 at 8:45

Attachments:

• pom-before.xml
• pom-after.xml

[GoogleCodeExporter]

Another algorithm is that; if elements are parsed in order, then blank lines 
are saved until next element is encountered. 
Example:
a pom file containing only <url> and <issueManagement> would get a blank line 
between them since the sort order file contained at least one blank line 
between the elements even though neither <url> nor <issueManagement> themselves 
had blank lines around them.

That is
<?xml version="1.0" encoding="UTF-8"?>
<project>
  <name>test-project</name>
  <url>http://maven.apache.org</url>
  <issueManagement>
    <system>Google Code</system>
    <url>http://code.google.com/p/sortpom/issues/list</url>
  </issueManagement>
</project>

would become


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

  <name>test-project</name>
  <url>http://maven.apache.org</url>

  <issueManagement>
    <system>Google Code</system>
    <url>http://code.google.com/p/sortpom/issues/list</url>
  </issueManagement>

</project>

Original comment by [email protected] on 12 Sep 2012 at 9:03

[GoogleCodeExporter]

Yeah, that sounds even better.

Original comment by [email protected] on 12 Sep 2012 at 9:07

[GoogleCodeExporter]

So, I think that I have understood the problem. I will check the code and see 
if it is possible to implement such logic. No promises though.

Original comment by [email protected] on 12 Sep 2012 at 9:19

[GoogleCodeExporter]

Original comment by [email protected] on 13 Sep 2012 at 9:55

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I will look into the blank lines after I have released version 2.1.0. This one 
is on hold until then.

Original comment by [email protected] on 20 Sep 2012 at 8:02

[GoogleCodeExporter]

How do you feel about git? I am about to change the version control from 
subversion to git. Git or this issue first?

Original comment by [email protected] on 23 Sep 2012 at 8:00

[GoogleCodeExporter]

It'd be OK with me if you wanted to do git first.

Original comment by [email protected] on 24 Sep 2012 at 7:38

[GoogleCodeExporter]

I do have some troubles with this issue. The sorting works like this:
All elements are fetched from the sort order file into a map and given an 
integer that indicates which 'weight' it has (relative to the other elements).
The sort order file is parsed into a structure and each element is matched 
against the map and given the weight number.
The structure is then resorted according the weight number.
Content that is not in the sort order file are either elements (which get heavy 
weight and sink towards the end) and text (which does not have weight and is 
not sorted).

I can detect empty lines in the sort order file and connect them with the sort 
order element in the map (and that will take some coding).
Elements in the pom file can also be given the blank line (since the map would 
have that information) (and that will take some coding).
Problems are: 
I cannot save blank lines for elements that are not found, since those elements 
will not exist in the pom file.
I have a problem to limit the blank lines to one line if an upper element wants 
one blank line below and a lower element wants one blank line above.
Finally the plugin will change behavior for all those who have custom sort 
order files.

So, if I put in a lot of effort into solving this issue, the results will still 
be quite bad. I'm sorry to say that I have to reject this issue. 
An alternative is that you implement this functionality yourself and I would 
happily adapt the plugin to your code.

Original comment by [email protected] on 27 Sep 2012 at 2:04

[GoogleCodeExporter]

Thanks for looking into it.

Original comment by [email protected] on 28 Sep 2012 at 9:29

[GoogleCodeExporter]

Original comment by [email protected] on 2 Oct 2012 at 7:26

• Changed state: WontFix

[ddcruver]

Is there plans to implement this feature?

[Ekryd]

Hi,
There are no plans to implement this feature. Existing bank lines can be preserved with the "keepBlankLines" option. I suggest to format the pom as you l prefer it and then always perform the sorting with the "keepBlankLines" option.
You are very welcome to submit a pull request to solve this issue.