groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Integrating Groovy with a Java EE application and Maven
Date Sun, 19 Jun 2016 12:09:39 GMT
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


Mime
View raw message