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" <mr.andersson....@gmail.com
<mailto:mr.andersson....@gmail.com>> 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.
<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>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>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 to happen, no major build is
happening, maybe a slightly bigger one but barely noticable.
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
