You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by Pramod Immaneni <pr...@datatorrent.com> on 2016/02/18 01:59:00 UTC
malhar dependency in apex-app-archetype
Currently we include a dependency to malhar-library in apps generated using
apex-app-archetype. This results in a soft dependency from apex to malhar,
namely a previously released version of malhar, which is reverse of the
build dependency.
Secondly we only include malhar-library and not malhar-contrib even though
it is a component of malhar possibly because the user would still need to
include the transitive dependencies based on the application. This again
makes the out-of-box experience a little less consistent.
How about not including the malhar-library dependency in the generated
default pom.xml.
Thanks
Re: malhar dependency in apex-app-archetype
Posted by Thomas Weise <th...@datatorrent.com>.
Would also be good to transform the test into a more meaningful piece that
checks actual results.
On Wed, Feb 17, 2016 at 5:27 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:
> Comments sounds good.
>
> On Wed, Feb 17, 2016 at 5:12 PM, David Yan <da...@datatorrent.com> wrote:
>
> > I think it's a good idea. We can add comments to the generated pom to
> > explain to the user that he/she may want to add malhar-library and/or
> other
> > libraries in malhar like contrib or kafka, depending on the use case,
> > instead of adding malhar-library dependency by default for the user.
> >
> > David
> >
> > On Wed, Feb 17, 2016 at 4:59 PM, Pramod Immaneni <pramod@datatorrent.com
> >
> > wrote:
> >
> > > Currently we include a dependency to malhar-library in apps generated
> > using
> > > apex-app-archetype. This results in a soft dependency from apex to
> > malhar,
> > > namely a previously released version of malhar, which is reverse of the
> > > build dependency.
> > >
> > > Secondly we only include malhar-library and not malhar-contrib even
> > though
> > > it is a component of malhar possibly because the user would still need
> to
> > > include the transitive dependencies based on the application. This
> again
> > > makes the out-of-box experience a little less consistent.
> > >
> > > How about not including the malhar-library dependency in the generated
> > > default pom.xml.
> > >
> > > Thanks
> > >
> >
>
Re: malhar dependency in apex-app-archetype
Posted by Pramod Immaneni <pr...@datatorrent.com>.
Comments sounds good.
On Wed, Feb 17, 2016 at 5:12 PM, David Yan <da...@datatorrent.com> wrote:
> I think it's a good idea. We can add comments to the generated pom to
> explain to the user that he/she may want to add malhar-library and/or other
> libraries in malhar like contrib or kafka, depending on the use case,
> instead of adding malhar-library dependency by default for the user.
>
> David
>
> On Wed, Feb 17, 2016 at 4:59 PM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > Currently we include a dependency to malhar-library in apps generated
> using
> > apex-app-archetype. This results in a soft dependency from apex to
> malhar,
> > namely a previously released version of malhar, which is reverse of the
> > build dependency.
> >
> > Secondly we only include malhar-library and not malhar-contrib even
> though
> > it is a component of malhar possibly because the user would still need to
> > include the transitive dependencies based on the application. This again
> > makes the out-of-box experience a little less consistent.
> >
> > How about not including the malhar-library dependency in the generated
> > default pom.xml.
> >
> > Thanks
> >
>
Re: malhar dependency in apex-app-archetype
Posted by David Yan <da...@datatorrent.com>.
I think it's a good idea. We can add comments to the generated pom to
explain to the user that he/she may want to add malhar-library and/or other
libraries in malhar like contrib or kafka, depending on the use case,
instead of adding malhar-library dependency by default for the user.
David
On Wed, Feb 17, 2016 at 4:59 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:
> Currently we include a dependency to malhar-library in apps generated using
> apex-app-archetype. This results in a soft dependency from apex to malhar,
> namely a previously released version of malhar, which is reverse of the
> build dependency.
>
> Secondly we only include malhar-library and not malhar-contrib even though
> it is a component of malhar possibly because the user would still need to
> include the transitive dependencies based on the application. This again
> makes the out-of-box experience a little less consistent.
>
> How about not including the malhar-library dependency in the generated
> default pom.xml.
>
> Thanks
>