+1 for 1a +1 for 2a Having separate project would help app developers for better dependency management.
~ Yogi On 4 March 2016 at 05:59, Vlad Rozov <[email protected]> wrote: > +1 for 1a. > > Vlad > > > On 3/3/16 11:37, Chinmay Kolhatkar wrote: > >> +1 for 1a. >> On 4 Mar 2016 12:26 a.m., "Thomas Weise" <[email protected]> wrote: >> >> +1 for 1a (same package with operators). >>> >>> Furthermore, there has been already a discussion on how we over time want >>> to break up contrib, and the Kafka operator is an existing example. >>> >>> Thomas >>> >>> On Thu, Mar 3, 2016 at 9:01 AM, Amol Kekre <[email protected]> wrote: >>> >>> IMHO the choice is between packages being "functional" or "java >>>> >>> construct" >>> >>>> based? Do users look for functionality or java constructs? My view is >>>> >>> that >>> >>>> users will overwhelmingly look for functionality. The search will be >>>> "How >>>> do I do ...". If so the organization should be functional. The case >>>> >>> where a >>> >>>> module has both input and output operators may in most cases >>>> >>> automatically >>> >>>> land up in different functional bucket (aka package). That translates to >>>> 1a. >>>> >>>> With regards to contrib, similar flow should work, but it may have >>>> issues >>>> due to cross dependencies, license and may need hybrid model. >>>> >>>> Thks >>>> Amol >>>> >>>> On Thu, Mar 3, 2016 at 8:54 AM, Sandesh Hegde <[email protected]> >>>> wrote: >>>> >>>> 1. 1.b Modules in the separate package. >>>>> >>>>> Reasons: >>>>> - It makes it for us to educate app developers, by saying >>>>> "Start with modules then operators and then custom >>>>> operators" >>>>> - Modules can contain different operators (say input as >>>>> well >>>>> >>>> as >>>> >>>>> output ) and other modules, so what is the right place for that ? >>>>> - Reduce the namespace bloating >>>>> >>>>> 2. Hybrid of 2-a and 2-b. >>>>> >>>>> >>>>> On Thu, Mar 3, 2016 at 5:11 AM Priyanka Gugale < >>>>> >>>> [email protected] >>> >>>> wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> Recently we added Modules feature in Apex platform. Using this >>>>>> >>>>> feature >>> >>>> we >>>>> >>>>>> are planning to write few modules (module is set of operators >>>>>> >>>>> connected >>> >>>> together to achieve unit of work). We would like to submit them to >>>>>> >>>>> Malhar. >>>>> >>>>>> My question is what would be the appropriate place to add these >>>>>> >>>>> modules. >>>> >>>>> Following are the options we are considering: >>>>>> >>>>>> 1. Malhar-library: If module code is not dependent on third part >>>>>> >>>>> libraries, >>>>> >>>>>> we can put the module in Malhar-library. Under Malhar library we can >>>>>> >>>>> put >>>> >>>>> them in >>>>>> a) same package as relevant operators >>>>>> b) a different package, where package name indicates it's a >>>>>> >>>>> module. >>> >>>> 2. Malhar-contrib: When module depends on third party libraries, we >>>>>> >>>>> can >>> >>>> put >>>>> >>>>>> them in contrib. Now in contrib, do we want to >>>>>> a) add each module as indipendent project? >>>>>> b) add module in some packages? >>>>>> >>>>>> >>>>>> I would prefer to got with 1-a and hybird of 2-a and 2-b. i.e. if >>>>>> >>>>> external >>>>> >>>>>> source versions etc changes frequently we can use 2-a. If external >>>>>> >>>>> library >>>>> >>>>>> version doesn't change frequently and is commonly used module we can >>>>>> >>>>> go >>> >>>> with 2-b. >>>>>> >>>>>> Please share your opinion. >>>>>> >>>>>> -Priyanka >>>>>> >>>>>> >
