I tend to agree with Abe-san that separation would be a net loss, unless the out-of-the-box nature of the examples could be maintained somehow.
Karl On Tue, Mar 18, 2014 at 4:39 AM, Shinichiro Abe <[email protected]>wrote: > HI, > > I don't think that separating framework and connectors is good > because voting on individual packages is time consuming and > building individual connector is too much trouble. > Users expect to use MCF binary release as OOTB. > > Regards, > Shinichiro Abe > > On 2014/03/18, at 17:10, Karl Wright <[email protected]> wrote: > > > 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 > >> > >> > >> > >
