Group Dependencies By Scope about sortpom

[GoogleCodeExporter]

I agree that sorting by scope would be helpful. I prefer to have all my test 
dependencies towards the bottom.

One idea would be to have text inside the elements of the sort order file and 
let the sorting be affected by that.
Example of a very simplified custom sort order file: 
...
    <dependencies>
        <dependency>
            <groupId/>
            <artifactId/>
            <scope/>
        </dependency>
        <dependency>
            <artifactId/>
            <groupId/>
            <scope>test</scope>
        </dependency>
    </dependencies>
...

This sort order file would tell the plugin to sort the test scoped dependencies 
after other dependencies (and also sort artifactId and groupId differently).

The other alternative would be to add a parameter som sort by scope first. This 
is perhaps easier, but more limited.

Do you have another solution?

There is one big problem: If you use dependency management in a parent pom 
(quite common in large projects) then the scope
is not visible at all in the child pom. My plugin cannot parse the maven 
infrastructure at all.

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

[GoogleCodeExporter]

One other option might be to utilize comments into the sort order file using 
recognized keywords. This would allow you to do fairly complicated things if 
you wanted to. For example
<!-- SORTPOM-DEPENDENCY-SORT-ORDER: scope, artifactId, groupId -->
<!-- SORTPOM-DEPENDENCY-SORT-ORDER-SCOPE: compile, runtime, provided, test -->
<!-- SORTPOM-DEPENDENCY-SORT-ORDER-ARTIFACTID: alphabetical -->
<!-- SORTPOM-DEPENDENCY-SORT-ORDER-GROUPID: alphabetical -->

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

[GoogleCodeExporter]

Another option would be to add those as parameters in the plugin configuration.

<dependencySortOrder>scope, artifactId, groupId</dependencySortOrder>
<scopeSortOrder>compile, runtime, provided, test</scopeSortOrder>

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

[GoogleCodeExporter]

That is a good suggestion to place stuff in comments (or in xml processing 
instructions)!
 I really would like to have something more generic though. Lots of keywords with lots of options equals Lots of coding and lots of maintenance.

This could perhaps solve another problem though. How to move plugin settings 
together with the sort order file.
Let the user add the plugin parameters to the sort order file as xml processing 
instructions.
<?sort.sortDependencies true?>
<?sort.createBackupFile false?>
The values could then be overridden by specifying then for the plugin. But that 
is another question entirely.

What is you thought on the dependency management problem?

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I guess that lists of arguments to a parameter can be supplied on command line 
if the spaces where removed.
-Dsort.dependencySortOrder=scope,artifactId,groupId

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

[GoogleCodeExporter]

I don't have any good ideas for the dependency management problem. If you had 
any dependencies that didn't have a visible scope, placing them at the 
beginning (or end) is not likely to make the consumer happy, so you might just 
want to gracefully degrade to the next sort order option and ignore the scope 
altogether.

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

[GoogleCodeExporter]

I think at the same time if I wasn't using dependency management that 
forgetting to put scope on one dependency and having it ignore scope in it's 
sorting would be annoying and also be harder to find the culprit. If it put 
that dependency at the top or bottom it would be easy to find and correct.

I think grouping dependencies without scope is probably the best way to go, 
then at least all your managed dependencies are grouped together.

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

[GoogleCodeExporter]

What I fear is that scope sorting might not solve the problem. 
Either the project is small and then manual rearranging isn't that hard; or the 
project is large and then the scopes (and versions) are defined in dependency 
management in a super pom.

In my current work-time project, we do have scope defined in multiple poms, but 
that is only because nobody has had the time to setup the dependency management 
correctly.

What do you two think?

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

[GoogleCodeExporter]

Since the default scope is compile you might want to treat all dependencies 
without scopes to be compile. If anybody was inheriting scopes from the parent, 
they would just have to not sort by scope.

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

[GoogleCodeExporter]

Regarding scope sorting not solving the problem, at work we tend to avoid 
parent POMs and as such we have many large projects where this would be 
helpful. That may be just me, though.

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

[GoogleCodeExporter]

We do use parent POM files in some situations, however when we use a parent we 
normally use that for version management and still define the scope on the 
child for sorting purposes.  I agree that if you were inheriting from parent 
you probably wouldn't sort by scope and would just sort your parent.

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

[GoogleCodeExporter]

I have started an implementation based on text in elements in the sort order 
file. I think it can work really good.

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

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Good news, everyone!
I have finished the implementation. The plugin can be controlled to place 
elements in a certain order depending on text content in sort order file. This 
can be used to group dependencies by scope or to make sure that a certain 
dependency is always placed first (or last).
Please try this implementation to see if it works for you

Download the source from subversion and compile with
mvn clean install -Ddev
and run the plugin with 
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.predefinedSortOrder="custom_2"

The sort order file custom_2.xml is modified to group test scoped dependencies 
last. I also added a tweak to make sure that a junit dependency is always first 
among test dependencies. Feel free to modify the file and experiment yourself.

The advantage of this solution is that the sort order functionality can be used 
for many purposes so it is quite flexible.

The disadvantage is that the sort order file will become quite large and I 
wonder if an average user will really use this functionality.

Try it out and send me some feedback!

Original comment by [email protected] on 13 Sep 2012 at 12:33

• Changed state: Started

[GoogleCodeExporter]

I could not resist. I implemented a parameter 
-Dsort.sortDependenciesByScope=true that sorts dependencies by scope (COMPILE 
(or empty), PROVIDED, SYSTEM, RUNTIME, IMPORT, TEST). Now you have the chance 
to experiment with both solutions.

Download the source from subversion and compile with
mvn clean install -Ddev

Either run
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.predefinedSortOrder="custom_2"
or
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependenciesByScope=true

Perhaps I could keep both solutions. The parameter would probably cover basic 
usage and the rest can be handled with specialized sort order files.

Original comment by [email protected] on 13 Sep 2012 at 1:41

[GoogleCodeExporter]

I have tested the sort file implementation and it works great. Thanks for your 
work. My team still would like to see the ability to sort based on scope, 
artifactId, groupId with the reasoning that you are more likely to know the 
artifact name than the entire group id if you are scrolling looking for 
something.

Would this be something you would be open to implementing in the config file or 
properties somehow? Should I log a separate issue requesting this change?

Original comment by [email protected] on 13 Sep 2012 at 3:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Works great here too. I'd also like to second an option for preferring artifact 
ID over group ID.

Original comment by [email protected] on 13 Sep 2012 at 3:42

[GoogleCodeExporter]

Good to hear that it works for you. I'm beginning to suspect that you two work 
at the same company :-)

I can try to change the sortDependencies parameter to accept a list element 
names to sort by (one of your earlier suggestions). 
The old parameter argument -Dsort.sortDependencies=true would then be expressed 
as -Dsort.sortDependencies=groupId,artifactId.
Your need for sorting dependencies would be 
-Dsort.sortDependencies=scope,artifactId,groupId.

Same logic would apply for sortPlugins

One problem with that solution is that old configurations for the plugin would 
not work anymore.

Another way would be to add comments or xml instructions in the sort order 
file, but that would leave the user to configure the plugin in three places: 
the parameters, the comments and the content of the sort order file.

Original comment by [email protected] on 13 Sep 2012 at 4:43

[GoogleCodeExporter]

A way to be passive while still supporting the new options would be to default 
to the old behavior if true or false was specified and honor the new sort 
options otherwise.

Original comment by [email protected] on 13 Sep 2012 at 5:42

[GoogleCodeExporter]

I would tend to lean that direction as well. I would look for true/false first 
and then read the order, if the items in the order are improperly formatted or 
can't be parsed for some reason I would fail back to false.

As far as if we're at the same company, I'm not sure, could be. I know we 
aren't on the same team at least.

Original comment by [email protected] on 13 Sep 2012 at 6:42

[GoogleCodeExporter]

Good suggestions! I'll allow true or false with old behavior and a deprecated 
warning. The list may contain anything otherwise, since it can reference any 
element names (case insensitive). List separators would be ,;:
Well, my next slot for open source programming is during the weekend. I'll let 
you know when I have something new for you.

Original comment by [email protected] on 13 Sep 2012 at 8:28

[GoogleCodeExporter]

Another implementation. sortDependenciesByScope is gone, and instead 
sortDependencies and sortPlugins have changed behavior. Please try the latest 
version.

Download the source from subversion and compile with
mvn clean install -Ddev

You can try the new options like this:
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=groupId,artifactId
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=scope,artifactId,groupId
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=scope,groupId,artifactId
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=version
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=false
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=true
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortPlugins=groupId,artifactId
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortPlugins=version

Will it solve your problem?

Original comment by [email protected] on 15 Sep 2012 at 4:32

[GoogleCodeExporter]

I like this solution a lot.

All options seem to work well (including the deprecated ones). The only thing I 
noticed that I would change is on plugins that don't have a group ID filled 
out, use the default group ID of "org.apache.maven.plugins" instead of sorting 
the blank ones to the top.

Original comment by [email protected] on 17 Sep 2012 at 2:46

[GoogleCodeExporter]

Strange! Empty or non-existing elements should be sorted as empty string. Can 
you send me an example.

Original comment by [email protected] on 18 Sep 2012 at 6:00

[GoogleCodeExporter]

Btw I think I will revert my 'text in sort order file'-solution that I 
suggested first. Tell me if the new behavior with sortDependencies and 
sortPlugins is enough to solve your problems.

Original comment by [email protected] on 18 Sep 2012 at 6:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yeah, I wasn't very clear. I am seeing them sorted as empty strings. I'm 
suggesting they be sorted as if the default group ID was present, even when it 
is not there.

The attached files were generated using:
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortPlugins=groupId,artifactId

Original comment by [email protected] on 18 Sep 2012 at 6:47

Attachments:

• pom-input.xml
• pom-expected.xml
• pom-actual.xml

[GoogleCodeExporter]

Regarding reverting the 'text in sort order file' solution, that's perfectly 
fine with me. The new sortDependencies and sortPlugins behavior is what I would 
use anyway.

Original comment by [email protected] on 18 Sep 2012 at 6:48

[GoogleCodeExporter]

Hmmm, well, I suppose that default groupId will only be valid for plugins. 
Empty groupId for dependencies will be treated as blank (and it doesn't build 
anyway).

During a build, a plugin without groupId is treated as it having grouId 
'org.apache.maven.plugins' even with pluginManagement, so it makes sense to 
default to that value. Especially of you compare pom files from different 
projects.

I'll think that it can be implemented quite easily.

Original comment by [email protected] on 18 Sep 2012 at 7:31

[GoogleCodeExporter]

Fixed default groupId for plugins and added your pom file as unit tests. 
Removed 'text in sort order file' solution.

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

[GoogleCodeExporter]

Now it is time to test the plugin before release. Verify that the solution 
solves your problem and please try to break it!

Download the latests source from subversion and compile with
mvn clean install -Ddev

You can try the new options like this:
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=scope,artifactId,groupId
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=false
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortDependencies=true
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortPlugins=groupId,artifactId
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortPlugins=true
mvn com.google.code.sortpom:maven-sortpom-plugin:2.1.0-SNAPSHOT:sort 
-Dsort.sortPlugins=false
combine it with different sort order files, run it on complex projects etc.

Original comment by [email protected] on 20 Sep 2012 at 9:36

• Changed state: Fixed

[GoogleCodeExporter]

I threw everything I could think of at it and didn't see any problems. Very 
nice work!

Original comment by [email protected] on 21 Sep 2012 at 1:29

[GoogleCodeExporter]

Version 2.1.0 is just released with the new functionality. Enjoy it!
<optional>
If you like plugin and use it professionally, please consider a donation. I 
could really use use a licence for 'GoodSync Desktop for Mac' ;-)
</optional>

Btw, set the status of this issue to verified, when you have tried version 
2.1.0.

Original comment by [email protected] on 23 Sep 2012 at 6:04

[GoogleCodeExporter]

Just updated the documentation as well.

Original comment by [email protected] on 23 Sep 2012 at 7:58

[GoogleCodeExporter]

Verified with the 2.1.0 release.

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

[GoogleCodeExporter]

Thanks for the testing help!

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

• Changed state: Verified