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 Tue, 21 Jun 2016 12:31:15 GMT
You are trying to do joint compilation so this is the only section you need:
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation

The only difference from pure Groovy compile and joint compilation is you list the stub tasks
to the goals. Basically all you do is add the gmavenplus-plugin and Groovy as a dependency.

Jason

-----Original Message-----
From: Mr Andersson [mailto:mr.andersson.002@gmail.com] 
Sent: Tuesday, June 21, 2016 3:04 AM
To: users@groovy.apache.org
Subject: Re: Integrating Groovy with a Java EE application and Maven

Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of compilation issues which
I started to correct, but then gave up on. I shouldn't have to change my code to get on Groovy.

I don't remember the exact errors, but there were some.

I just tried again and it failed. I tried the join compilation but failed. Files were not
recognized.

Plus have you seen the size of this examples page?

https://github.com/groovy/GMavenPlus/wiki/Examples

Fifty ways to configure. I don't even know anything about what I need when i start off, so
that's just too much headache.

The ant task for me is good enough.

See comments below.

On 06/19/2016 02:09 PM, Jochen Theodorou 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 ;)

Not easy to integrate a command line argument for maven it seems. I am not sure how you can
add that to the classpath. I was trying really hard on that but could not find any info, like
with everything involving searching for Java issues. Google sucks at this, or the Java folks
seriously do not ask or think enough about doing things the right way.

https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8

>
>> 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

Groovy has been alive for over 10 years. It has to be a couple of people wanting to integrate
Groovy in a JEE environment by now.

And I doubting the procedure is different for gradle.
>
>> 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

Did not work with both. The ant task should be the one mentioned because it will always succeed,
unless you can figure how to add it to the classpath.

>
>> 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

I am not sure what it means that you always compile all files. I haven't 
tried it enough but besides a 15 seconds extra build time, i don't see 
much difference in repetition.

>
> 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
>

It should be simple, one plugin declaration with all configuration right 
there, and work.

----------------------------------------------------------------------
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