It will be consistent but there is something to be said about preserving some history in the present where it allows itself. On Sat, Aug 19, 2017 at 11:05 AM Vlad Rozov <vro...@apache.org> wrote:
> Yes, consistency. > > Thank you, > > Vlad > > On 8/19/17 10:57, Pramod Immaneni wrote: > > Is there any significant gain by doing this? > > > > Thanks > > > > On Sat, Aug 19, 2017 at 10:36 AM, Vlad Rozov <vro...@apache.org> wrote: > > > >> The parent level pom artifact Id is not referenced by applications, it > >> exists simply to group modules together under current malhar project. > The > >> name can be changed to library-parent(root) or > apex-library-parent(root) or > >> something similar. Note that the proposal includes rename of the project > >> from apex-malhar to apex-library along with the version change. > >> > >> Thank you, > >> > >> Vlad > >> > >> > >> On 8/19/17 10:10, Pramod Immaneni wrote: > >> > >>> Would library module then become apex-library-library? Why change the > >>> malhar artifact id as the project is called apex-malhar. > >>> > >>> Thanks > >>> > >>> On Sat, Aug 19, 2017 at 10:03 AM, Vlad Rozov <vro...@apache.org> > wrote: > >>> > >>> Overall I support the proposal and this is what I was in favor of > during > >>>> the last discussion. I'd also propose changing the name of the > artifact > >>>> id > >>>> and git repo from malhar to apex-library as part of the major version > >>>> change. It will make it more consistent with the entire project and > will > >>>> also allow using 1.0 (1.0-SNAPSHOT) version that more closely reflects > >>>> maturity of the library. > >>>> > >>>> Thank you, > >>>> > >>>> Vlad > >>>> > >>>> On 8/18/17 17:04, Thomas Weise wrote: > >>>> > >>>> The proposed change does NOT require changes to existing apps. It > follows > >>>>> what you see for example in the JDK where older classes are retired > >>>>> without > >>>>> making breaking major release changes. > >>>>> > >>>>> Even though not required technically, it looks like the preference > is to > >>>>> make this change with a 4.0 release. I will therefore propose to > change > >>>>> the > >>>>> master branch to 4.0-SNAPSHOT and make this and other changes deemed > >>>>> worthwhile. > >>>>> > >>>>> To me it is more important that to newcomers the codebase does not > look > >>>>> like an outdated legacy situation and therefore if I have to make a > >>>>> choice > >>>>> than pretty much any version number will do for that. So far I have > seen > >>>>> very little interest and initiative in addressing maintenance work > like > >>>>> the > >>>>> packages, checkstyle, CI stability, documentation etc. So it would be > >>>>> great > >>>>> if people interested would step up and contribute. > >>>>> > >>>>> Here is the next proposal how to proceed: > >>>>> > >>>>> - create release-3.8 branch for last 3.8 release right away > >>>>> - update master to 4.0-SNAPSHOT as part of the open PR #664 > >>>>> - identify further cleanup work for master > >>>>> - release 4.0 > >>>>> > >>>>> Thanks, > >>>>> Thomas > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Aug 17, 2017 at 4:48 PM, Amol Kekre <a...@datatorrent.com> > >>>>> wrote: > >>>>> > >>>>> This following pull request should be taken up in 4.0.0. See my > comments > >>>>> > >>>>>> in > >>>>>> https://github.com/apache/apex-malhar/pull/664 > >>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com% > >>>>>> 2Fapache%2Fapex-malhar%2Fpull%2F664&sa=D&ust=1503020269444000&usg= > >>>>>> AFQjCNHDPZIg2e6I33Jb1XjB5Ir1FkdURQ> > >>>>>> https://github.com/apache/apex-malhar/pull/662 > >>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com% > >>>>>> 2Fapache%2Fapex-malhar%2Fpull%2F662&sa=D&ust=1503020269444000&usg= > >>>>>> AFQjCNF7Xde7X55M3qmc8z-D5y3ZwNg7Fg> > >>>>>> > >>>>>> This merge should not be done without a consensus. This will require > >>>>>> code > >>>>>> changes to existing apps. > >>>>>> > >>>>>> Thks, > >>>>>> Amol > >>>>>> > >>>>>> > >>>>>> > >>>>>> E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* > >>>>>> > >>>>>> www.datatorrent.com > >>>>>> > >>>>>> > >>>>>> On Mon, Aug 14, 2017 at 7:48 PM, Thomas Weise <t...@apache.org> > wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>>> I opened following PRs for the package change: > >>>>>>> > >>>>>>> https://github.com/apache/apex-malhar/pull/662 > >>>>>>> > >>>>>>> Moves all classes with history retained (hence 2 commits). Also > >>>>>>> contains > >>>>>>> checkstyle and other mechanical changes. > >>>>>>> > >>>>>>> https://github.com/apache/apex-malhar/pull/664 > >>>>>>> > >>>>>>> Adds backward compatibility jar. > >>>>>>> > >>>>>>> Once above PRs are merged the new artifact can be deployed and > >>>>>>> introduced > >>>>>>> as dependency in malhar-library. > >>>>>>> > >>>>>>> Please review. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Thomas > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Sun, Jul 16, 2017 at 7:04 AM, Thomas Weise <t...@apache.org> > wrote: > >>>>>>> > >>>>>>> My original list of work items contained the b/w compatibility > aspect, > >>>>>>> I > >>>>>>> don't think there should be any confusion of whether it will be > >>>>>>> covered > >>>>>>> > >>>>>>>> here or not. > >>>>>>>> > >>>>>>>> The proposed shading will provide the old classes and they will be > >>>>>>>> > >>>>>>>> frozen > >>>>>>> as of release 3.7. That's the same as making a copy of the code and > >>>>>>> never > >>>>>>> again making changes to the original classes. This cannot be > >>>>>>> accomplished > >>>>>>> by using the older 3.7 release in your project because you cannot > use > >>>>>>> 2 > >>>>>>> > >>>>>>>> different versions of Malhar in parallel unless you apply shading. > >>>>>>>> > >>>>>>>> The shaded artifact will only expose the com.datatorrent classes, > and > >>>>>>>> > >>>>>>>> they > >>>>>>> will be self-contained as the rest of the classes that they may > depend > >>>>>>>> on > >>>>>>> are shaded. The shaded artifact does not evolve, there are not more > >>>>>>> changes > >>>>>>> > >>>>>>> to com.datatorrent classes after they are relocated in master. > >>>>>>>> Thanks, > >>>>>>>> Thomas > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sun, Jul 16, 2017 at 2:00 AM, Pramod Immaneni < > >>>>>>>> > >>>>>>>> pra...@datatorrent.com > >>>>>>> wrote: > >>>>>>> > >>>>>>>> I don't think we can limit the topic strictly to relocation > without > >>>>>>>> having > >>>>>>>> a good b/w compatibility story or at least one that goes far > enough. > >>>>>>>> > >>>>>>>>> The shading idea sounds interesting. Why not let the shaded > version > >>>>>>>>> > >>>>>>>>> move > >>>>>>> forward with each release till we hit a major release. If it is > going > >>>>>>> > >>>>>>>> to > >>>>>>>> > >>>>>>> remain pegged at 3.7.0, why shade in the first place as the regular > >>>>>>> > >>>>>>>> 3.7.0 > >>>>>>>> release would do the same job and it would be same as the loss of > b/w > >>>>>>>> > >>>>>>>>> compatibility with newer releases. > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>> On Sat, Jul 15, 2017 at 7:57 AM, Thomas Weise <t...@apache.org> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Discussing what in the future might become stable needs to be a > >>>>>>>>> separate > >>>>>>>>> > >>>>>>>> thread, it will be a much bigger discussion. > >>>>>>>> > >>>>>>>>> The topic here is to relocate the packages. With a few exceptions > >>>>>>>>>> relocation won't affect the semantic versioning. Semantic > >>>>>>>>>> versioning > >>>>>>>>>> > >>>>>>>>>> is > >>>>>>>> essentially not effective for Malhar because almost everything is > >>>>>>>> > >>>>>>>>> @Evolving > >>>>>>>>> > >>>>>>>>> (and there are reasons for that.. -> separate topic) > >>>>>>>>>> I don't really like the idea of creating bw compatibility stubs > for > >>>>>>>>>> > >>>>>>>>>> the > >>>>>>>> follow up PR. It creates even more clutter in the source tree than > >>>>>>>> > >>>>>>>>> there > >>>>>>>>> > >>>>>>>> already is and so here is an alternative suggestion: > >>>>>>>> > >>>>>>>>> https://github.com/tweise/apex-malhar/blob/malhar37- > >>>>>>>>>> compat/shaded-malhar37/pom.xml > >>>>>>>>>> > >>>>>>>>>> Create a shaded artifact that provides the old com.datatorrent.* > >>>>>>>>>> > >>>>>>>>>> classes as > >>>>>>>>> of release 3.7. Users can include that artifact if they don't > want > >>>>>>>>>> to > >>>>>>>> change import statements. At the same time they have an incentive > to > >>>>>>>> switch > >>>>>>>>> to the relocated classes to take advantage of bug fixes and new > >>>>>>>>>> functionality. > >>>>>>>>>> > >>>>>>>>>> I will work on the first PR that does the relocate. In the > >>>>>>>>>> meantime, > >>>>>>>>>> > >>>>>>>>>> we > >>>>>>>> can > >>>>>>>> > >>>>>>>>> finalize what backward compatibility support we want to provide > and > >>>>>>>>>> how. > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>>> Thomas > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, Jul 14, 2017 at 11:33 AM, Pramod Immaneni < > >>>>>>>>>> > >>>>>>>>>> pra...@datatorrent.com> > >>>>>>>>> wrote: > >>>>>>>>>> How about coming up with a list of @Evolving operators that we > >>>>>>>>>> would > >>>>>>>>>> > >>>>>>>>> like > >>>>>>>> to see in the eventual stable list and move those along with the > >>>>>>>>>> not > >>>>>>>>>> > >>>>>>>>> @Evolving ones in org.apache.apex with b/w stubs and leave the > >>>>>>>> rest > >>>>>>>>> as > >>>>>>> they > >>>>>>>>> are. Then have a follow up JIRA for the rest to be moved over to > >>>>>>>>>>> contrib > >>>>>>>>>> and be deprecated. > >>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> > >>>>>>>>>>> On Fri, Jul 14, 2017 at 10:37 AM, Thomas Weise < > >>>>>>>>>>> > >>>>>>>>>>> thomas.we...@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> We need to keep the discussion here on topic, if other things > >>>>>>>>>>> are > >>>>>>>>>>> > >>>>>>>>>> piled > >>>>>>>> on > >>>>>>>>>>> top then nothing gets done. > >>>>>>>>>>>> Most operators today are not stable, they are @Evolving. So > >>>>>>>>>>>> > >>>>>>>>>>>> perhaps > >>>>>>>>>> it > >>>>>>>>> is > >>>>>>>>>> necessary to have a separate discussion about that, outside of > >>>>>>>>>>> this > >>>>>>>>>>> > >>>>>>>>>> thread. > >>>>>>>>> My guess is that there are only a few operators that we could > >>>>>>>>>>>> declare > >>>>>>>>>> stable. Specifically, under contrib the closest one might have > >>>>>>>>>> > >>>>>>>>>>> been > >>>>>>>>>>> > >>>>>>>>>> Kafka, > >>>>>>>>> but that is already superseded by the newer versions. > >>>>>>>>>>>> Thomas > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Fri, Jul 14, 2017 at 10:21 AM, Pramod Immaneni < > >>>>>>>>>>>> > >>>>>>>>>>>> pra...@datatorrent.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> We had a discussion a while back, agreed to relegate > >>>>>>>>>>>> non-stable > >>>>>>>>>>>> > >>>>>>>>>>> and > >>>>>>>> experimental operators to contrib and also added this to > >>>>>>>>>>> contribution > >>>>>>>>>>> guidelines. We aexecuted on this and cleaned up the repo by > >>>>>>>>>>> moving > >>>>>>>>>>> operators deemed non-suitable for production use at that time > >>>>>>>>> to > >>>>>>>>>>> contrib. > >>>>>>>> So I wouldn't say the operators that are at the top level > >>>>>>>>>>>> today > >>>>>>>>>>>> > >>>>>>>>>>> or > >>>>>>> the > >>>>>>>>> ones > >>>>>>>>>>>> in library are 0.x.x quality. Granted, we may need to do one > >>>>>>>>>>>>> more > >>>>>>>>>>> pass > >>>>>>>>> as > >>>>>>>>>>> some of the operators may no longer be considered the right > >>>>>>>>>>>> implementations > >>>>>>>>>>>> > >>>>>>>>>>>> with the advent of the windowed operator. > >>>>>>>>>>>>> Since contrib used to be the place that housed operators that > >>>>>>>>>>>>> > >>>>>>>>>>>>> required > >>>>>>>>>>> third party libraries, there are some production quality > >>>>>>>>>>> > >>>>>>>>>>>> operators in > >>>>>>>>>>>> > >>>>>>>>>>> there > >>>>>>>>>>> that need to be pulled out into top level modules. > >>>>>>>>>>>>> I think we are in agreement that for operators that we > >>>>>>>>>>>>> > >>>>>>>>>>>>> consider > >>>>>>>>>>> stable, > >>>>>>>> we > >>>>>>>>>>>> should provide a b/w stub. I would add that we strongly > >>>>>>>>>>>>> consider > >>>>>>>>>>> creating > >>>>>>>> the org.apache.apex counterparts of any stable operators that > >>>>>>>>>>>> are > >>>>>>>>>>>> > >>>>>>>>>>> in > >>>>>>>>> contrib out in top level modules and have the com.datatorrent > >>>>>>>>>>> stubs > >>>>>>>>>>> in > >>>>>>>>>> contrib. > >>>>>>>>>>>> For the operators not considered stable, I would prefer we > >>>>>>>>>>>>> either > >>>>>>>>>>> leave > >>>>>>>>> the > >>>>>>>>>>>> current package path as is or if we change the package path > >>>>>>>>>>>>> then > >>>>>>>>>>> create > >>>>>>>> the > >>>>>>>>>>>> b/w stub as I am not sure how widely they are in use (so, in > >>>>>>>>>>>>> essence, > >>>>>>>>>>> preserve semantic versioning). It would be good if there is a > >>>>>>>>>>> followup > >>>>>>>>>>> JIRA > >>>>>>>>>>> > >>>>>>>>>>>> that takes a look at what other operators can be moved to > >>>>>>>>>>>>> contrib > >>>>>>>>>>> with > >>>>>>>>> the > >>>>>>>>>>>> advent of the newer frameworks and understanding. > >>>>>>>>>>>>> Thanks > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Fri, Jul 14, 2017 at 9:44 AM, Thomas Weise < > t...@apache.org > >>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>> Most of the operators evolve, as is quite clearly indicated > >>>>>>>>>>> > >>>>>>>>>>>> by > >>>>>>>>>>>> @Evolving > >>>>>>>> annotations. So while perhaps 0.x.x would be a more > >>>>>>>>>>>>> appropriate > >>>>>>>>>>>>> > >>>>>>>>>>>> version > >>>>>>>>> number, I don't think you can change that. > >>>>>>>>>>>>> Thomas > >>>>>>>>>>>>>> On Fri, Jul 14, 2017 at 9:35 AM, Vlad Rozov < > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> v.ro...@datatorrent.com > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> If entire library is not stable, its version should be > >>>>>>>>>>>>>> 0.x.x > >>>>>>>>>>>>>> > >>>>>>>>>>>>> and > >>>>>>>> there > >>>>>>>>>>> should not be any semantic versioning enabled or implied. > >>>>>>>>>>>>>> It > >>>>>>>>>>>>>> > >>>>>>>>>>>>> evolves. > >>>>>>>> If > >>>>>>>>>>>>> some operators are stable as 3.8.x version suggests, the > >>>>>>>>>>>>>> library > >>>>>>>>>>>>>> > >>>>>>>>>>>>> should > >>>>>>>>>>> follow semantic versioning and it is not OK to make a > >>>>>>>>>>>>>> major > >>>>>>>>>>>>>> > >>>>>>>>>>>>> change > >>>>>>>> that > >>>>>>>>>>>> breaks semantic versioning across the entire library. It > >>>>>>>>>>>>>> is > >>>>>>>>>>>>>> > >>>>>>>>>>>>> not a > >>>>>>>> finding > >>>>>>>>>>> an excuse not to make a change. For me semantic versioning > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>> > >>>>>>>>>>>>> backward > >>>>>>>>> compatibility is more important than a proper package > >>>>>>>>>>>>>> name. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you, > >>>>>>>> Vlad > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 7/14/17 09:11, Thomas Weise wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Semantic versioning makes sense when you have a stable > >>>>>>>>>>>>>>> baseline. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> As > >>>>>>>>>>> long > >>>>>>>>>>>>> as > >>>>>>>>>>>>>>> frequent fixes need to be made to address basic issues, > >>>>>>>>>>>>>>>> it > >>>>>>>>>>>>>> makes > >>>>>>>> no > >>>>>>>>>>> sense > >>>>>>>>>>>>> to declare operators stable, which is why they are marked > >>>>>>>>>>>>>>> evolving. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> Instead of finding reasons to avoid changes that should > >>>>>>>>>>>>> have > >>>>>>>>>>>>>> been > >>>>>>>>> made a > >>>>>>>>>>>> long time ago, why not discuss what a "stable operator" > >>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> and > >>>>>>>> which > >>>>>>>>>>> ones > >>>>>>>>>>>>> deserve to be in that category. Those are the ones that > >>>>>>>>>>>>>>> will > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> get > >>>>>>>>> the > >>>>>>>>>>> backward compatibility stub. > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> Thomas > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Fri, Jul 14, 2017 at 8:34 AM, Vlad Rozov < > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> v.ro...@datatorrent.com> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> My preference is to agree that the next Malhar release is > >>>>>>>>>>>>>>>> 4.0.0 > >>>>>>>>>>>>>> and > >>>>>>>>>>> make > >>>>>>>>>>>>> the proposed changes when 3.8.0 goes out. Otherwise why > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>> keep > >>>>>>>> semantic > >>>>>>>>>>> versioning checks on Malhar in case there is no version > >>>>>>>>>>>>>>>> compatibility. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thank you, > >>>>>>>>>>>>>>> Vlad > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 7/14/17 08:11, Thomas Weise wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> next release is 3.8.0 > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Fri, Jul 14, 2017 at 7:55 AM, Vlad Rozov < > >>>>>>>>>>>>>>>>>> v.ro...@datatorrent.com> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> next release - 3.9.0 or 4.0.0? > >>>>>>>>>>>>>>>>>> Thank you, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Vlad > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 7/13/17 22:25, Thomas Weise wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> It is time to resurrect this thread and get going with > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> work. > >>>>>>>>> For the next release, I will sign up to do the > >>>>>>>>>>>>> package > >>>>>>>>>>>>>>>>>> move > >>>>>>>> in > >>>>>>>>>> Malhar: > >>>>>>>>>>>> https://issues.apache.org/ > >>>>>>>>>>>>>>>> jira/browse/APEXMALHAR-2517 > >>>>>>>>>>>>>>>>>> In general this will be straightforward; most classes > >>>>>>>> in > >>>>>>>>>>>>>>>>>> Malhar > >>>>>>>>> are > >>>>>>>>>>>>> marked > >>>>>>>>>>>>>>> evolving and it is trivial for users to change import > >>>>>>>>>>>>>>>>>>>> statements. > >>>>>>>>>>>>>>>>>> However, > >>>>>>>>>>>>>> I would suggest to discuss if there are selected > >>>>>>>>>>>>>>>>>>>> operators > >>>>>>>>>>>>>>>>>> that > >>>>>>>>>>> are > >>>>>>>>>>>>> worth > >>>>>>>>>>>>>>> keeping a backward compatibility stub in the old > >>>>>>>>>>>>>>>>>>>> location. > >>>>>>>>>>>>>>>>>> Here is my plan: > >>>>>>>>>>> 1. Relocate all classes in *lib* and *contrib* within > >>>>>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>> PR - > >>>>>>>>> this > >>>>>>>>>>>> is > >>>>>>>>>>>>>> all > >>>>>>>>>>>>>>>> IDE automated work > >>>>>>>>>>>>>>>>>>>> 2. Add backward compatibility classes, if, any in > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> separate > >>>>>>>>>>>>>>>>>> PR > >>>>>>>>>> 3. Create PR for Megh library to reflect moved > >>>>>>>>>>>> classes > >>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>> Thomas > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Wed, Mar 1, 2017 at 2:24 PM, Pramod Immaneni < > >>>>>>>>>>>>>>>>>>>> pra...@datatorrent.com > >>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Inline > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Mon, Feb 27, 2017 at 11:03 PM, Thomas Weise < > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> t...@apache.org> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> --> > >>>>>>>>>>>>>>>>>>>>> On Mon, Feb 27, 2017 at 1:27 PM, Pramod Immaneni < > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> pra...@datatorrent.com > >>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> For malhar, for existing operators, I prefer we do > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> this as > >>>>>>>>>>>>>>>>>>>> part > >>>>>>>>>>> of > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>> planned refactoring for breaking the monolith > >>>>>>>>>>>>>>>>>>>>>> modules > >>>>>>>>>>>>>>>>>>>> into > >>>>>>>> baby > >>>>>>>>>>> packages > >>>>>>>>>>>>>> and would also prefer deprecating the existing > >>>>>>>>>>>>>>>>>>>>>> operators > >>>>>>>>>>>>>>>>>>>> in > >>>>>>>>>> place. > >>>>>>>>>>>> Refactor into smaller modules was discussed for > >>>>>>>>>>>>>>> malhar-contrib > >>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>> given > >>>>>>>>>>>>>>> the overall state of that module I think it is OK > >>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>> defer > >>>>>>>> package > >>>>>>>>>>> renaming > >>>>>>>>>>>>>>> there. I do however prefer to see the package rename > >>>>>>>>>>>>>>>>>>>>> addressed > >>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>> other > >>>>>>>>>>>>>>> modules, especially for the main library module. > >>>>>>>>>>>>>>>>>>>>>> Should we consider breaking the library into > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> smaller > >>>>>>>>>>>>>>>>>>>> modules > >>>>>>>> as > >>>>>>>>>>>> well, > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> file/block operators for example probably can be in > >>>>>>>>>>>>>>>>>>>>> their > >>>>>>>>>>>>>>>>>>> own > >>>>>>>>>> module > >>>>>>>>>>>> from > >>>>>>>>>>>>>>>> just an organizational perspective. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> will help us achieve two things. First, the user > >>>>>>>>>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> see > >>>>>>>> all > >>>>>>>>>>> the > >>>>>>>>>>>>> new > >>>>>>>>>>>>>>> changes at once as opposed to dealing with it > >>>>>>>>>>>>>>>>>>>>>>> twice > >>>>>>>>>>>>>>>>>>>>> (with > >>>>>>>> package > >>>>>>>>>>> rename > >>>>>>>>>>>>>>> and dependency changes) and second it will allow > >>>>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> a > >>>>>>> smoother > >>>>>>>>> transition > >>>>>>>>>>>>>> as the existing code will still work in a > >>>>>>>>>>>>>>>>>>>>>> deprecated > >>>>>>>>>>>>>>>>>>>> state. > >>>>>>>> It > >>>>>>>>>>> will > >>>>>>>>>>>>> also > >>>>>>>>>>>>>>>> give a more consistent structure to malhar. For new > >>>>>>>>>>>>>>>>>>>>>> operators, > >>>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>> can > >>>>>>>>>>>>>>> go > >>>>>>>>>>>>>>>>>>>>>> with the new package path but we need to ensure > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> they > >>>>>>>>>>>>>>>>>>>> will > >>>>>>>> get > >>>>>>>>>>> moved > >>>>>>>>>>>>> into > >>>>>>>>>>>>>>>> the baby packages as well. > >>>>>>>>>>>>>>>>>>>>>> I think existing operators should be renamed so > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> git > >>>>>>>> history > >>>>>>>>>>> remains. A > >>>>>>>>>>>>>> possible solution for backward compatibility could > >>>>>>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>> to > >>>>>>> subsequently > >>>>>>>>> add > >>>>>>>>>>>>>>>> empty subclasses in the previous location (for > >>>>>>>>>>>>>>>>>>>>>> existing > >> Thank you, > >> > >> Vlad > >> > > > Thank you, > > Vlad >
