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 Tue, 21 Jun 2016 13:12:32 GMT
Also the usage page <https://github.com/groovy/GMavenPlus/wiki/Usage> has
the two most common ways GMavenPlus is used.

-Keegan

On Tue, Jun 21, 2016 at 8:31 AM, Winnebeck, Jason <
Jason.Winnebeck@windstream.com> wrote:

> 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