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

[octonato]

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:

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

Same as above, the annotation could be refactored to:

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

Action

View

Workflow

[aludwiko]

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

[octonato]

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