GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-1200

maven: after a successful build, doing a mvn install fails with "The type package-info is already defined"

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.5.1Release
    • Fix Version/s: 2.5.2.Release
    • Component/s: Maven integration
    • Labels:
      None
    • Number of attachments :
      0

      Description

      when building a project that contains package-info.java files doing following command will fail compilation:

      mvn install //this will succeed
      mvn install //this will fail

      the workaround is always to do a mvn clean install

      the error you receive relates to the compiler thinking an existing package-info.java already exists.

      222. ERROR in C:\projects\kuali\KULRICE-5640\core\api\src\main\java\org\kuali\ri
      ce\core\api\util\package-info.java (at line 1)
      /*
      ^
      The type package-info is already defined

        Activity

        Hide
        Andrew Eisenberg added a comment -

        Presumably, you have a package-info.java file in the same package in both your src/main/java and src/main/groovy source folders. I tried this on a groovy project and I do see the same error on the command line. It is not there when I stop using the groovy-eclipse-compiler.

        However, importing this project into Eclipse, I get "The type package-info is already defined" for all these instances, even when on the command line, this error is not shown.

        I'll explore a bit more...

        Show
        Andrew Eisenberg added a comment - Presumably, you have a package-info.java file in the same package in both your src/main/java and src/main/groovy source folders. I tried this on a groovy project and I do see the same error on the command line. It is not there when I stop using the groovy-eclipse-compiler. However, importing this project into Eclipse, I get "The type package-info is already defined" for all these instances, even when on the command line, this error is not shown. I'll explore a bit more...
        Hide
        Travis added a comment - - edited

        Thanks, Andrew

        You can see this error by checking out:

        https://test.kuali.org/svn/rice/sandbox/KULRICE-5640

        Also, we only have one package-info.java file in our java source tree.

        Show
        Travis added a comment - - edited Thanks, Andrew You can see this error by checking out: https://test.kuali.org/svn/rice/sandbox/KULRICE-5640 Also, we only have one package-info.java file in our java source tree.
        Hide
        Andrew Eisenberg added a comment -

        Now, using the plexus-compiler-eclipse compiler plugin for eclipse, I am still getting the same error as when I use groovy-eclipse.

        Note that the problem does not exist when the package-info exists only in src/main/java and src/test/java. Since they are compiled at different phases and have different output directories (but, there is still an error inside of eclipse since everything is compiled at once).

        Show
        Andrew Eisenberg added a comment - Now, using the plexus-compiler-eclipse compiler plugin for eclipse, I am still getting the same error as when I use groovy-eclipse. Note that the problem does not exist when the package-info exists only in src/main/java and src/test/java. Since they are compiled at different phases and have different output directories (but, there is still an error inside of eclipse since everything is compiled at once).
        Hide
        Travis added a comment -

        I also ran into this bug in our CI environment

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=214948

        no clue why it didn't show up locally. Maybe related?

        Show
        Travis added a comment - I also ran into this bug in our CI environment https://bugs.eclipse.org/bugs/show_bug.cgi?id=214948 no clue why it didn't show up locally. Maybe related?
        Hide
        Andrew Eisenberg added a comment -

        What??? I must be smoking something. Now, I can't even get a vanilla project with multiple (non-test) source folders to compile if package-infos overlap. I don't know why this was working for me before.

        But, it does make some sense. In this situation, which package-info.java file should make it into the output folder? There is fundamentally a conflict here. The package-info from one source folder should apply to the other source folder.

        I think that you get away with this for gmaven since the gmaven compiler compiles groovy source separately from java source. But, that begs the question, which package-info.java would you expect to see in the output folder?

        I am going to try some more to see if I can get this working again for a vanilla multi-source folder project. And if not, I am starting to think that this "feature" of gmaven is not really a feature...

        Show
        Andrew Eisenberg added a comment - What??? I must be smoking something. Now, I can't even get a vanilla project with multiple (non-test) source folders to compile if package-infos overlap. I don't know why this was working for me before. But, it does make some sense. In this situation, which package-info.java file should make it into the output folder? There is fundamentally a conflict here. The package-info from one source folder should apply to the other source folder. I think that you get away with this for gmaven since the gmaven compiler compiles groovy source separately from java source. But, that begs the question, which package-info.java would you expect to see in the output folder? I am going to try some more to see if I can get this working again for a vanilla multi-source folder project. And if not, I am starting to think that this "feature" of gmaven is not really a feature...
        Hide
        Andrew Eisenberg added a comment -

        Well, let me try your project. I've been hacking away at this without looking for your comments between mine.

        Show
        Andrew Eisenberg added a comment - Well, let me try your project. I've been hacking away at this without looking for your comments between mine.
        Hide
        Andrew Eisenberg added a comment -

        hmmm...with your project. I did:

        1. mvn clean compile
        2. mvn install
        3. mvn install

        All commands were successful. What version of maven are you using? I am on 3.0.3.

        Show
        Andrew Eisenberg added a comment - hmmm...with your project. I did: mvn clean compile mvn install mvn install All commands were successful. What version of maven are you using? I am on 3.0.3.
        Hide
        Travis added a comment -

        odd. I'm on Windows 7 running maven 3.0.3.

        If you recall we tested out this compiler on the rice project a few months back. Then on was on Windows xp. I don't suppose that makes a difference....

        Show
        Travis added a comment - odd. I'm on Windows 7 running maven 3.0.3. If you recall we tested out this compiler on the rice project a few months back. Then on was on Windows xp. I don't suppose that makes a difference....
        Hide
        Andrew Eisenberg added a comment -

        And I guess you wouldn't see this on the build server since you would never run mvn install twice.

        So, when on Windows xp, you had generally the same setup for package-info.java files? There was a change that we recently made so that annotation statements on package declarations are read and stored by the compiler. This was a change to get a piece of gpp working. I wonder if this could be a cause.

        What version of g-e-c are you using?

        Show
        Andrew Eisenberg added a comment - And I guess you wouldn't see this on the build server since you would never run mvn install twice. So, when on Windows xp, you had generally the same setup for package-info.java files? There was a change that we recently made so that annotation statements on package declarations are read and stored by the compiler. This was a change to get a piece of gpp working. I wonder if this could be a cause. What version of g-e-c are you using?
        Hide
        Travis added a comment -

        Oh that could be it! Last I tried this I was probably on an older version of g-e-c. I'll try a different version and let you know what I find.

        Show
        Travis added a comment - Oh that could be it! Last I tried this I was probably on an older version of g-e-c. I'll try a different version and let you know what I find.
        Hide
        Travis added a comment -

        That did it! g-e-c 2.5.1 is broken for me. g-e-c 2.5.1-1 works just fine. So something between those versions is causing the problem.

        Show
        Travis added a comment - That did it! g-e-c 2.5.1 is broken for me. g-e-c 2.5.1-1 works just fine. So something between those versions is causing the problem.
        Hide
        Andrew Eisenberg added a comment -

        Thanks for following up. I am resolving this as fixed, but please re-open if this happens again.

        Show
        Andrew Eisenberg added a comment - Thanks for following up. I am resolving this as fixed, but please re-open if this happens again.
        Hide
        Travis added a comment -

        So does that mean it is fixed in trunk? I thought 2.5.1-1 was an older version that 2.5.1....

        Show
        Travis added a comment - So does that mean it is fixed in trunk? I thought 2.5.1-1 was an older version that 2.5.1....
        Hide
        Andrew Eisenberg added a comment -

        No, 2.5.1-1 is the next release after 2.5.1. Is that not considered a greater version in the maven world? I had assumed that the same rules would apply from the OSGi world, where 2.5.1 is less than 2.5.1.1.

        I am trying to find the maven documentation for version comparisons, but there is nothing that clearly states the rules. The closest I found is this, but even that is unclear about comparing these kinds of versions.
        http://mojo.codehaus.org/versions-maven-plugin/version-rules.html

        Well regardless when 2.5.2 comes out I will mark it as 2.5.2-01 just in case I need to put out other releases of the maven support between micro releases of Groovy-Eclipse.

        Show
        Andrew Eisenberg added a comment - No, 2.5.1-1 is the next release after 2.5.1. Is that not considered a greater version in the maven world? I had assumed that the same rules would apply from the OSGi world, where 2.5.1 is less than 2.5.1.1. I am trying to find the maven documentation for version comparisons, but there is nothing that clearly states the rules. The closest I found is this, but even that is unclear about comparing these kinds of versions. http://mojo.codehaus.org/versions-maven-plugin/version-rules.html Well regardless when 2.5.2 comes out I will mark it as 2.5.2-01 just in case I need to put out other releases of the maven support between micro releases of Groovy-Eclipse.
        Hide
        Travis added a comment -

        Yup you are right. See here for details: http://docs.codehaus.org/display/MAVEN/Versioning

        Show
        Travis added a comment - Yup you are right. See here for details: http://docs.codehaus.org/display/MAVEN/Versioning
        Hide
        Andrew Eisenberg added a comment -

        Still, I think it is better to be more explicit with version names and the next release will be 2.5.2-01.

        Show
        Andrew Eisenberg added a comment - Still, I think it is better to be more explicit with version names and the next release will be 2.5.2-01.

          People

          • Assignee:
            Andrew Eisenberg
            Reporter:
            Travis
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: