Details

    • Number of attachments :
      5

      Description

      Currently plugin sorts artifacts on its own (alphabetic order???) because the order of dependencies that comes from maven is not reliable (random?). This breaks tests that use JBoss Embedded which works under maven surefire plugin because it still puts dependencies that came first at the beginning of the classpath). Apparently not all classpath elements are put in random order. At least I get the first ones listed in dependencies also first in the classpath (can be seen as $

      {surefire.test.class.path}

      and in target/surefire-reports/TEST-TestSuite.xml).

      While there is not much we can do for maven eclipse plugin a solution is on the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can revert back to the default classpath order.

      Can we somehow schedule this?

      Another question: is there anyway to put certain dependencies in the first place except for renaming them so that alphabetic order does the job?

      1. ideal.classpath
        1 kB
        Jean-Noel Rouvignac
      2. MECLIPSE-388.patch
        2 kB
        David J. M. Karlsen
      3. MECLIPSE-388.patch
        2 kB
        David J. M. Karlsen
      4. MECLIPSE-388-it-test.patch
        8 kB
        David J. M. Karlsen

        Issue Links

          Activity

          Hide
          Barrie Treloar added a comment -

          Jean-Noel, thanks for the feedback but its reads as a mixed message. I'm not sure if this is fixed or there is more work to be done.
          I suspect more work.

          When you say it better respects the dependency tree, are you saying that the output is not correct?

          Looking at the 2.9 output, I'm suspicious about why the JRE_CONTAINER is third on the classpath (i.e. splattered in amongst everything else).

          Also why is M2_REPO/javax/persistence/persistence-api/1.0/persistence-api-1.0.jar second?
          Its a transitive dependency of org.hibernate:hibernate-annotations:jar:3.2.1.ga:compile.
          The ordering doesn't look like the order I expect.

          Would you be able to re-arrange the 2.9.classpath into the order you expect?

          I've pulled out the dependency mojo which uses a shared component for building the tree.
          I vaguely recall something about that not being 100% correct but I think I'll look at switching the m-e-p implementation from a home-grown to shared components.
          At least that will mean it can get fixed once.

          Work is busy at the moment so progress may stall for a bit.

          Show
          Barrie Treloar added a comment - Jean-Noel, thanks for the feedback but its reads as a mixed message. I'm not sure if this is fixed or there is more work to be done. I suspect more work. When you say it better respects the dependency tree, are you saying that the output is not correct? Looking at the 2.9 output, I'm suspicious about why the JRE_CONTAINER is third on the classpath (i.e. splattered in amongst everything else). Also why is M2_REPO/javax/persistence/persistence-api/1.0/persistence-api-1.0.jar second? Its a transitive dependency of org.hibernate:hibernate-annotations:jar:3.2.1.ga:compile. The ordering doesn't look like the order I expect. Would you be able to re-arrange the 2.9.classpath into the order you expect? I've pulled out the dependency mojo which uses a shared component for building the tree. I vaguely recall something about that not being 100% correct but I think I'll look at switching the m-e-p implementation from a home-grown to shared components. At least that will mean it can get fixed once. Work is busy at the moment so progress may stall for a bit.
          Hide
          Jean-Noel Rouvignac added a comment - - edited

          Hi Barrie,

          Many thanks for your help on this issue.
          I had a think about what would make sense as a .classpath file to me on this example. I based myself on the dependency tree as it is the only way users can change how maven will order the jars.
          I reached the conclusion that a breadth-first search, ordered by the position in the dependencies is what I want. First of all you want to see your top level dependencies being included in the classpath in the order they are declared, then come the second level dependencies also following the order of the top level dependencies, etc.

          So if you have the folowing dependencies:

           myproject
             +- a
                +- a1
                +- a2
                +- a3
             +- b
                +- b1
                +- b2
                +- b3
             +- c
                +- c1
                +- c2
                +- c3
          

          Then I would expect to see the following classpath being generated:

          myproject classes;a;b;c;a1;a2;a3;b1;b2;b3;c1;c2;c3

          I attached the corresponding .classpath for the little test I previously attached.

          Thanks,
          Jean-NoŽl

          Show
          Jean-Noel Rouvignac added a comment - - edited Hi Barrie, Many thanks for your help on this issue. I had a think about what would make sense as a .classpath file to me on this example. I based myself on the dependency tree as it is the only way users can change how maven will order the jars. I reached the conclusion that a breadth-first search, ordered by the position in the dependencies is what I want. First of all you want to see your top level dependencies being included in the classpath in the order they are declared, then come the second level dependencies also following the order of the top level dependencies, etc. So if you have the folowing dependencies: myproject +- a +- a1 +- a2 +- a3 +- b +- b1 +- b2 +- b3 +- c +- c1 +- c2 +- c3 Then I would expect to see the following classpath being generated: myproject classes;a;b;c;a1;a2;a3;b1;b2;b3;c1;c2;c3 I attached the corresponding .classpath for the little test I previously attached. Thanks, Jean-NoŽl
          Hide
          Robert Scholte added a comment -

          Jean-NoŽl,

          this is not the order Maven will use to compile. So to stay as close as possible to Maven it should be:
          a;a1;a2;a3;b;b1;b2;b3;c;c1;c2;c3;

          Show
          Robert Scholte added a comment - Jean-NoŽl, this is not the order Maven will use to compile. So to stay as close as possible to Maven it should be: a;a1;a2;a3;b;b1;b2;b3;c;c1;c2;c3;
          Hide
          Jean-Noel Rouvignac added a comment -

          Hi Robert, this order looks good enough to me. As long as Maven and the maven-eclipse-plugin do not yield different results when compiling without good reason (like the fact the project and the tests of this project are two distinct projects in Maven but only one in Eclipse).

          Show
          Jean-Noel Rouvignac added a comment - Hi Robert, this order looks good enough to me. As long as Maven and the maven-eclipse-plugin do not yield different results when compiling without good reason (like the fact the project and the tests of this project are two distinct projects in Maven but only one in Eclipse).
          Hide
          Barrie Treloar added a comment -

          From feedback for this "iteration" of the solution is more palatable to users.

          The next step is to look at aether and how its doing the dependency graph so that this can be shared appropriately.

          Show
          Barrie Treloar added a comment - From feedback for this "iteration" of the solution is more palatable to users. The next step is to look at aether and how its doing the dependency graph so that this can be shared appropriately.

            People

            • Assignee:
              Barrie Treloar
              Reporter:
              Siarhei Dudzin
            • Votes:
              11 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: