I put this page together to try to explain the pros and cons of different tools: https://github.com/groovy/GMavenPlus/wiki/Choosing-Your-Build-Tool
-Keegan On Sun, Jun 19, 2016 at 8:09 AM, Jochen Theodorou <[email protected]> wrote: > On 18.06.2016 20:12, Mr Andersson wrote: > >> I was able to get it to work, both as separate groovy and java >> directories and as one directory ( basically a groovy directory with >> mixed ). >> >> It is interesting how complex this task was. It would appear as if the >> Groovy community should have figured this out by now. >> > > From the project side we support an ant task, command line and a > programmatic way to do joint compilation. The task is complex because the > build tools and the scenarios are. Gradle has much better support for > Groovy because we use it for our own build, but most of all, because the > Gradle people care. > > I finally ( after 10 hours ) was able to get it to work, using only ANT. >> The question is why Gmaven, GMaven2 Eclipse maven, and what not is even >> mentioned when it is as simple as an ANT task. >> > > command line is even more simple ;) > > In constract, pulling in Scala and Kotlin ( during the process which I >> gave up on Groovy ) took seconds. >> > > well, there are some maven people, here only very few > > Relying on the Eclipse compiler is not a good thing as it has a history >> of breaking and not being up to date with any other compiler that one >> might wish to use. >> > > Which is why the page suggests gmavenplus for maven... maybe that should > be more clear > > > The solution ( note that I change some other things as well, like I >> don't use src/main/java but just src ): >> >> <properties> >> <java.version>1.8</java.version> >> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> >> >> <org.springframework.version>4.0.6.RELEASE</org.springframework.version> >> >> <skipTests>true</skipTests> >> <maven.test.skip>true</maven.test.skip> >> >> <myproject.src>${basedir}/src</myproject.src> >> <myproject.test>${basedir}/test</myproject.test> >> >> >> <myproject.srcOutput>${project.build.directory}/WEB-INF/classes</myproject.srcOutput> >> >> >> <myproject.testOutput>${project.build.directory}/WEB-INF/classes</myproject.testOutput> >> </properties> >> >> >> <sourceDirectory>${myproject.src}</sourceDirectory> >> <testSourceDirectory>${myproject.src}</testSourceDirectory> >> >> <!-- This is an important part, especially in development mode, where we >> treat the compiled output the same as when served through a container, >> we place in a /WEB-INF/classes/ directory, \ rather than the default >> /classes/ allowing us to have consistent resources lookup through out >> all environments --> >> <outputDirectory>${myproject.srcOutput}</outputDirectory> >> <testOutputDirectory>${myproject.srcOutput}</testOutputDirectory >> >> >> <plugin> >> <inherited>true</inherited> >> <groupId>org.apache.maven.plugins</groupId> >> <artifactId>maven-compiler-plugin</artifactId> >> <version>3.5.1</version> >> <configuration> >> <source>${java.version}</source> >> <target>${java.version}</target> >> >> <!-- See: >> >> http://stackoverflow.com/questions/17944108/maven-compiler-plugin-always-detecting-a-set-of-sources-as-stale >> --> <useIncrementalCompilation>false</useIncrementalCompilation> >> </configuration> >> >> <executions> >> <execution> >> <id>default-compile</id> >> <phase>none</phase> >> </execution> >> </executions> >> </plugin> <plugin> >> <groupId>org.apache.maven.plugins</groupId> >> <artifactId>maven-antrun-plugin</artifactId> >> <version>1.8</version> >> <executions> >> <execution> >> <id>groovyc-compile</id> >> <phase>compile</phase> >> <configuration> >> <target> >> <taskdef name="groovyc" >> classname="org.codehaus.groovy.ant.Groovyc"> >> <classpath refid="maven.compile.classpath"/> >> </taskdef> >> >> <mkdir dir="${myproject.src}"/> >> <mkdir dir="${myproject.srcOutput}"/> >> <groovyc destdir="${myproject.srcOutput}" >> srcdir="${myproject.src}" listfiles="true"> >> <classpath refid="maven.compile.classpath"/> >> <src> >> <pathelement path="${myproject.src}" /> >> </src> >> >> <javac source="1.8" target="1.8" debug="on" >> encoding="UTF-8"/> >> </groovyc> >> >> </target> >> </configuration> >> <goals> >> <goal>run</goal> >> </goals> >> </execution> >> </executions> >> </plugin> >> > > I see, good to have that here. Now what are the main cons with this? > > compared with gmaven plus: > * not really integrated in maven, thus you always compile all files > > compared with eclipse groovy plugin: > * stubs cannot compile as many scenarios as the integrated approach of the > eclipse groovy compiler > * not really integrated in maven, thus you always compile all files > > I am working on a new compiler tool for Groovy, which is supposed to have > less of those disadvantages, for which I will then also look for more > proper maven integration (I am hoping here on the help of gmaven plus). But > that is still in the future and no fast project, because my free time is > limited > > bye Jochen > >
