After switching to gradle 2.3 for wrapper I am noticing a lot more goals being added from application plugin and included as part of the build process. Its creating zip files, tar files, doing script related stuff for all subprojects. This is not the intended behavior. I would like to keep it the way it was before such that unless I explicitly specify the application plugin goals like distZip, they shouldnt be invoked as part of my gradle build.
This behaviour's caused by Spring Boot's Gradle plugin. I've opened an issue. I don't fully understand why the switching from Gradle 2.2 to 2.3 triggers a change in behaviour, but your best bet at the moment would appear to be to stick with Gradle 2.2.
Related
I am new to gradle. But I do understand to some extent why developers are encouraged to use gradlew instead of gradle. However what worse could happen if developers use different versions of gradle to build their project? At the end of the day any gradle version makes sure that dependencies of the project is managed properly. For example if a Spring Boot project is dependent of a starter plugin version 2.x, no matter what version of gradle is used, the build tool makes sure that 2.x is available
As far as I'm aware the main point to use a common version of Gradle is plugin compatibility.
Gradle's internal APIs changed quite a lot in the last few versions, so not every plugin works with every Gradle version.
For example: Spring Boot's 2.3.4 reference explicitly states that it's build plugin requires Gradle 6.3 or later (although 5.6 is mentioned to work in a deprecated form)
https://docs.spring.io/spring-boot/docs/2.3.x/reference/htmlsingle/#getting-started-system-requirements
So while you can be sure that the Spring Boot version is used (because you defined it in your buildfile) any older version of Gradle is likely to run into Exceptions when trying to build your project.
Even if you're just using plugins that are provided by Gradle itself there can be compatibility issues. For example the java configuration block was first introduced in Gradle 5 (I think) and therefore would cause a syntax error in earlier versions.
Or simple things like Java versions that older version of Gradle do not support.
The more plugins you use it becomes increasingly unlikely that a lot of Gradle versions will be able to run it. Using the Gradle Wrapper is therefore a simple way that your build works for everyone.
And from the other perspecitve: if you are the one that usually maintains the build you can use all the latest Gradle features using the Wrapper as you can be sure it will not break anything. Getting everyone on the team to update manually before you can use a feature can be a pain
That beeing said, it's really primarly a maintenance issue. Nothing bad can happen if anyone uses their own installed version of gradle, except it might just not work
If everyone on the team uses a similar version nothing might happen at all
I'm writing a plugin to extract some boilerplate from a selection of existing Gradle build scripts. The existing build scripts are primarily written in Groovy and compiling Java.
To build my plugin I'm using the Gradle Kotlin DSL and figured I'd take the opportunity to write the plugin in Kotlin too. This all works but now my plugin has a huge dependency on Kotlin - and the Gradle docs specifically recommend minimizing external libraries.
Java and Groovy plugins avoid this because Java & Groovy are a shared dependency with Gradle, but Kotlin isn't a shared pre-requirement and so we then have to be concerned about potentially conflicting Kotlin versions needed by different plugins.
I figure I should move forward with one of the following approaches but am not clear which:
Just list Kotlin's stdlib as a standard dependency and trust Gradle to sort things out.
This works for one plugin, but should I expect problems when another plugin is also being used but depending on a different Kotlin?
Build some sort of uber shadowJar shadowing Kotlin libraries for my plugin
Implying that every plugin I write like this will be 10s of MB bigger than necessary.
Give up on Kotlin based plugins and rewrite in Java/Groovy
Would be a shame to give up on the new goodness but might be better to avoid the above sins.
Recommendations welcome!
Since your plugin is replacing boilerplate and is presumably not destined for public release, would it make sense to write it as a script plugin in the Gradle Kotlin DSL? That way a new enough Gradle should be able to understand it natively.
Raised this in Gradle Community Slack and was recommended to use Gradle's kotlin-dsl plugin to automatically configure dependencies on gradleApi() and embeddedKotlin() versions, and therefore whatever Kotlin version is bundled with Gradle's Kotlin DSL support.
I was concerned that this might introduce a dependency on the calling script using Kotlin DSL, but I've tested with a Groovy script and have been able to use my plugin. I assume that it does still depend on a version of Gradle with Kotlin DSL support though - i.e. 4.0+.
Though i haven't any experience with gwt, my current task is integrating existing gwt project with maven. Some of the project java classes extend from com.google.gwt.core.ext.generator which is part of gwt-dev.jar. My issue is that gwt-dev.jar is not recommended to be included as maven dependency(even with provided scope), but in that case my project can't be compiled. How such kind of problem can be resolved ?
Thanks in advance.
If you're referring to the warning printed by Mojo's Maven Plugin for GWT, you can ignore it. If it ever causes issues, it'd mean you don't have split your client and server code in separate modules. gwt-dev as a dependency is the recommended setup, Mojo's Maven Plugin for GWT just hasn't updated yet.
I have a project that uses some Java and some Groovy, and it's all built with Maven. We use the GMaven plugin to compile the Groovy. I've been using Eclipse and have got fed up with the "Plugin execution not covered by lifecycle" message that indicates Eclipse is incapable of doing what my command-line does (I've tried adding the ignore/execute config to fix it, but it never works properly), so I've switched to Spring Tool Suite, which claims to have full Groovy support. How should I set it all up? So far I've had exactly the same experience as with regular Eclipse, but given that SpringSource are responsible for Groovy, I figure there must be a way of doing it.
Have you read this thread?
http://forum.springsource.org/showthread.php?130130-Working-with-Mavenized-Grails-projects-in-GGTS-3-1-0-Updated-for-3-1-0-release/page2
For grails projects, you do not need to use gmaven or the groovy-eclipse-compiler. You must be using the 3.1.0 STS (which is not actually released yet, but you can get this
You also must be using Grails 2.1.1.
You can secretly get a 3.1.0 release build by going to this download page:
http://www.springsource.org/downloads/sts-ggts
Instead of clicking on the links, copy them and substitute 3.1.0 for 3.0.0.
I am trying to write my pom.xml for a multimodal flex application. I have been using this resource as an example:
http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-creating-with-archetype.html
I am using M2E v1.01 but I am faced with a number of 'Plugin execution not covered by lifecycle configuration" errors. As far as I can see - there are no m2E connectors available to resolve this and I have tried all the Maven advice I can find - to include:
Clean
Update dependencies
Update project configuration
The problem only occurs if the project is declared as swc or swf package. My next move to ask Eclipse to 'permanently mark goal as ignored' - which seems a little brash.
Any advice would be appreciated.
Thanks in advance.
With STS 2.8.0, we have upgraded m2eclipse to be version 1.0. However, this can cause a bit of trouble with existing projects. I wrote a blog on this a couple of months ago.
http://blog.springsource.org/2011/10/18/upgrading-maven-integration-for-springsource-tool-suite-2-8-0/
Essentially, the new architecture for m2eclipse requires that each maven plugin you use must be mapped to one Eclipse plugin to handle the plugin's execution inside of Eclipse. This obviously causes problems since not every maven plugin author has the knowledge or time to create also create and maintain an Eclipse plugin.
By marking the plugin as ignored, you are saying that the plugin should never be executed inside of Eclipse (implying that whenever you need it to be executed, you will do so from the command line). Once marked as ignored, you can then change it to execute, which means that it should always be executed whenever the associated lifecycle is performed in Eclipse. This may cause performance problems, and so only do it if you know the risks.
If all this is too much for you, then STS provides a downgrade option to revert to an older version of m2eclipse. Go to the Dashboard extensions page. Unfortunately, you will have to manually revert all changes to your .project and .classpath files (we provide an auto-upgrade mechanism, but not a downgrade mechanism...presumably everything is in version control).
Any questions or problems should be sent to the STS forums:
http://forum.springsource.org/forumdisplay.php?32-SpringSource-Tool-Suite
You can check this alpha connector "Flex Maven Integration for Flash Builder" on the eclipse marketplace: http://marketplace.eclipse.org/node/648556.