Details

    • Type: Wish Wish
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      avoid the need for forkmode=once by switching to the superior surefire plugin for general testing.

      Enhance the surefire mojo to provide the same output as junit so that the test plugin remains backwards compatible.

        Activity

        Hide
        Trygve Laugstøl added a comment -

        I'm not sure what the best way is, there are at least two solutions to this:

        1) The easy way Add setters to the Mojo and use it as a normal bean in jelly. Then you will have to map the Maven 2 expressions to the Maven 1 $

        {project}

        object etc. This is possible as the MavenProject and ArtifactRepository actually doesn't seem to be used in the plugin at all. I'll look into removing those in the morning.

        2) The more correct way: Create a infrastructure for embedding Maven 2 and get Maven to instanciate and execute the Mojo. This will require a way to map a Maven 1 project to a Maven 2 project and a lot of other stuff.

        This is probably way more work than you're ready for and solution 1) will suffice for now.

        Show
        Trygve Laugstøl added a comment - I'm not sure what the best way is, there are at least two solutions to this: 1) The easy way Add setters to the Mojo and use it as a normal bean in jelly. Then you will have to map the Maven 2 expressions to the Maven 1 $ {project} object etc. This is possible as the MavenProject and ArtifactRepository actually doesn't seem to be used in the plugin at all. I'll look into removing those in the morning. 2) The more correct way: Create a infrastructure for embedding Maven 2 and get Maven to instanciate and execute the Mojo. This will require a way to map a Maven 1 project to a Maven 2 project and a lot of other stuff. This is probably way more work than you're ready for and solution 1) will suffice for now.
        Hide
        Andy Glick added a comment -

        In Brett's comment of 9 August above, he stated the that among the preconditions for going forward with the backport of the surefire plugin to M1 was that the "...m2 surefire plugin gets up to feature level of m1 test plugin ".

        A naive survey of the situation might lead someone to believe that such an event might be a long way off, for 3 reasons:

        1) the surefire plugin does not generate an XML for JUnit tests

        2) a JUnit report contains in addition to the test case results, a whole list of properities and values from the underlying Ant environment, since M1 is executing the Ant JUnit task

        3) the current surefire plugin works, andf there are plenty of things that don't work , so why invest core team energy where it isn't required to meet upcoming deliveries?

        As an outsider with no coding assignments, and having volunteered to work on this, I've been looking at the surefire report package and at the Ant JUnit optional task package, and some sort of XML report of the test results shouldn't be too hard to come up with, but I have understood from the users list that there is no agreement on a candidate "properties set" that would be added to the XML report to provide a feature level match.

        I'm sure that I've left out other features towards the feature level. If someone would be willing to enumerate them, I'd be willing to take a crack at adding them.

        In Trygve's comment above of 23 August, he spoke about creating an infrastructure for embedding M2 into an M1 environment. Has anyone made any progress on that, and if so, where would I look to find the code?

        One more question if you will, is there any reason why I shouldn't go ahead and rework the m1 test plugin and the m1 itest plugin by modifying the existing jelly code and either 1) refactoring some behavior or 2) simply exposing all of the necessary configurable parameters of the test plugin?

        Show
        Andy Glick added a comment - In Brett's comment of 9 August above, he stated the that among the preconditions for going forward with the backport of the surefire plugin to M1 was that the "...m2 surefire plugin gets up to feature level of m1 test plugin ". A naive survey of the situation might lead someone to believe that such an event might be a long way off, for 3 reasons: 1) the surefire plugin does not generate an XML for JUnit tests 2) a JUnit report contains in addition to the test case results, a whole list of properities and values from the underlying Ant environment, since M1 is executing the Ant JUnit task 3) the current surefire plugin works, andf there are plenty of things that don't work , so why invest core team energy where it isn't required to meet upcoming deliveries? As an outsider with no coding assignments, and having volunteered to work on this, I've been looking at the surefire report package and at the Ant JUnit optional task package, and some sort of XML report of the test results shouldn't be too hard to come up with, but I have understood from the users list that there is no agreement on a candidate "properties set" that would be added to the XML report to provide a feature level match. I'm sure that I've left out other features towards the feature level. If someone would be willing to enumerate them, I'd be willing to take a crack at adding them. In Trygve's comment above of 23 August, he spoke about creating an infrastructure for embedding M2 into an M1 environment. Has anyone made any progress on that, and if so, where would I look to find the code? One more question if you will, is there any reason why I shouldn't go ahead and rework the m1 test plugin and the m1 itest plugin by modifying the existing jelly code and either 1) refactoring some behavior or 2) simply exposing all of the necessary configurable parameters of the test plugin?
        Hide
        Trygve Laugstøl added a comment -

        1) As you're saying this shouldn't be hard. Just add a new surefire reporter

        2) I don't think that this is a really important feature, the Maven 1 plugin doesn't use it for anything in particular. And I'm pretty sure it's just a dump of System.getProperties()

        3) Well, you asked for something to do

        One major feature I know that's missing is the ability to fork the tests, which I see as the biggest issue to fix.

        I haven't looked into making some infrastructure for embedding Maven 2 in Maven 1 yet but I don't think it's strictly needed for this plugin. I think that doing this plugin "by hand" might give a more clear overview over what's really needed.

        Show
        Trygve Laugstøl added a comment - 1) As you're saying this shouldn't be hard. Just add a new surefire reporter 2) I don't think that this is a really important feature, the Maven 1 plugin doesn't use it for anything in particular. And I'm pretty sure it's just a dump of System.getProperties() 3) Well, you asked for something to do One major feature I know that's missing is the ability to fork the tests, which I see as the biggest issue to fix. I haven't looked into making some infrastructure for embedding Maven 2 in Maven 1 yet but I don't think it's strictly needed for this plugin. I think that doing this plugin "by hand" might give a more clear overview over what's really needed.
        Hide
        Lukas Theussl added a comment -

        Don't see why this should be a blocker.

        Show
        Lukas Theussl added a comment - Don't see why this should be a blocker.
        Hide
        Michael Osipov added a comment -

        Old stuff, cleanup.

        Show
        Michael Osipov added a comment - Old stuff, cleanup.

          People

          • Assignee:
            Unassigned
            Reporter:
            Brett Porter

            Dates

            • Created:
              Updated:
              Resolved: