search

lightbend / kalix-jvm-sdk

Java and Scala SDKs for Kalix
https://docs.kalix.io/java/index.html
Other
58 stars 39 forks source link

Too many (and confusing) import options in code-first sdk #1862

Open octonato opened 1 year ago

octonato commented 1 year ago

When building an application with the code-first SDK, a user have too many classes with the same name to import.

If, for example you want to implement an EventSourcedEntity, you get the following list of imports to choose from:

event-sourced-entity

From all this options, only kalix.javasdk.eventsourcedentity.EventSourcedEntity is correct.

The one in kalix.javasdk.annotations.Subscribe is a public one. It's used to subscribe to events produced by an event-sourced entity. Here we could eventually deprecate it and introduce something else, for example:

@Subscribe.EventsFrom(ShoppingCartEntity.class) where ShoppingCartEntity is a ES.

The classes in kalix.component, kalix, kalix.protocol, kalix.annotations.CodegenOptions, kalix.eventing could be hidden from the user using java modules. They are internal Kalix classes and should not be exposed, confuse or distract the users.

The same happens for the other types we have.

Value Entity

value-entity

Same as above, the annotation could be refactored to:

@Subscribe.StateFrom(ShoppingCartEntity.class) where ShoppingCartEntity is a VE.

Action

action

View

view

Workflow

workflow

aludwiko commented 1 year ago

Oh yes, it's frustrating even for me :)

octonato commented 7 months ago

I didn't know that, but scalac doesn't support JPMS, meaning that we are out of options for now.