Maven 2.x Eclipse Plugin

update to correctly sort upper/lowercase dependencies

I'd like to throw my support behind this idea and request that a transitive nearness ordering be added as well.

Crap. I wrote a few Kb and accidently closed the window. I hate web-guis.

Short story:

continuum-release depends on:

• maven-project 2.0.4
• maven-release-plugin, which depends on maven-project 2.0

In eclipse, maven-release-plugin is listed before maven-project-2.0.4.jar.

Due to an API change (ProjectSorter added another exception in 2.0.4), I get an error in eclipse,
because the code catches the exception defined in 2.0.4 but eclipse sees the implementation
from 2.0 which doesn't throw that.

So I suggest we ONLY support ordering for transitive dependencies. However, there are a few options:

• sort projects by transitive dependencies, so that the correct version is resolved. This is impossible, because two projects could be considered to be listed before eachoter:

MAIN depends on A and B.
A depends on C 1.0 and D 1.1
B depends on C 1.1 and D 1.0.
MAIN depends on C 1.0 and D 1.0.

No way to order this properly, A needs to come before B because of C, and B needs to come before A because of D.

• Simplest solution: do NOT export any dependencies, and list all transitive dependencies explicitly. This is done already for
  non-workspace dependencies, but should also be done for workspace project references.

I had some hybrid solutions but the above cover the extremes.

Kenney, none of your examples show why having an alphabetic ordering should not be at least an option. I don't see why people with correctly managed dependencies have to suffer from other people's mistakes, like your example where an ABI break in maven requires messing with the build system. Using the build system to fix this is the wrong solution to the right problem (yes I understand that sometimes it's necessary in "the real world", wherever that is); your second example even shows why the assumption that transitive dependencies are always correct becomes more and more likely to break down as the number of dependencies increases. Add some m1-converted POMs with changed groupIds and the whole concept simply stops working "in the real world". Also as long as the dependency list in eclipse is flattened, the fact that it is transitively ordered becomes less than helpful because you cannot see where a dependency level starts and stops.
My workspace contains >30 projects with sometimes >80 dependencies each and trying to resolve duplicates or conflicts (keywords: XML, JMX, other API/implementation conflicts, different profiles for JDK 1.4/1.5) caused by broken POMs was simply not reasonably possible without ordering by name to quickly see offending jars.

Hm, actually, when I just disable the 'exported' flag on dependencies, the problem above goes away.

I tested reordering the dependencies but this doesn't work in eclipse 3.2. Even though the correct dep
is listed first, it still resolves to the second one. Weird.

You're right. I created a separate issue (MECLIPSE-170) to address the erroneous classpath issue.

As for the sorting on names, that's a really good idea since I'm always searching huge lists of dependencies to see if a jar is in there.

scheduling for 2.3: at this moment only osgi dependencies in manifest are sorted

As for the convenience of finding particular dependencies in eclipse build path more quickly, I'd suggest the following
SORT OPTIONS:

• by artifactId
• by groupId

However, I consider it more important to have the option to control CLASSPATH ORDER by sorting classpath entries
according to the order of dependencies as written in the POM. At least for runtime dependencies.
This would make it unnecessary to manually adjust classpath order in eclipse and reduce time for supporting
developers who are unexperienced or new to the project...

Does this change not need to be made in maven core (MNG-1412) rather than just this plugin? Otherwise it could lead to different results between building a project in the cmdline and within eclipse.

Note that in MECLIPSE-294, it is noted that this particular randomness causes problems in the unit tests.

Patch applied.
Dependencies are now sorted by artifactId instead to have a random sort.
It's only a wordaround, which could disappear in the feature if maven's core has a policy for dependencies order.

Please re-open this issue. A sort by artifactId is not sufficient. Part of the reason for desiring sorting is so that the generated classpaths in the plugins own tests are consistent - some of these contain entries which differ only in classifier, so the classifier it is necessary that the classifier be included in the sort criteria.

For a full solution, the sort key should probably include groupId+artifactId+type+classifier - i.e. the criteria applied by Maven in DefaultArtifact.getDependencyConflictId().

Max, your "full solution" would do something completely different than what I originally intended, which is pretty much your solution without the groupId. There cannot be a single "unified" solution! eclipse has no notion of "groups" and trying to somehow model maven concepts on top of the .classpath will just lead to a great deal of confusion. artifact "ordering" is a very arbitrary and project-dependent concept, which is why I said from the very beginning that multiple comparators need to be selectable. I merely provided the first (one possible) implementation.

Ah, I admit I had not actually read this issue, I was going to comment on MECLIPSE-294, but then noticed that it had been closed as duplicate of this issue, so I followed the "duplicates" link and put my comment here instead.

Right. Having read this issue, I can see that whilst the committed fix solves the concerns of this issue, it does not fix the MECLIPSE-294 - so I'm going to unduplicate the two issues.