groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: Integrating Groovy with a Java EE application and Maven
Date Mon, 20 Jun 2016 12:38:40 GMT
I work on multiple projects integrating Groovy including one large J2EE project. I’ve always
been able to work with out of the box gmavenplus integration: https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation.
For anyone using Maven I suggest only GMavenPlus. I set up groovy-eclipse-compiler on some
microservice projects that were created in the period after gmaven was discontinued and before
gmavenplus. With that solution I’ve had nothing but problems, the plugin lagged behind official
Groovy releases and the compilation results differed from groovyc, especially when CompileStatic
was used, most often things would fail to compile in groovy-eclipse-compiler but work in groovyc,
which was annoying since we developed with IntelliJ IDEA which uses groovyc built-in then
the Maven builds would fail. Therefore we move to GMavenPlus whenever possible.

Jason

From: Mr Andersson [mailto:mr.andersson.002@gmail.com]
Sent: Monday, June 20, 2016 7:58 AM
To: users@groovy.apache.org
Subject: Re: Integrating Groovy with a Java EE application and Maven

Cons:

Requires Eclipse compiler. Big cons. Especially version < 4.4 which seems to be the one
used by Gmaven and maven.

The ant way is just fine and is the easiest one. The cons are pretty slim if you ask me.

But thanks for clarifying. Now I know I have made the right decision.
On 06/19/2016 07:57 PM, Keegan Witt wrote:
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<mailto: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



----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
Mime
View raw message