Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

On 06/26/2016 11:22 AM, Jochen Theodorou wrote:

On 26.06.2016 09:14, Mr Andersson wrote:



On 06/24/2016 10:40 PM, Jochen Theodorou wrote:

On 24.06.2016 17:41, Mr Andersson wrote:
[...]
If you want to convince me of switching, i am still looking/waiting 
for

someone to offer cyclic dependency support between modules, since
without it, my code is getting more complex than need be.


then you probably do not want modules, but just multiple source
folders... because what advantages are left of modules if they are
cyclic?


Access rights. Even if a module/package is a cyclic, unless another
module has specifically declared that you can access it, can you access
it. It is like packages, but with access rules attached to them, which
does not exist currently.


How exactly are you using that? I know only dependencies, no module 
level access rights, since I guess you do not talk about jdk9 jigsaw. 
And how do these translate to runtime?


No, in the runtime there are no checks. As you know, currently a module 
in maven can only access another if it  declares a dependency on 
another. This might be happening at compile time in Maven where a 
missing import will raise an error because of a missing jar file.


I am arguing for a maven like dependency manager, that would build a 
Java like package structure based on the modules it imports. So module A 
and module B would go into one package, where by default ( in Java ) 
they can access each other as they please. But to prevent say B from 
accessing A, you need to check that B actually has a dependency declared 
on A, and then raise an error. This would occur at build time.


Imagine like a one big module project, that only consists of root 
packages, each mimicking a module. That would work fine for me, and 
enable cyclic dependencies to work, but I can not as of now enforce 
rules on access rights, which if I turn the project to someone else, 
someone might start using packages across and destroy any extraction of 
one module, without extracting all project/modules.


I am not sure how Intelllij does it, but in Intellij modules can have 
cyclic dependencies between them. The only problem is that Intellij only 
offers it inside Intellij and does not offer a maven like dependency 
manager to build a project, declare dependencies from a config, download 
dependencies and what not.






bye Jochen

Re: Integrating Groovy with a Java EE application and Maven

[Jochen Theodorou]

On 26.06.2016 09:14, Mr Andersson wrote:



On 06/24/2016 10:40 PM, Jochen Theodorou wrote:

On 24.06.2016 17:41, Mr Andersson wrote:
[...]

If you want to convince me of switching, i am still looking/waiting for
someone to offer cyclic dependency support between modules, since
without it, my code is getting more complex than need be.


then you probably do not want modules, but just multiple source
folders... because what advantages are left of modules if they are
cyclic?


Access rights. Even if a module/package is a cyclic, unless another
module has specifically declared that you can access it, can you access
it. It is like packages, but with access rules attached to them, which
does not exist currently.


How exactly are you using that? I know only dependencies, no module 
level access rights, since I guess you do not talk about jdk9 jigsaw. 
And how do these translate to runtime?


bye Jochen

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

On 06/24/2016 10:40 PM, Jochen Theodorou wrote:

On 24.06.2016 17:41, Mr Andersson wrote:
[...]

If you want to convince me of switching, i am still looking/waiting for
someone to offer cyclic dependency support between modules, since
without it, my code is getting more complex than need be.


then you probably do not want modules, but just multiple source 
folders... because what advantages are left of modules if they are 
cyclic?


Access rights. Even if a module/package is a cyclic, unless another 
module has specifically declared that you can access it, can you access 
it. It is like packages, but with access rules attached to them, which 
does not exist currently.




[...]

I also have hate the fact that I have to keep creating modules for every
thing. If I have a module Core containing many utility classes, another
module should be able to import only a package from Core, alternatively
only a class from Core. That might be tricky, but it is desirable, and
not unresolvable. Take the case where I decide to publish an Opensource
library using a few things out of Core. Now I have to create another
module move things out of Core, to expose and share only what is
required with world.  If another opensource library is created that uses
something else from Core, and something from the already extracted
module, then we end up in hell.


you can filter sources/classes by (package)name... even create virtual 
projects in gradle


Cool, i need to look at those things eventually. I think maybe gradle 
can offer me this kind of power where i can exactly decide using tasks 
what something includes and does not include.




bye Jochen

Re: Integrating Groovy with a Java EE application and Maven

[Jochen Theodorou]

On 24.06.2016 17:41, Mr Andersson wrote:
[...]

If you want to convince me of switching, i am still looking/waiting for
someone to offer cyclic dependency support between modules, since
without it, my code is getting more complex than need be.


then you probably do not want modules, but just multiple source 
folders... because what advantages are left of modules if they are cyclic?


[...]

I also have hate the fact that I have to keep creating modules for every
thing. If I have a module Core containing many utility classes, another
module should be able to import only a package from Core, alternatively
only a class from Core. That might be tricky, but it is desirable, and
not unresolvable. Take the case where I decide to publish an Opensource
library using a few things out of Core. Now I have to create another
module move things out of Core, to expose and share only what is
required with world.  If another opensource library is created that uses
something else from Core, and something from the already extracted
module, then we end up in hell.


you can filter sources/classes by (package)name... even create virtual 
projects in gradle


bye Jochen

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

On 06/22/2016 10:30 AM, Cédric Champeau wrote:


You should really give Gradle a try. It's pretty straightforward.



I have tried it, i found it "too dirty", too groovy, too dynamic, 
although I know it's an excellent tool for building and hooking into the 
build process.


I also found there was too many ways of doing the same thing, which to 
me always is an issue, since I have to figure out what the difference 
is, and then choose which way is most preferable. Too much choice leaves 
my mind spinning.


But, I am not a great fan of maven either.

If you want to convince me of switching, i am still looking/waiting for 
someone to offer cyclic dependency support between modules, since 
without it, my code is getting more complex than need be.


For me the problem can be solved, since packages in a Java project can 
have cyclic dependencies.
One just need a way to declare rules that prevent one package to access 
another if it is not declared that it wants access to it. Basically, 
"modules/packages" would have a rule saying that it can access another 
package.


A build tool such as maven, gradle, "new one" could then build one jar 
containing the other resources, mimicking one big module containing 
other "modules". I know Intelij modules allows for cyclic dependencies 
too, so the problem is defenitely solvable, although Intellij has a 
habit of destroying whatever setup one has, and there is no way to 
externalize that outside of Intellij.


All modules could then access each other as per definition as they 
please and we would have cyclic dependency.


I know people argue that modules shouldn't have cyclic dependencies and 
that is bad design. What is true however, is the opposite. Bad design is 
forcing one not to have it, just out of a principle. There are cases 
where cyclic dependency is important, and a problem becomes almost 
impossible if not awkward to solve without.


I also have hate the fact that I have to keep creating modules for every 
thing. If I have a module Core containing many utility classes, another 
module should be able to import only a package from Core, alternatively 
only a class from Core. That might be tricky, but it is desirable, and 
not unresolvable. Take the case where I decide to publish an Opensource 
library using a few things out of Core. Now I have to create another 
module move things out of Core, to expose and share only what is 
required with world.  If another opensource library is created that uses 
something else from Core, and something from the already extracted 
module, then we end up in hell.


Maybe Gradle is able to pull that off with build scripts though. Hmm. It 
got me thinking of a switch might give me the power to do what I want.


I am glad I did everything in Maven so far, because it gave me control, 
and I guess I could convert to Gradle now.


Example of cyclic dependency issues, forcing:

module App

module FinanceApp -> access to -> App
module TvApp -> access to -> App
module NewsApp -> access to -> App

But what if you wanted a central location where you did something that 
needs access to all modules?
For example, I prefer to have all exception handling in one location, as 
well as all Authentication and Permissions declared in one class, with 
access FinanceController.class for instance ( class reference, not 
strings to be refactor friendly) as to not have them declared across 
many modules and loosing control of who has access to what. I also need 
to build bundles for all the modules, preferably in one location.


The perfect location would be App. But App can't access Finance, Tv or 
News now.


So to resolve it, maven and other build tools forces you to declare 
another module, which we can call


module Base -> access to >{ Finance, Tv, News } -> App

The others would then:

module FinanceApp -> access to -> App
module TvApp -> access to -> App
module NewsApp -> access to -> App

One extra module just to be able to support access from one module to 
all. But now the problem arises where Finance can't see what is being 
configured in Base. For instance, in development mode, the finance 
application might need to rebuild the bundles or reconfigure the 
authentication logic. The problem is solvable through setting a lambda 
for that in App from Base, but it's not a pretty solution.


Cyclic dependency makes sense in packages, why not across modules, if I 
desire it.





Le 21 juin 2016 23:40, "Mr Andersson" > a écrit :




On 06/21/2016 10:39 PM, Jochen Theodorou wrote:

On 21.06.2016 09:04, Mr Andersson wrote:

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.


yeah, forget about those... gmavenplus is supposed to work. If
that one does not do the job, then there is a problem

[...]

Plus have you seen the size of

Re: Integrating Groovy with a Java EE application and Maven

[Cédric Champeau]

You should really give Gradle a try. It's pretty straightforward.
Le 21 juin 2016 23:40, "Mr Andersson"  a écrit :

>
>
> On 06/21/2016 10:39 PM, Jochen Theodorou wrote:
>
> On 21.06.2016 09:04, Mr Andersson wrote:
>
> 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.
>
>
> yeah, forget about those... gmavenplus is supposed to work. If that one
> does not do the job, then there is a problem
>
> [...]
>
> 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.
>
>
> you wanted joint compilation, so go to
> https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation and
> hopefully be done.
>
>
> Did not work :(
>
>
> The ant task for me is good enough.
>
>
> well, then everything is almost fine ;)
>
> [...]
>
> 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
>
>
>
> Yes, you are right.
>
> 
> org.apache.maven.plugins
> maven-antrun-plugin
> 1.8
> 
> 
> groovyc-compile
> compile
> 
> 
>  classname="org.codehaus.groovy.ant.Groovyc">
> 
> 
> 
>
> 
> 
> run
> 
> 
> 
>
> This seems to be enough and built successfully. Great! Even simpler!
>
> If only I could pass a compilesStatic flag too. But I guess I could put the 
> classpath to a global config file for now.
> But Groovy should consider adding such a flag alternatively provide a jar 
> that has this option turned on.
> It will bring back Groovy++ and that's defintely desirable. I love Groovy and 
> it's closeness
>  to the java syntax and it's much better interop with Java and have been 
> resisting a switch to Scala and
> Kotlin because you have to use ugly syntax to access from Java their logic. 
> With Groovy it is basically Java.
> Groovy adds so much to Java and should really have an option to go static.
>
> I think the maven structure is not really made for executing command line
> commands... you could always use the ant runner to do that kind of thing of
> course, but then why use maven at all.
>
> 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.
>
> maven works best if you follow the maven conventions and the very few
> maven projects I had to do with really tried to follow that.
>
> And I doubting the procedure is different for gradle.
>
> give it a try. But it has its quirks too as well of course. For example if
> you have files in src/main/java and in src/main/groovy, the groovy plugin
> will not do joint compilation for the files in src/main/java. You can
> easily change that by sourceSets.main.java.srcDirs = []
> sourceSets.main.groovy.srcDirs += ["src/main/java"] or use a totally
> different folder or multiple folders. ant is more direct in that you
> will always have to supply that information anyway. if that is more easy or
> not, I don´t know. But I have seen some pretty complex builds and most of
> them I really would not like to do with ant I must say.
>
> 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.
>
> Most important is that you got something working. Granted, it took too
> long and longer than it should have, and that is the fault of our
> documentation. Which brings me to the point of asking you what you would
> suggest how we should change our documentation so the next one will not
> have to do so much fighting.
>
> Add the ant option at the top. Gmavenplus did not work for me when I tried
> the join compilation option.
>
> [...]
>
> I am not sure what it means that you always

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

On 06/21/2016 10:39 PM, Jochen Theodorou wrote:

On 21.06.2016 09:04, Mr Andersson wrote:

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.


yeah, forget about those... gmavenplus is supposed to work. If that 
one does not do the job, then there is a problem


[...]

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.


you wanted joint compilation, so go to 
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation 
and hopefully be done.


Did not work :(




The ant task for me is good enough.


well, then everything is almost fine ;)

[...]

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 





Yes, you are right.


org.apache.maven.plugins
maven-antrun-plugin
1.8


groovyc-compile
compile









run



This seems to be enough and built successfully. Great! Even 
simpler! If only I could pass a compilesStatic flag too. But I guess I 
could put the classpath to a global config file for now. But Groovy 
should consider adding such a flag alternatively provide a jar that has 
this option turned on. It will bring back Groovy++ and that's defintely 
desirable. I love Groovy and it's closeness to the java syntax and it's 
much better interop with Java and have been resisting a switch to Scala 
and Kotlin because you have to use ugly syntax to access from Java their 
logic. With Groovy it is basically Java. Groovy adds so much to Java and 
should really have an option to go static.


I think the maven structure is not really made for executing command 
line commands... you could always use the ant runner to do that kind 
of thing of course, but then why use maven at all.
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. 
maven works best if you follow the maven conventions and the very few 
maven projects I had to do with really tried to follow that.
And I doubting the procedure is different for gradle. 
give it a try. But it has its quirks too as well of course. For 
example if you have files in src/main/java and in src/main/groovy, the 
groovy plugin will not do joint compilation for the files in 
src/main/java. You can easily change that by 
sourceSets.main.java.srcDirs = [] sourceSets.main.groovy.srcDirs += 
["src/main/java"] or use a totally different folder or multiple 
folders. ant is more direct in that you will always have to supply 
that information anyway. if that is more easy or not, I don´t know. 
But I have seen some pretty complex builds and most of them I really 
would not like to do with ant I must say.
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. 
Most important is that you got something working. Granted, it took too 
long and longer than it should have, and that is the fault of our 
documentation. Which brings me to the point of asking you what you 
would suggest how we should change our documentation so the next one 
will not have to do so much fighting. 
Add the ant option at the top. Gmavenplus did not work for me when I 
tried the join compilation option.

[...]
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. 
It means, that if you change one class, you will compile all of them 
and live with the build overhead. If you have several hundred files to 
compile, this will add up during development and testing. 
For intellij this doesn't seem 

Re: Integrating Groovy with a Java EE application and Maven

[Jochen Theodorou]

On 21.06.2016 09:04, Mr Andersson wrote:

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.


yeah, forget about those... gmavenplus is supposed to work. If that one 
does not do the job, then there is a problem


[...]

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.


you wanted joint compilation, so go to 
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation and 
hopefully be done.



The ant task for me is good enough.


well, then everything is almost fine ;)

[...]

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


I think the maven structure is not really made for executing command 
line commands... you could always use the ant runner to do that kind of 
thing of course, but then why use maven at all.



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.


maven works best if you follow the maven conventions and the very few 
maven projects I had to do with really tried to follow that.



And I doubting the procedure is different for gradle.


give it a try. But it has its quirks too as well of course. For example 
if you have files in src/main/java and in src/main/groovy, the groovy 
plugin will not do joint compilation for the files in src/main/java. You 
can easily change that by


sourceSets.main.java.srcDirs = []
sourceSets.main.groovy.srcDirs += ["src/main/java"]

or use a totally different folder or multiple folders. ant is more 
direct in that you will always have to supply that information anyway. 
if that is more easy or not, I don´t know. But I have seen some pretty 
complex builds and most of them I really would not like to do with ant I 
must say.



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.


Most important is that you got something working. Granted, it took too 
long and longer than it should have, and that is the fault of our 
documentation. Which brings me to the point of asking you what you would 
suggest how we should change our documentation so the next one will not 
have to do so much fighting.


[...]

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.


It means, that if you change one class, you will compile all of them and 
live with the build overhead. If you have several hundred files to 
compile, this will add up during development and testing.



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



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


agreed.. though will only if you follow the conventions for maven, 
because any different way will require additional configuration.. but I 
guess that is clear already


bye Jochen

Re: Integrating Groovy with a Java EE application and Maven

[Keegan Witt]

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.winneb...@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@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 ):
> >>
> >> 
> >>  1.8
> >> UTF-8
> >> 4.0.6.RELEASE
> >>
> >>  true
> >>  true
> >>
> >>  ${basedir}/src
> >> ${basedir}/test
> >>
> ${project.build.directory}/WEB-INF/classes
> >>
> ${project.build.directory}/WEB-INF/classes
> >> 
> >>
> >>
> >> ${myproject.src}
> >> ${myproject.src}
> >>
> >> 
> >&

RE: Integrating Groovy with a Java EE application and Maven

[Winnebeck, Jason]

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@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 ):
>>
>> 
>>  1.8
>> UTF-8
>> 4.0.6.RELEASE
>>
>>  true
>>  true
>>
>>  ${basedir}/src
>> ${basedir}/test
>> ${project.build.directory}/WEB-INF/classes
>> ${project.build.directory}/WEB-INF/classes
>> 
>>
>>
>> ${myproject.src}
>> ${myproject.src}
>>
>>  
>> ${myproject.srcOutput}
>> ${myproject.srcOutput}>
>>
>> 
>>  true
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>>  ${java.version}
>>  ${java.version}
>>
>>   false
>>  
>>
>>  
>>  
>>  default-compile
>>  none
>>  
>>  
>>  
>>  org.apache.maven.plugins
>>  maven-antrun-plugin
>>  1.8
>>  
>>  
>>  groovyc-compile
>>  compile
>>  
>>  
>>  > classname="org.codehaus.groovy.ant.Groovyc">
>>  
>> 

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

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


 1.8
UTF-8
4.0.6.RELEASE

 true
 true

 ${basedir}/src
${basedir}/test
${project.build.directory}/WEB-INF/classes
${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}

 
${myproject.srcOutput}

${myproject.srcOutput}
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}

  false
 

 
 
 default-compile
 none
 
 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 1.8
 
 
 groovyc-compile
 compile
 
 
 classname="org.codehaus.groovy.ant.Groovyc">

 
 

 
 
 srcdir="${myproject.src}" listfiles="true">

 
 
 
 

 encoding="UTF-8"/>

 

 
 
 
 run
 
 
 



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 plu

RE: Integrating Groovy with a Java EE application and Maven

[Winnebeck, Jason]

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@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 
mailto:blackd...@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 ):


 1.8
 UTF-8
 4.0.6.RELEASE

 true
 true

 ${basedir}/src
 ${basedir}/test
 
${project.build.directory}/WEB-INF/classes
 
${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}

 ${myproject.srcOutput}
${myproject.srcOutput}
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}

  false
 

 
 
 default-compile
 none
 
 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 1.8
 
 
 groovyc-compile
 compile
 
 
 
 
 

 
 
 
 
 
 
 

 
 

 
 
 
 run
 
 
 


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,

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

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


 1.8
 UTF-8
 
4.0.6.RELEASE

 true
 true

 ${basedir}/src
 ${basedir}/test
 
${project.build.directory}/WEB-INF/classes
 
${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}


${myproject.srcOutput}
${myproject.srcOutput}
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}

  false
 

 
 
 default-compile
 none
 
 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 1.8
 
 
 groovyc-compile
 compile
 
 
 
 
 

 
 
 
 
 
 
 

 
 

 
 
 
 run
 
 
 



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

Re: Integrating Groovy with a Java EE application and Maven

[Keegan Witt]

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  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 ):
>>
>> 
>>  1.8
>>  UTF-8
>>
>>  4.0.6.RELEASE
>>
>>  true
>>  true
>>
>>  ${basedir}/src
>>  ${basedir}/test
>>
>>  
>> ${project.build.directory}/WEB-INF/classes
>>
>>  
>> ${project.build.directory}/WEB-INF/classes
>> 
>>
>>
>> ${myproject.src}
>> ${myproject.src}
>>
>> 
>> ${myproject.srcOutput}
>> ${myproject.srcOutput}>
>>
>> 
>>  true
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>>  ${java.version}
>>  ${java.version}
>>
>>   false
>>  
>>
>>  
>>  
>>  default-compile
>>  none
>>  
>>  
>>  
>>  org.apache.maven.plugins
>>  maven-antrun-plugin
>>  1.8
>>  
>>  
>>  groovyc-compile
>>  compile
>>  
>>  
>>  > classname="org.codehaus.groovy.ant.Groovyc">
>>  
>>  
>>
>>  
>>  
>>  > srcdir="${myproject.src}" listfiles="true">
>>  
>>  
>>  
>>  
>>
>>  > encoding="UTF-8"/>
>>  
>>
>>  
>>  
>>  
>>  run
>>  
>>  
>>  
>> 
>>
>
> 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
>
>

Re: Integrating Groovy with a Java EE application and Maven

[Jochen Theodorou]

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


 1.8
 UTF-8
 4.0.6.RELEASE

 true
 true

 ${basedir}/src
 ${basedir}/test
 
${project.build.directory}/WEB-INF/classes
 
${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}

 ${myproject.srcOutput}
${myproject.srcOutput}
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}

  false
 

 
 
 default-compile
 none
 
 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 1.8
 
 
 groovyc-compile
 compile
 
 
 
 
 

 
 
 
 
 
 
 

 
 

 
 
 
 run
 
 
 



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

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

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.


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.


In constract, pulling in Scala and Kotlin ( during the process which I 
gave up on Groovy ) took seconds.


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.


The solution ( note that I change some other things as well, like I 
don't use src/main/java but just src ):



1.8
UTF-8
4.0.6.RELEASE

true
true

${basedir}/src
${basedir}/test

${project.build.directory}/WEB-INF/classes

${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}

 ${myproject.srcOutput}

${myproject.srcOutput}
true
org.apache.maven.plugins
maven-compiler-plugin
3.5.1

${java.version}
${java.version}

 false





default-compile
none


 
org.apache.maven.plugins
maven-antrun-plugin
1.8


groovyc-compile
compile








listfiles="true">













run








On 06/18/2016 07:34 PM, Schalk W. Cronjé wrote:
I dob't know about Ant, but in Gradle it us eady to get 
joint-compilation of Groovy & Java if eerything is under the 
src/main/groovy folder.




Sent from my Samsung device


 Original message 
From: Mr Andersson 
Date: 18/06/2016 18:39 (GMT+01:00)
To: users@groovy.apache.org
Subject: Re: Integrating Groovy with a Java EE application and Maven

I have gotten a bit further in my research and came up with this 
sample project which uses ant to compile the groovy classes but I 
can't get them to compile together.


To be able to have cyclic dependencies between Java and Groovy files.

Here is a standalone isolated maven project that contains everything:

http://www.speedyshare.com/TbQyG/Isolated.zip

Pom file:

 xmlns="http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>

 4.0.0

 Isolated
 Isolated
 Isolated
 1.0
 http://maven.apache.org

 jar
 
 

 1.8
 UTF-8
 true
 true
 
 
 

 
 org.codehaus.groovy
 groovy-all
 2.4.6  
 

 
 
 
 
 

 
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}
 
 
 
  

 maven-antrun-plugin
 
 
 

 compile
 compile
 
 
 
 
 
 

 
 
 
 
 srcdir="${basedir}/src/main/groovy/" listfiles="true">

 
 
 
 

 
 
 run
 
 
 
 

 
 
 

Re: Integrating Groovy with a Java EE application and Maven

[Schalk W . Cronjé]

I dob't know about Ant, but in Gradle it us eady to get joint-compilation of 
Groovy & Java if eerything is under the src/main/groovy folder.


Sent from my Samsung device

 Original message 
From: Mr Andersson  
Date: 18/06/2016  18:39  (GMT+01:00) 
To: users@groovy.apache.org 
Subject: Re: Integrating Groovy with a Java EE application and Maven 


I have gotten a bit further in my research and came up with this
sample project which uses ant to compile the groovy classes but I
can't get them to compile together. 



To be able to have cyclic dependencies between Java and Groovy
files. 



Here is a standalone isolated maven project that contains
everything: 



http://www.speedyshare.com/TbQyG/Isolated.zip



Pom file: 





http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0   
   http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0

Isolated
Isolated
Isolated
1.0
http://maven.apache.org

jar


1.8
UTF-8
true
true




org.codehaus.groovy
groovy-all
2.4.6 







true
org.apache.maven.plugins
maven-compiler-plugin
3.5.1

${java.version}
${java.version}





maven-antrun-plugin



compile
compile

















run










  

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

I have gotten a bit further in my research and came up with this sample 
project which uses ant to compile the groovy classes but I can't get 
them to compile together.


To be able to have cyclic dependencies between Java and Groovy files.

Here is a standalone isolated maven project that contains everything:

http://www.speedyshare.com/TbQyG/Isolated.zip

Pom file:

 xmlns="http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>

4.0.0

Isolated
Isolated
Isolated
1.0
http://maven.apache.org

jar



1.8
UTF-8
true
true





org.codehaus.groovy
groovy-all
2.4.6  









true
org.apache.maven.plugins
maven-compiler-plugin
3.5.1

${java.version}
${java.version}



 

maven-antrun-plugin




compile
compile











srcdir="${basedir}/src/main/groovy/" listfiles="true">








run

Re: Integrating Groovy with a Java EE application and Maven

[Jochen Theodorou]

On 18.06.2016 13:40, Mr Andersson wrote:
[...]

I've tried:


 org.codehaus.groovy
 groovy
 2.4.7
 as well as 
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}


 groovy-eclipse-compiler
 true

  false
 

 
 
 org.codehaus.groovy
 groovy-eclipse-compiler
 2.9.2-01
 
 


according to 
https://github.com/groovy/groovy-eclipse/wiki/Groovy-Eclipse-Maven-plugin you 
need to define a dependency for groovy-eclipse-batch as well



 but this results in an error when a Java class is referencing
a Groovy class in the project.


where did you store your java and groovy source files?


I am not using eclipse. What are the
neccesary steps to get Groovy to work *seamlessly in a Groovy project in
2016* ? What are the limitations? Thanks!


you can always try the gmavenplus plugin... or migrate to gradle, it 
works much better there for me ;)


bye blackdrag