I tend to agree with Arek on this one. It feels a good logical division to have it separate, primarily so when updates to the Azure SDK are released, a new version of this module can be released without having to update oak-blob-cloud. By that same argument it may make sense at some point to do the same thing for AWS and S3DataStore.
-MR On Wed, Mar 15, 2017 at 3:55 AM, Arek Kita <[email protected]> wrote: > Hi Amit, > > On 15/03/2017, 10:29, "[email protected] on behalf of Amit Jain" < > [email protected] on behalf of [email protected]> wrote: > > > Hi Team, > > > > There is a new contribution for azure blob storage support - OAK-4933. > > This introduces a new module oak-blob-cloud-azure. This certainly seems > to > > be the right approach from a separation and deployment standpoint. But in > > terms of code the module may only contain a few classes and also in > future > > if we introduce (on my horizon) support for jclouds we could unify all > > under one module. > > > > What is the correct thing to do here? > > I IMHO think that even if it contains a few classes, there are/there will > be for sure some external transitive dependencies that could be helpful to > have in independent deployable module. I think it should not be about how > many classes but rather how mature the code is and how frequently it will > be updated or backported (code maturity level). > > I would go with a separate module for this so you can replace it, leaving > the rest as is (possibly). > > Regrads, > Arek > >
