Is there a plugin or sth. else for Gradle that informs you when there are new library versions available for a certain depedency?
Might be difficult if some libs do not stick to well-known version conventions but for the others I think it should be possible to find out!?
If there is not, any hints how to implement this feature are appreciated.
Thanks
No such plugin ships with Gradle. There might be a third-party plugin, but I'm not aware of one. To implement this, you would iterate over a configuration's resolved dependencies (using the configuration.resolvedConfiguration or configuration.incoming API) and query some website (e.g. http://search.maven.org) or web service for latest versions. For API details, see the Gradle Build Language Reference.
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've been looking for the answer to this for a few days and have turned up empty.
I'm devving a Confluence plugin that integrates with a 3rd party app. This 3rd party app has a nice REST API and they even provide a Java SDK (yay!). Except.....the Java SDK has bundled a version of Jersey (1.18) that conflicts with Confluence's forked version of Jersey (1.8-atlassian_15). The SDK was not released as a Maven jar (or at least there's no pom.xml included). There ARE other pom.xml in the jar's META-INF for the dependencies it uses, but the SDK itself is just released as a jar download by the vendor.
So as I've done in the past, I mvn install:install-file the sucker with my own groupId and artifactId, thinking it'd be fine. Intellij recognized the library, everything compiled nicely, and then I tried my test call to the REST API. This is when it threw an error that made it evident that there's a conflict between the versions.
SOOOO. Is there anyway to get around this? Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses? I have a feeling that even after the Jersey dependency is resolved (if that's even possible) there will be other issues....The SDK also bundles the specific version of Jackson, Swagger, etc. with it.
I attempted to decompile the jar and include the decompiled code in my project, but that just had all of issues I'd rather not deal with ever again.
I have reached out the SDK devs to see if they could release a more maven-friendly release, but I'm not hopeful this will be done at all, and even it is, their release cycle is much different than my own requirements (read: I need a solution now). This is my last-ditch effort before rewriting the REST client from scratch.
Can I "sandbox" the SDK jar in a way the executes code in its own deal without being exposed to the nasties of Confluence's builtin version of libraries the SDK uses?
Sure you can. Often-used way to do this is to use Maven shade plugin that transforms an existing jar to a shaded jar, using another package hierarchy and getting rid of the package naming conflict. See also the documentation about relocating packages. I suggest you use that - that's what I've done in cases like this (though I haven't done confluence plugin development, but it should be the same thing as with other platforms).
That feature was very useful for us, but after upgrade sonar 5.1 to 5.6 we have missed it.
Reading this topic : Sonarqube dependency feature missing i want to ask if you know a similar alternative to check dependency libraries for a proyect.
We was using this feature for check 3PPs dependency shared between projects and check what other projects was using the same 3pp.
Do you know a similar tool?
There is a lot of talk about maven being the dependency resolution engine of choice (or Aether more specifically). What is the result of this change from an application development perspective? Going forward am I meant to use an external pom file to capture my dependencies rather than BuildConfig? Do I run create-pom on legacy projects upgraded to 2.3x? Is there a recommended approach?
The recommended approach is to express your dependencies in BuildConfig.groovy and let Grails take care of it from there. You don't need to generate a pom file unless you are trying to integrate your Grails build as part of some other build (like a Maven build). The normal thing to do, unless you have some specific reason to do otherwise, is to use the Grails build system which by default in recent versions will use aether to do the resolution, but that is largely an implementation detail and all you typically have to interact with is BuildConfig.groovy.
I hope that helps.
What happened to the Maven Polyglot project that used to be at http://polyglot.sonatype.org/?
As described in this article,
One exciting new feature in Maven 3 is it's ability to work with pom files written in non-XML notations. The Maven core now provides an underlying DSL to access the Maven internals, and write POM files in the language of your choice. This currently includes scripting languages like Groovy, Ruby, and others. In short, you will be able to write a DSL for virtually any scripting language you like that can hook into the Maven internals and pilot the Maven build process.
There are several additional articles on the web that I've found referencing the feature.
http://www.thinkplexx.com/learn/article/maven-learn-material/maven3/maven3-pom-using-groovy-ruby-scala-yaml-sonatype-polyglot
http://mattgivney.blogspot.com/2011/05/maven-3-polyglot-support.html
But the polyglot site now redirects to sonatype.org and I can find no mention of this feature in the Maven 3 release notes.
So what happened? Was it cut or is it in there and just not documented in the release notes? If it did make the cut for Maven 3 could you point to some documentation. I am also interested in the translator tool mentioned by the first article I linked to.
This project is now named tesla-polyglot. I've just completed the Scala DSL for it, and tesla-polyglot should be released very soon now. We're just waiting on Maven 3.1.1 to roll out of the door.
There has been an update on the maven users list from Jason van Zyl: http://maven.40175.n5.nabble.com/What-happened-to-Polyglot-Maven-td5715529.html
I'm still working on it along with a few others. Dhanji has the Atom markup working, Kristian has implemented a Ruby DSL, and Jason Dillon has implemented a Groovy DSL which creates synthetic plugins to bind arbitrary scripting to Maven's lifecycle. My original was to see how Maven's infrastructure could be leveraged by other markups and DSLs. These examples do render to an interoperable format insofar as consumers go. Maven itself obviously cannot run a Ruby DSL but if you like the Ruby DSL you can use it to build an not affect consumers: you can build and deploy to a Maven repository and someone else can consume the dependency with stock Maven.
I have all the early adopters I can deal with one-on-one right now, because I can't deal with many really, but if you have more than a passing interest feel free to email me privately.
looks like it is still alive :-)
You won't believe it, but it's released (if you can call a 0.1 version a release).
As of April 2016,
the home page is https://github.com/takari/polyglot-maven ,
the latest release is 0.1.15
There is Polyglot Maven IDE Pack for Eclipse, that includes some plugins.
There is also maven-tiles project https://github.com/repaint-io/maven-tiles ,
and quick trying out what Maven flavor works well shows that Groovy does better than others.
Be aware of Babylon Tower problem, so it is actually better when most of developers use the same flavor.
The latest info comes from here
"Polyglot for Maven is still moving along and we've seen a lot of activity recently on the Ruby DSL by Cristian Meier from the JRuby team, and the Scala DSL by Chris Hunt from Typesafe. We hope that this initial work can serve as inspiration for helping the POM evolve. For those interested in what the XML alternatives can look like you can take a look at the existing implementations:
Ruby DSL
Groovy DSL
Scala DSL
YAML
Atom"