groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: Integrating Groovy with a Java EE application and Maven
Date Sun, 19 Jun 2016 17:57:18 GMT
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 <blackdrag@gmx.org> 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
>
>

Mime
View raw message