Command implementation as part of public API

[heiko.braun]

IMO any command should be part of the public AIP and not reside in a '**/internal/' package. Currently we 'lock' them in org.jbpm.pvm.internal.cmd.

[camunda]

Hi Heiko.

But then we should introduce interfaces for every Command, or?
Maybe this is the cleanest way, even if that is a bit unhandy...

[heiko.braun]

I think the Command interface [1] is sufficient for now.

[1] http://jbpm.dyndns.org/jbpm4/jbpm-api/apidocs/org/jbpm/cmd/package-frame.html

[jbarrez]

Bernd,

I find it a bit messy to create an interface for every command ... in reality it will always be the same interface, no :p

I don't see what's wrong by exposing the Commands as they are in the public API. They all implement the same interface, so they shoud be changeable in future versions

[heiko.braun]

IMO these command implementations are a good example of "grey zone" in an API. But I don't see a reason why we shouldn't make them publicly available.

Another option would a typed interface with clear functionality.
We had this discussion quiet a while ago when I was complaining about the command pattern in place, rememeber? There is actually no difference between a typed interface with specific scope and an untyped interface (Command) with scoped implementations. The later is what we currently encounter.

[camunda]

Wait a second: The one Command-Interface goes in the API or all Command-Implementations?

The first: Sure!
The second: Isn't that code already implementation specific?

And yes, I agree, an additional interface for every command is NOT my vote as well.

[heiko.braun]

The second: Isn't that code already implementation specific?

Yes it is. But it's very likely that people will work with those commands. And if we publish the CommandExecutor (i.e. EJB) then we need to give ammunition to it as well, don't you think? Hence my question in the first place.

[camunda]

In principal: +1. But I haven't looked into the dependencies yet it that can cause trouble...