can i tell amper not to add repositories, and use ...

# amper

[christophsturm]

can i tell amper not to add repositories, and use only maven central?

[joffrey]

Could you please describe your use case? This is definitely something we could consider, and it's nice to gather use cases as they come.

[joffrey]

At the moment there is no way to do this in the Amper config itself, but you can work around it by using Gradle interop.

I couldn't test these options yey, but you should be able to remove repositories from the list using repositories.removeIf { it.name != "maven" }. If you want to do this more generally, using a dependencyResolutionManagement block with PREFER_SETTINGS mode in your settings.gradle.kts should override Amper's default repos (which are added at the project level):

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }
    repositoriesMode = RepositoriesMode.PREFER_SETTINGS
}

[christophsturm]

my usecase is simply that when checking for updates its much faster when there is only maven central to check, and not a repo that contains 100s of kotlin snapshot builds.
also currently its really hard to filter out the snapshot builds:

The following dependencies have later milestone versions:
 - org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable [1.9.20 -> 1.9.24-786]
     <https://kotlinlang.org/>
 - org.jetbrains.kotlin:kotlin-serialization-compiler-plugin-embeddable [1.9.20 -> 1.9.24-786]
     <https://kotlinlang.org/>
 - org.jetbrains.kotlin:kotlin-stdlib [1.9.20 -> 2.0.0-241135-2]
     <https://kotlinlang.org/>
 - org.jetbrains.kotlin:kotlin-test [1.9.20 -> 2.0.0-241135-2]
     <https://kotlinlang.org/>
 - org.jetbrains.kotlin:kotlin-test-junit [1.9.20 -> 2.0.0-241135-2]

[christophsturm]

your suggestion with settings.gradle.kts works, but it outputs a lot of warnings for each subproject:

> Configure project :core
Build was configured to prefer settings repositories over project repositories but repository 'MavenRepo' was added by plugin 'org.jetbrains.amper.settings.plugin'
Build was configured to prefer settings repositories over project repositories but repository 'Google' was added by plugin 'org.jetbrains.amper.settings.plugin'
Build was configured to prefer settings repositories over project repositories but repository 'Gradle Central Plugin Repository' was added by plugin 'org.jetbrains.amper.settings.plugin'
Build was configured to prefer settings repositories over project repositories but repository 'maven' was added by plugin 'org.jetbrains.amper.settings.plugin'
Build was configured to prefer settings repositories over project repositories but repository 'maven2' was added by plugin 'org.jetbrains.amper.settings.plugin'

[joffrey]

Ah I didn't know Gradle warned about those. This is indeed not ideal.

Then probably removing repositories manually should work without warnings. And if you need to do it in many subprojects you could use a convention plugin or an allprojects block.

[christophsturm]

amper could just check if the mode is RepositoriesMode.PREFER_SETTINGS and then not add the repos. that would be perfect

[christophsturm]

is one goal of amper in its current state (0.2, 0.3) to be usable for small projects and be as good or better as gradle? or is it more just a prototype to try in experiments? if its the former, there are a lot of small things that could be fixed.

[joffrey]

amper could just check if the mode is RepositoriesMode.PREFER_SETTINGS and then not add the repos. that would be perfect

Thanks for the suggestion!

Note that removing default Amper repos may in general break some of Amper's functionality. For instance, people using settings.compose: enabled might have problems because compose dependencies might not be found in the user-provided repos. In that sense, the Gradle warning is legitimate.

One option could be to make Amper conditionally add repos only if a feature requires it, but that could have side effects on dependency resolution for users. Imagine removing compose: enabled and suddenly one of your dependencies cannot be resolved anymore. That might be a bit too surprising.

The idea of opting out of default Amper repos is probably a more suitable option. Amper could provide a setting to do this from module.yaml (which could be done globally via a template).

In a sense, using PREFER_SETTING or FAIL_ON_PROJECT_REPOS modes from Gradle settings could be considered a way to opt out too, as you suggested. We would need to evaluate how surprising that would be. I'll discuss this with the team.

[joffrey]

is one goal of amper in its current state (0.2, 0.3) to be usable for small projects and be as good or better as gradle? or is it more just a prototype to try in experiments? if its the former, there are a lot of small things that could be fixed.

Amper is still experimental, but it can already be used for several types of projects, and we are trying to provide the best possible experience for the use cases that we support. In that light, what would you like to be fixed? (feel free to open YouTrack issues as well if you want a more formal way to report them)

[christophsturm]

just small things like the thing with the repos. another thing it would be cool if it would work without so many repos declared in the settings file (move all the dependencies to the amper repo and make the android plugin optional).
or use more recent versions of dependencies, this is what I currently get:

The following dependencies have later milestone versions:
 - junit:junit [4.12 -> 4.13.2]
     <http://junit.org>
 - org.jetbrains.kotlin:kotlin-scripting-compiler-embeddable [1.9.20 -> 1.9.23]
     <https://kotlinlang.org/>
 - org.jetbrains.kotlinx:kotlinx-serialization-json [1.5.1 -> 1.6.3]
     <https://github.com/Kotlin/kotlinx.serialization>
 - org.junit.jupiter:junit-jupiter-api [5.9.2 -> 5.10.2]
     <https://junit.org/junit5/>
 - org.junit.jupiter:junit-jupiter-engine [5.9.2 -> 5.10.2]
     <https://junit.org/junit5/>