Activiti version numbering

[briantopping]

As I started integrating Activiti to my project, I was happy to find the IdentityService interface and easily integrated a stubbed implementation via Spring, with breakpoints to dynamically view usages.  So far, so good. 

After running my test framework, I was surprised to find that none of the methods were reached. 

After finding usages in my IDE, I find that the implementation is instantiated but never used.  Oops!

This is a bit of a challenge to find that such an important SPI is unused in software that is "beta".  I know there is some marketing here, but calling software that is at this stage "beta" is in direct contradiction with the mission of the project: "to make Business Process Management (BPM) ubiquitous by offering solutions that both business people and developers love".

Speaking as a developer, Activiti looks great and this isn't going to stop me from using it, but this situation makes me very uneasy.  In the past, we used to use the categorization of "alpha" for software that had final API/SPIs, and "beta" for software that had no known bugs and was just going through user acceptance testing and baking.  I had inadvertently thought when I started looking to use Activiti (software that calls itself "5.0" and "beta") that I was looking at a very stable and finished system, now it appears that I have a lot of work ahead of me to get it integrated with my system, and no idea whether I'm going to run into another similar roadblock in the future.

What do you guys think about this?  This isn't to throw cold water on the project, your team has done a commendable job in a difficult and much-needed problem space.  But there's definitely going to need to be some work toward how releases are communicated!  🙂

Cheers, Brian

[tombaeyens]

IdentityService is our identity API.  Should be used in our test suite.
IdentitySession is our identity SPI.  That is the interface for which we would very much like to have a Spring Security binding.

Since we are pressed in time, we focus on API first.  That should be stable.  SPI's are not yet considered stable.  Good point that we should document that better.

Some background that might help understand Activiti identity approach:  Internally in our own runtime engine persistence, we only store userId references as String's.  That is exactly to enable easy pluggability of the IdentitySession.  Not all bindings will have all the features that might be exposed in the full IdentitySession.  So our impl uses the IdentitySession for very specific functions and as minimal as possible.  This makes it easy to start implementing a basic binding with e.g. Spring Security.  You can use most of Activiti by just implementing the basic IdentitySession methods.  Only for the specific features, other method implementations will be used.

You should start plugging the IdentitySession by building a ProcessEngineConfiguration programmatically.  Then supply a different implementation for the IdentitySessionFactory in the sessionFactories property.  Keep us posted.