I've created a ticket, CONNECTORS-912, to describe a way that we can reorganize the build files to make everyone happy. I think. Anyway, although I've triaged it for 1.6, there's quite a good chance it won't land until later; we'll see.
For Abe-san: The proposal would retain MCF's out-of-the-box capabilities exactly as they are today. For Graeme: The proposal, if I can actually implement it, would allow developers to maintain their own connectors, build them, and integrate them into the examples, by simply referencing a MCF binary distribution. Karl On Tue, Mar 18, 2014 at 7:29 AM, Karl Wright <[email protected]> wrote: > 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 >> >> >> >> >> >> >> >> >
