This profile is from a federated server and may be incomplete. Browse more on the original instance.

jendrik, to Kotlin

JetBrains introduces Amper. An experimental project description language for Multiplatform. The underlying system using the notation is still .

Happy to see such developments. The / build system is Gradle's killer application. But in its core it's a powerful framework to create build systems on top of.

The huge feature set of vanilla Gradle is probably it's biggest weakness when used directly by end users. Excited to see where this goes.

https://blog.jetbrains.com/blog/2023/11/09/amper-improving-the-build-tooling-user-experience/

brianverm, to Java
@brianverm@mastodon.social avatar

Hi Gradle users, I have a question. How do you replace or update a transitive dependency?
Is the preferred way to register the transitive dependency as a direct one, or are there better ways?
Is there an equivalent to dependencyManagement in Maven?

jendrik,

@brianverm The equivalent to Maven's 'dependencyManagement' in Gradle are 'Dependency Constraints'. That's what you are looking for (most likely).

dependencies.constraints {
implementation("org.apache.commons:commons-lang3:3.13.0")
}

https://docs.gradle.org/current/userguide/dependency_constraints.html

jendrik,

@kerfuffle @brianverm Do you mean:

(1) The plugin adds a dependency for your software (classpath of your application)?

(2) The plugin itself has a dependency when running inside Gradle (Gradle plugin classpath)?

In case (1): yes

In case (2): also yes, but you have to add the constraint for the plugin classpath. How you do that best depends on your setup. For example you can do in 'build.gradle':

buildscript {
dependencies.constraints {
classpath("...")
}
}

jendrik, to random

org.gradle.api.provider.Property<>

org.gradle.api.provider.Provider<>

These concepts changed how projects (should) look today.

I talk about why they were introduced and when/how you work with them.

https://www.youtube.com/watch?v=n8Tgr4aLB18&list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE

jendrik, to Java

supports different options to write plugins. This is good, because it gives you the choice to use what fits your context. Any you should always write plugins - if only to organize your project's build configuration.

But it is confusing 😖. That's why I created this overview:
https://github.com/jjohannes/gradle-plugins-howto

Learn by exploring the difference between writing the same Gradle plugins in:

jendrik, to random

How to structure software projects with ?

A thread 👇

https://github.com/jjohannes/gradle-project-setup-howto

jendrik, to Java

Maven Central and Gradle Plugin Portal should have never allowed to publish dependencies with not-fixed versions.

If you don't check your transitives carefully, something might sneak in. And you have non-reproducible builds. Which you only notice once something breaks.

Like here: https://github.com/google/guava/issues/6612#issuecomment-1618157335

#Gradle #Maven #Java #Dependencyhell

jendrik,

@tbroyer There are features in tools to make builds still stable – locking, additional constraints, forced versions, dependency rules...

I just think there is no value in publishing an open range in a public repository.

Did you go to the future to check that future versions will still work? No? Then what does it even mean?

It may be different in a "closed world" (e.g. company repository) where you can make assumptions about future versions. But in the open, it has zero value IMO.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines
    •