GMaven (OLD... DO NOT USE)
  1. GMaven (OLD... DO NOT USE)
  2. MGROOVY-184

org.codehaus.groovy.maven.plugin.CompileState implementation causes errors in <module/> builds

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0-rc-4
    • Fix Version/s: 1.0-rc-5
    • Component/s: compile, stub generation
    • Labels:
      None
    • Environment:
      -
    • Number of attachments :
      0

      Description

      The same instance of CompileState is being passed to every GMaven mojo. During the build, the CompileState singleton is being loaded with files to compile when stubs are generated, then cleared when the Compile occurs.

      The problem with this is that GenerateStubs can happen irrespective of Compile.

      My issue occurs because I am using the maven-source-plugin, which causes GenerateStubs to be run out of turn, after Compile. The next project to be compiled in the <module/> build gets the resulting "forced-compile" files from the previous build. And because some dependencies aren't there in the next build in the chain, the compilation fails.

      In my case, GMaven is trying to compile a custom Maven Mojo class into another project, and that project does not reference the Maven dependencies.

      I am not sure the best way to fix this. If the CompileState class used the current MavenProject as a key, that would work (since a single project will have the same forced-compile files throughout the build). I suppose the MavenProject could be passed in as an argument. I'm not totally up on Plexus, so there might be a way to discover the current project info during the build...

      The issue seems to me, from hacking into the source, that there is an assumption that GenerateStubs will always be followed by Compile, in order, for each project. While this is usually the case, it appears that it is not necessarily always the case.

      This is a subtle yet important bug, as it can result in classes being compiled into the wrong projects without warning (if all the dependencies happen to line up).

        Activity

        Hide
        Jason Smith added a comment -

        I have a treatment for this issue. I'd like permission before I check it in. Need a response.

        Show
        Jason Smith added a comment - I have a treatment for this issue. I'd like permission before I check it in. Need a response.
        Hide
        Jason Dillon added a comment -

        Go for it

        Show
        Jason Dillon added a comment - Go for it
        Hide
        Jason Smith added a comment -

        Treated, checked in SVN revision 15354. Modification to CompileState API. Required minor fixup for TestCompileMojo, GenerateStubsMojo, GenerateTestStubsMojo, and CompileMojo.

        Changed CompileState so that it accepts the Project as a key (using data from the MavenProject instance to generate a unique key for each project in the build).

        This change deals with the assumption that a GenerateStubs is always followed by a Compile that can clear it. In at least one case, GenerateStubs was being called in a forked lifecycle without a Compile. This resulted in "forceCompile" files being kept around for the next project. This fix ensures that there can be no bleed-over of information from one project to the next.

        Show
        Jason Smith added a comment - Treated, checked in SVN revision 15354. Modification to CompileState API. Required minor fixup for TestCompileMojo, GenerateStubsMojo, GenerateTestStubsMojo, and CompileMojo. Changed CompileState so that it accepts the Project as a key (using data from the MavenProject instance to generate a unique key for each project in the build). This change deals with the assumption that a GenerateStubs is always followed by a Compile that can clear it. In at least one case, GenerateStubs was being called in a forked lifecycle without a Compile. This resulted in "forceCompile" files being kept around for the next project. This fix ensures that there can be no bleed-over of information from one project to the next.

          People

          • Assignee:
            Jason Dillon
            Reporter:
            Jason Smith
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: