Hi,
Now you can use activiti with and without spring. And that is good.
But we see a potential problem popping up. There are now 2 styles of configuration: activiti cfg xml and the spring configuration. Up to now there was good reason for this split up. As the things that we have configurable are very different (transaction/datasource stuff) in both scenarios.
But now we're starting to work out more configurable aspects and we realize that we'll have a ton of extra configuration items which don't need to be different. Like engine variable types, form types, business calendar etc. And the way we're going now, we'll have to work out parsing for those 2 environments separate and document that separate. That is a bad choice we think.
So I'll be trying out a new strategy. The reasoning is that we'll distinct between a dependency on spring for the configuration and a dependency on spring's transaction management. The idea is that we'll refactor the ProcessEngineBuilder to use the spring bean xml configuration parsing. That way of configuring would not use the spring transaction integration or the other spring integrations.
The advantage is that all the non-tx-related configurations would only have to be implemented once and documented once. And that will lead to less confusing documentation and usage of the engine.
The downside could be that we introduce a dependency from the activiti engine to spring-core for parsing of the configuration file. I'm thinking of making that parsing pluggable in case people would really object against that dependency. In that case, contributors could write a spring-bean-xml-parser in activiti to avoid that dependency. Imo, i can live with a dependency on spring core for parsing the config.
I want to stress that this would not create a full dependency on the spring style of doing things. It's just for parsing the config.
Does anyone see a problem with this approach?
I'll be starting to code a prototype now and hopefully later today we'll all be able to review it.
