Groovy main/test folders not added as source folders

[reckart]

I have been using a maven-build-helper-based approach to add src/main/groovy and src/test/groovy to Eclipse-based builds since a long time. Now suddenly that does not work anymore.

I strongly suspect the fix for #186 to be the cause of this problem.

Here is the configuration that I use in the POM:

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.12</version>
        <executions>
          <execution>
            <id>add-source</id>
            <phase>process-sources</phase>
            <goals>
              <goal>add-source</goal>
            </goals>
            <configuration>
              <sources>
                <source>src/main/groovy</source>
              </sources>
            </configuration>
          </execution>
          <execution>
            <id>add-test-source</id>
            <phase>generate-test-sources</phase>
            <goals>
              <goal>add-test-source</goal>
            </goals>
            <configuration>
              <sources>
                <source>src/test/groovy</source>
              </sources>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

I can see that the paths are added in the m2e log:

8/2/16, 2:04:52 PM GMT+2: [INFO] Update started
8/2/16, 2:04:52 PM GMT+2: [INFO] Using org.eclipse.m2e.jdt.JarLifecycleMapping lifecycle mapping for MavenProject: PROJECT:SUBMODULE:0.0.1-SNAPSHOT @ /ABSOLUTE-PATH/SUBMODULE/pom.xml.
8/2/16, 2:04:53 PM GMT+2: [INFO] Source directory: /ABSOLUTE-PATH/SUBMODULE/src/main/groovy added.
8/2/16, 2:04:53 PM GMT+2: [INFO] Test Source directory: /ABSOLUTE-PATH/SUBMODULE/src/test/groovy added.
8/2/16, 2:04:53 PM GMT+2: [INFO] Adding source folder /SUBMODULE/src/main/java
8/2/16, 2:04:53 PM GMT+2: [INFO] Adding source folder /SUBMODULE/src/main/groovy
8/2/16, 2:04:53 PM GMT+2: [INFO] Adding resource folder /SUBMODULE/src/main/resources
8/2/16, 2:04:53 PM GMT+2: [INFO] Adding source folder /SUBMODULE/src/test/java
8/2/16, 2:04:53 PM GMT+2: [INFO] Adding source folder /SUBMODULE/src/test/groovy
8/2/16, 2:04:53 PM GMT+2: [INFO] Adding resource folder /SUBMODULE/src/test/resources
8/2/16, 2:04:53 PM GMT+2: [INFO] Update completed: 1 sec
8/2/16, 2:04:53 PM GMT+2: [INFO] Source directory: /ABSOLUTE-PATH/SUBMODULE/src/main/groovy added.
8/2/16, 2:04:53 PM GMT+2: [INFO] Using 'UTF-8' encoding to copy filtered resources.
8/2/16, 2:04:53 PM GMT+2: [INFO] Copying 0 resource
8/2/16, 2:04:53 PM GMT+2: [INFO] Using 'UTF-8' encoding to copy filtered resources.
8/2/16, 2:04:53 PM GMT+2: [INFO] Copying 5 resources
8/2/16, 2:04:53 PM GMT+2: [INFO] Test Source directory: /ABSOLUTE-PATH/SUBMODULE/src/test/groovy added.
8/2/16, 2:04:53 PM GMT+2: [INFO] Using 'UTF-8' encoding to copy filtered resources.
8/2/16, 2:04:53 PM GMT+2: [INFO] Copying 6 resources

Even if I add the folders manually as source folders, this is undone the next time I update the project or make a change to the POM. Adding any other folder this way, e.g. src/main/lala works without any problem.

Update: The problem seems to affect only nested Groovy project in a multi-module build. Looks like the logic that checks if groovy source folders exists may have problem with nested modules.

[reckart]

I should add that this basically prevents me from using any Groovy-based projects. Unfortunately, I cannot even revert the Eclipse configuration because it complains about all kinds of plugins no longer being available from repositories.

[reckart]

I have tried to build the project from the command line using Maven, but that also didn't work. Tycho failed to resolve dependencies with a message like No solution found because the problem is unsatisfiable.: ... and then a very long list of dependencies.

[reckart]

The problem seems to affect only nested Groovy project in a multi-module build. Looks like the logic that checks if groovy source folders exists may have problem with nested modules.

[reckart]

A hack that currently works for me is creating a symlink, e.g. ln -s groovy snoovy and then adding that as a source folder in Eclipse.

[kdvolder]

Please provide a test project and I might have a look / debug it.

[reckart]

@kdvolder I have produced a minimal project illustrating the problem. It looks like the problem may possible not be related to #186 after all - but that is not entirely sure yet. The problem seems to be triggered by the gmaven-plugin being configured in the pom. I have been using that plugin for quite some time. Something in the Eclipse environment must have changes that it is causing problems now, because the gmaven-plugin hasn't been updated for ages.

The Groovy/m2e plugin versions I am using are:

• Groovy-Eclipse M2E integration - 2.9.2.xx-201607251752-e45
• m2e - Maven Integration for Eclipse (includes Incubating components) - 1.7.0.20160603-1933

Here is a rather minimal POM illustrating the problem:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>groovy-eclipse-issue-191-b</groupId>
  <artifactId>groovy-eclipse-issue-191-b</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.3</version>
        <configuration>
          <compilerId>groovy-eclipse-compiler</compilerId>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-compiler</artifactId>
            <version>2.9.2-01</version>
          </dependency>
          <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-eclipse-batch</artifactId>
            <version>2.4.3-01</version>
          </dependency>
        </dependencies>
      </plugin>
      <!-- 
       - If this plugin is commented in, then the folders "src/main/groovy" and "src/test/groovy"
       - are not added as source paths - if it is commented out, they are added
      <plugin>
        <groupId>org.codehaus.gmaven</groupId>
        <artifactId>gmaven-plugin</artifactId>
        <version>1.5</version>
        <inherited>true</inherited>
      </plugin>
      -->
    </plugins>
  </build>
</project>

A full project is attached here: groovy-eclipse-issue-191-b.zip

[kdvolder]

greclipse used to not care about gmaven plugin at all. I.e it used to ignore it alltogether. But we recently started picking it up as an alternative to groovy-eclipse-compiler plugin (for maven builds) since we don't intend to support it any further.

Folks still wanting to compile groovy should be using gmaven plugin (or gmaven-plus) instead. And the m2e configurators for greclipse provides minimal support for it.

It could be that this change means greclipse-maven configurators are now doing something they did not do before and this is causing you problems.

I see your pom uses both gmaven-plugin and groovy-eclipse-compiler via maven-compiler-plugin. Do you really need both of these? (I.e. if you are using gmaven-plugin why do you still need groovy-eclipse-compiler as well?

[reckart]

I'm using the gmaven-plugin to execute a groovy script during the build, i.e. a custom build action. It is not at all meant to be used in my context to actually compile groovy as part of the build. The compilation is left to the groovy-eclipse-compiler.

I'll see if I can switch to gmavenplus.

[kdvolder]

I'm using the gmaven-plugin to execute a groovy script during the build

Okay, cool. I'm guessing the new behavior in greclipse configurator is malfunctioning in the sense that it probably assumes that its there to compile groovy and so its trying to configure source folders from it.

If so, then I think we should try to figure out a good 'check' to disable this functionality. I.e. if the config for gmaven / gmaven-plus looks like its not there for compiling stuff... ignore it.

The configurator isn't actually a terribly complicated piece of code. See here:

https://github.com/groovy/groovy-eclipse/blob/master/extras/org.codehaus.groovy.m2eclipse/src/org/codehaus/groovy/m2eclipse/GroovyProjectConfigurator.java#L73

Since you are actually using gmaven in exactly this way... any thoughts on how we could detect your case and just ignore the gmaven config in that specific case?

PS: Trying to switch to gmaven-plus for your compile may be a good idea, but it doesn't mean we are trying to deliberatly break your builds. The greclipse compiler should continue to work as a long as you are content to keep using the old versions. So I think we can somehow fix the misbhaving greclipse m2econfigurator instead.

[reckart]

@kdvolder How about something like this:

 Plugin plugin = getGMavenPlugin(mavenProject);
        if (plugin != null) {
            SourceType st = getSourceTypeInGMavenProject(plugin);
            // Consider it a GMaven project only if GMaven is actually configured to compile
            if (!SourceType.NONE.equals(st)) {
              return st;
            }
        }

[reckart]

@kdvolder I think the same kind of fall-through should be applied to the other compiler mechanisms.

[kdvolder]

I think the same kind of fall-through should be applied to the other compiler mechanisms.

Yeah, but I don't want to put in a lot of extra logics as it risks breaking more things than it fixes. So I'd rather try to fix it on a case-by-case basis. I.e. when we know of a case where its doing the wrong thing because someone reported it, we try and fix that case only.

Sorry haven't had much time to look at this yet. I'll try and get to it next week.

[eric-milles]

Is this still an issue? I was editing this code yesterday and could get a fix in if it is still a problem.

[reckart]

After hitting this issue, I switched all my project to another Maven groovy plugin where the problem did not occur.

[reckart]

More specifically, I switched to gmavenplus. So I can't tell if it is still an issue with GMaven.