Re: New module oak-blob-cloud-azure?

[Amit Jain]

Hi,

Thanks!! As suggested would go for a new module oak-blob-cloud-azure.

Regards
Amit

On Thu, Mar 16, 2017 at 9:50 PM, Angela Schreiber  wrote:

> Hi Amit
>
> In the light of discussions we had recently wrt modularisation, I would
> also prefer to keep the new oak-blob-cloud-azure implementation in a
> separate module.
>
> Kind regards
> Angela
>
> On 15/03/17 10:29, "Amit Jain"  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?
> >
> >Thanks
> >Amit
>
>

Re: New module oak-blob-cloud-azure?

[Angela Schreiber]

Hi Amit

In the light of discussions we had recently wrt modularisation, I would
also prefer to keep the new oak-blob-cloud-azure implementation in a
separate module.

Kind regards
Angela

On 15/03/17 10:29, "Amit Jain"  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?
>
>Thanks
>Amit

Re: New module oak-blob-cloud-azure?

[Davide Giannella]

On 15/03/2017 09:29, Amit Jain 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?
>

Don't know about correctness but IMO it's better to separate by concerns
rather than amount of code. If it won't receive that many updates as it
contains only few classes so be it. Even if we release a new module at
every release as monolith, like we're doing now, if the it's small it's
not that bigger impact than having all the classes in one big bundle.
Actually it could be better.

If the module "depends" on oak (note the quotes please), we may even
think about adding a specific released oak version as dependency and
pull it out of the monolith release cycle (MRC). Just an idea.

D.

Re: New module oak-blob-cloud-azure?

[Matt Ryan]

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  wrote:

> Hi Amit,
>
> On 15/03/2017, 10:29, "amit@gmail.com on behalf of Amit Jain" <
> amit@gmail.com on behalf of am...@ieee.org> 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
>
>

Re: New module oak-blob-cloud-azure?

[Arek Kita]

Hi Amit,

On 15/03/2017, 10:29, "amit@gmail.com on behalf of Amit Jain" 
 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