made this channel public. Any member in this workspace can see and join it.

Is there any information regarding what inspired the name “Amper”? Does it mean something? In my mind I immediately thought of Amber, but this isn’t the inspiration right?

so, any official build for amper so i can use it from command line? running fedora here

Hello o7 I have some questions: What are the benefits over normal Kotlin DSL? As it has auto-complete already. Will it have an LSP for other IDEs/Editors outside of Jetbrains? Will it be open-source, so that other extensions (notably from the community) can be added in the future? Is the scope only for Kotlin, JVM and Swift or will it has support for Scala or Clojure later on?

set the channel description: Discussing Amper: a project configuration tool by JetBrains

set the channel topic: Discussing Amper: a project configuration tool by JetBrains

Is amper only available for Mac ? Doesn't work on fleet on windows and can't find it in the marketplace of intellij Idea.

I noticed the amper repo doesn't have the source for the plugin. Will the project be open-sourced in the future?

I've seen the FAQ for why Gradle isn't being extended, but I'm still not getting it. Does Amper provide something that Gradle isn't able to? At the surface it seems to be that Amper could be a regular gradle plugin with an easier to work with extension, like how convention plugins work. I'd hate to see the build system get fractured (especially after investing a lot of time in mastering Gradle 😅).

Testing questions in general 🧵

Noticed in the docs this is mentioned:

NOTE: Since Amper is currently Gradle-based

Are there long term plans to possibly move away from gradle? 😏 or at least decoupling it so another build system can be used? - Anyways, super glad this is happening - imo gradle build scripts (kotlin or groovy) has always left a lot to be desired from a developer experience standpoint

Continuing the discussion from the thread in the announcement: I’m happy you already plan to add the per-file/folder

@platform

suffix. 🥳 Also, I’ve seen that you can build native JVM-less cli tools and tried it out a little bit. It’s awesome that a simple file containing only

product: macos/app

was sufficient. No need to apply plugins and reading long docs about how to configure a native cli build. It just worked and that’s how it should be. 🚀 Also looking at the possible publication setup and other configs, the YAML based DSL removes so much friction compared to Gradle. I’ll post a few more thoughts in separate messages, so they can be separate threads:

Could you please make the settings.gradle.kts and gradlew etc. optional, so you can really start with just a module.yaml and an src folder? This might require auto-adjusting the RAM limits, so we wouldn’t even need a gradle.properties file. 🙂

Compiling multiple products from a single module is impossible. E.g.

macos/app

and

linux/app

could be built from the same module, but currently I have to create separate modules instead. Maybe the solution is to merge the

macos/app

and

linux/app

products into a

native/app

type. Similarly, the planned

windows/dll

and

linux/so

etc. somehow overlap with

lib

and publication definitions (e.g. Cocoapods). Something about this solution isn’t quite right yet.

Creating a lib that targets all platforms seemed to be impossible:

product:
  type: lib
  platforms: [android, iosArm64, iosSimulatorArm64, iosX64, jvm, linuxArm64, linuxX64, macosArm64, macosX64]

=>

Cannot create a framework: sharedDebugFramework. Binaries of this kind are not available for target linuxArm64

Also, for libs I see two special use-cases: For many published (e.g. open-source)

lib

projects it might be possible to build for absolutely all targets that Kotlin supports. Can’t we have an

all

platform, maybe with an

exclude

option? And similarly,

ios

and

macos

etc. platform shortcuts. Breaking changes about the meaning of those shortcuts would be expected and absolutely OK. So if

iosSimulatorArm64

gets added to

ios

later, that really is the desired behavior. I’d rather always attempt to build for the full set of platforms than forget some platform. Especially if my lib only relies on the stdlib (e.g. because it’s a Base64 implementation or a MIME types DB or an XML parser or …). Having to explicitly list all targets is bad for the open-source library ecosystem and it’s really only necessary when your lib contains platform-specific code. Such libs can still maintain an explicit list of supported platforms, but ideally exclusion-based, so when new platforms get supported the developers notice that by default without having to read the Kotlin “What’s new” section.

Similarly, an

auto

(or

only-necessary

?) platform for

lib

modules which aren’t published, but only used within the same repo as internal dependencies could be useful. That

auto

platform would auto-adjust based on what the final binaries need. If there are

macos/app

and

android

and

ios

modules which depend on the same shared

lib

then this lib would automatically be built for those platforms. No need to even list any platforms, at all. This

auto

value could even be the default, but as soon as you add a

publish

definition for Maven you’d have to explicitly choose between

all

or an explicit list of platforms (hopefully with

ios

etc. shortcuts).

Finally, it should be possible to set the default list of lib platforms in the root build script instead of having to repeat that list in every module. Like suggested in the announcement thread, the root build script should be the preferred place for many configuration options. Per-module configs should ideally be the exception.

JetBrains has joined this channel by invitation from kotlinlang.

has renamed the channel from "amper-ext" to "ext-kotlin-amper"

Hi, congrats for Amper announcement. I would like to provide my feedback, as I have a strong hope that something else than Yaml could be used in the future for a wide range of reasons (version numbers and collections would be very error prone, weak support for schemas, etc.). That said, I am perfectly aware it is hard to find the right format. For now, TOML and a subset of Kotlin are my 2 preferred options, see this Reddit discussion and this conversation with Cédric Champeau. If you provide non-JVM tooling (via Kotlin Native or GraalVM), first class schema support and choose a catchy name and file extension, the subset of Kotlin could be pretty successful IMO even outside of the JVM world, because we see there is no straightforward answer to this need yet and the syntax of Kotlin DSL + data classes is pretty appealing. So it could potentially be a gateway to Kotlin for various developers. And the fact it could be a subset of "Kotlin with DSL style of code" could be pretty appealing, with a lot of use cases, including in Spring. Also be able to "share the knowledge" between "Kotlin Properties" and "Kotlin Code" would be nice. Without proper specs, I would love to see a Rust implementation usable with Wasm projects for example. BTW if you choose a subset of Kotlin, IMO the name should not be "Kotlin Something" (too Kotlin specific), but could start by a K. The ambition should be IMO to make this format appealing outside JetBrains/Gradle/JVM/Kotlin world. Any thoughts?

The tutorial on https://github.com/JetBrains/amper/blob/main/docs/Tutorial.md is a bit incomplete in parts. Some I noticed: • It says to copy

settings.gradle.kts

and the

/gradle

folder. However, without

gradlew (.bat)

, not much is going to happen. • It doesn't once mention how to run it (

gradlew run

). That's described on

Usage.md

but a tutorial should be a bit more complete • In step 7, the "new file layout" shows

android-app/src/main.kt

but that should be

android-app/src/MainActivity.kt

. It's correct in the linked full example code. It's nice how every step in the tutorial links to a working full example 👌🏼.

First impression after trying: not bad, pretty cool. Really like how it gets even simpler to configure a multiplatform project. Followed the tutorial, set up

shared

module +

app-android

and

app-desktop

. Both work, but Fleet isn't happy with the Android code. Not sure if this should be in the #fleet channel instead. Using Fleet 1.26 (Nov. 7) on Windows 11. Errors remain after syncing & reloading workspace. No issues with the desktop code.

@aleksandr.syplivchak has left the channel

Since all of the sample projects in the repo are trivially simple, maybe it could help in the design phase to also think of a more complex real-world use-case. At least, this build system topic has cost us so much time and left me with so many scars that I really want to see it finally solved. I even planned to create an open-source Gradle conventions plugin that solves this, but now you’re working on Amper already, so let’s use the opportunity. 😄 The following is an example similar to our project structure. Here you have several SDKs and apps for different clients with different feature sets: • libs ◦ common (APIs useful for all SDKs and apps; possibly also published as an XCFramework and JS/WASM Node.js lib) ▪︎ base-utils ▪︎ image (APIs for manipulating JPEG, PNG, etc.) ▪︎ pdf (PDF generation) ▪︎ xml (XML parsing) ▪︎ … ◦ foo-sdk (an SDK also published as XCFramework and JS/WASM Node.js lib) ▪︎ core ▪︎ notification ▪︎ profile ▪︎ … ◦ bar-sdk (SDK with XCFramework etc.) ▪︎ … ◦ … (other SDKs, possibly even depending on foo-sdk and bar-sdk) ◦ ui (the reusable UI library) ▪︎ core ▪︎ navigation ▪︎ foo (base UI for foo-sdk) ▪︎ whitelabel-flavor-xyz (a whole reusable app flavor, integrating foo, navigation, login/registration flow etc.) ▪︎ … • apps (Android, iOS, desktop - where some iOS and desktop apps could use a native or Electron UI while others could use Compose) ◦ client-a ▪︎ base (the main app code, building on top of whitelabel-flavor-xyz) ▪︎ app-prod (uses base and just configures the backend URL and other settings) ▪︎ app-dev-env ▪︎ app-test-env ▪︎ … ◦ client-b ▪︎ base (main app code, combining ui/foo and some bar-sdk features in a much more custom way, so whitelabel-flavor-xyz can’t be reused) ▪︎ … ◦ … • backends (reusing some of the

libs/*

APIs) ◦ … Either you develop the app for the client or they build it and integrate either your logic SDKs or ViewModels or your themable UI (or some combination). EDIT: For SDKs it’s important to have a simple way to expose the whole API, similar to the way it works on JVM with just public vs. private. The current JS/WASM export annotations are too painful and the XCFramework

export

build configs are also quite repetitive and error-prone when working with multiple SDKs and many modules. Let’s say there are 100+ modules overall. You need linting, Sonarqube, dependency update and security checks, snapshot and unit tests and code coverage, version consistency (e.g. BOM), API docs with real text and examples (not just Dokka-generated references, but more like Kotlin's docs), assets and translations (at

libs/*-sdk

,

libs/ui

and

apps/*

level, also overriding/customizing values from lower-level modules). Some consumers of your SDKs are allowed to see the source code, others only get the binaries - ideally with integrated API docs. Thus you’d want to keep the configuration as centralized as possible. Settings should ideally be transitive (e.g. iOS pods, webpack customizations, kotlinx.serialization, etc.). They should also be applied from the root and match on certain path patterns or module properties. With too much repetition you’ll lose yourself in complexity and will have a hard time updating configs and finding out how the build system is configured and which outputs there are at all (your different XCFrameworks, apps, etc.). Ideally you don’t have to look at 30 module.yaml files to understand which artifacts get built in the project. Side-problem: Your iOS apps with native UI need to integrate one or multiple XCFrameworks. Your iOS apps are modularized, too. So if foo-sdk and bar-sdk depend on common/oauth, the the iOS app’s modules need to reuse that common/oauth API and be able to pass objects to both foo-sdk and bar-sdk. That’s a huge problem because with the current build system SDKs become separate XCFrameworks/WASM/JS libs with their own incompatible copy (!) of common/oauth. So the resulting XCFrameworks/WASM/etc. need to be built and published in a modularized way somehow and this should ideally even work across multiple repos. I hope this is a useful example for discussing Amper’s solution. Is this even a use-case Amper wants to serve? Maybe a tiny similar project in the samples would be helpful, too (I think a lot of problems in the current Gradle based build system would’ve been avoided with such a more complex example).

Hello. Congrats on Amper. I'm loving it so far! What directory should SQLdelight .SQ files go into so that the SQLdelight plugin sees them? Do you have to use the "gradle-kmp" layout option? TIA!

I just gave Amper a try! I can say that I really enjoyed setting this up, it feels so much nicer than manually setting up Gradle files. Unfortunately, beyond simple use cases, I couldn’t really get very far without running into the need for Gradle interop… Is there a way to use both a Gradle file and an Amper config file in the same module, as well as keeping the directory structure very similar to Amper’s? I’m experimenting with the possibility of testing the waters with devs on my team in an effort to make the idea of kotlin multiplatform seem more appealing with Amper

I wrote a quick amper project for some data analysis the other day, and noticed that breakpoints didn't work on jvm when running debug in fleet. Is this expected?

Amper approach towards a declarative build tool, moving away from kotlin script (and gradle) is very sound. A while ago there was a debate in the Scala community about sbt which describes a project in a subset of scala. Using a well-know DSL to describe a project will offer better tooling support. I hope that Amper will be a modern version of maven (minus the XML, and the plugins) I think that Rust's cargo should be the benchmark for Amper. Simple, fast, powerful.