Basically everything in lib/occiantlr and lib/occi, except lib/occi/api and lib/occi/bin.
Everything else; bin, examples, ext, config, lib/occi/api and lib/occi/bin.
Gem: occi or occi-client
Pros and Cons? What do you think?
That sounds like a good idea. I would like to get rid of occiantlr before (as mentioned in #55). The split is a good target for rOCCI 4.0.
I like this idea too :-). Can we extend the idea with the following:
rOCCI-infrastructure (extension of the idea)
is rOCCI-infrastructure overhead or can we use it to easy extend rocci with new features like rocci-plattform or rocci-service? What do you think?
Are there any (core) changes you haven't committed yet that I should wait for before starting the refactoring process?
I am currently working on Core changes to Attributes and Actions and I would suggest to include the Settings class from #46 in rOCCI core. I don't see the changes blocking the split. You may go ahead and separate the code and I will commit the changes (50% done) in the next week into rOCCI-core. I would also suggest to include all changes and updates to the spec tests before we tag rOCCI core as 4.0 and build everything else on top of rOCCI 4.0.