Regardless of how one feels about complete separation of framework and connectors, it occurs to me that there may be helpful build-system measures that could be done which would be good for people developing their own connectors outside of our release process. I *tried* to set it up this way initially, but it's short of that goal right now for a couple of reasons:
- The main build.xml file is too hard-wired; it should just basically handle dependency downloads, packaging, rat-sources, and list the connectors and the tests, and all the targets should be autogenerated given that - Individual connector builds do not currently include any packaging or example installation targets; moving this down to the connector level would mean you could in theory develop your own connectors with a shipping binary MCF release, although obviously the binary release would also need to change to include ant build infrastructure as well if that was going to work Thoughts on this idea? Should we put effort into pursuing it? Karl On Tue, Mar 18, 2014 at 3:56 AM, Karl Wright <[email protected]> wrote: > Hi all, > > Graeme raised the question of whether we should try to separate framework > and connectors into separate releases. I'm creating a new thread for > discussion of that proposal. > > To summarize the proposal, we'd have a separate release cycle for the > framework and each of the connectors. > > The benefits: > > - Much easier to incorporate new connectors into the project > - Lots of small releases rather than one big one > - A new connector release would not necessarily be needed for every major > framework release (although we may well want to do it as a matter of policy > in any case -- see the technical note below) > > The downsides: > > - Framework tests that don't require actual shipping connectors to > exercise framework features are almost non-existent > - Getting a voting quorum to release a new revision of a connector that is > lightly used might be a significant challenge > - It becomes much harder to make global changes that extend the connector > APIs, because there may well be a dozen votes or more as a result > - Deployment is far more difficult; you'd effectively need an installer > for each connector package that you'd run to install it into the > example(s)(?). All the examples would need to change fundamentally as a > result, as would the documentation. > > ** The technical complication is that for connectors we've made much use > of the interface/abstract base class metaphor to keep backwards > compatibility for connector methods. This works fine IF you rebuild your > connector every time the base class changes, but if you don't you will > likely get linkage errors when you run. So, we reasonably should expect to > rerelease all connectors on every framework release anyhow. > > Thoughts? > > Karl > > >
