Why don't we go in a reverse direction - instead of creating multiple scripts for different needs we incorporate all capabilities within visorcmd? Visor is an app/script that can be updated to meet the requirements of specific tools.
- Denis On Wed, Jan 23, 2019 at 1:23 PM Sergey Kozlov <skoz...@gridgain.com> wrote: > Thanks Sergey for the raising the question. > > What's about move actual/interesting commands from visorcmd and remove that > script at all? > > Also would good simplify the bash code of script and ideally process > everyting inside java code? > > On Wed, Jan 23, 2019 at 7:38 PM Stanislav Lukyanov <stanlukya...@gmail.com > > > wrote: > > > I value strict compatibility rules very highly, and would be happy if we > > never removed a public class (even if it is in the “internal” package) > > in a minor release. > > Unfortunately, Ignite is far from that place for now. We don’t have any > > distinction between API and internal classes, don’t have > > plugin-only APIs, etc. All classes are public, everything is accessible > to > > user code. We even refer to internal classes in public Javadoc > > (e.g. I recall mentions of IgniteUtils in examples here and there). > > Considering this, moving CommandHandler from ignite-core to > > ignite-control-utility > > doesn't look that bad. It doesn’t differ to much from any other change > > that removes or renames a class. > > There could be required changes with a higher compatibility impact but I > > don’t see them after a superficial glance. > > > > Stan > > > > From: Sergey Antonov > > Sent: 23 января 2019 г. 19:15 > > To: dev@ignite.apache.org > > Subject: Re: [DISCUSSION] Control.sh global rework in apache ignite 3.0 > > > > Stan, thank you for response! > > > > I my view we shouldn't make incompatible changes and switch extendable > > classes (i.e. VisorDataTransferObject -> IgniteDataTransferObject) > between > > minor releases. Therefore we couldn't rework utility in 2.8 release. > > > > ср, 23 янв. 2019 г. в 18:48, Stanislav Lukyanov <stanlukya...@gmail.com > >: > > > > > Hi, > > > > > > Sounds good. I agree with all points so far. > > > > > > I don’t really see why to wait for 3.0 though. > > > As long as the old commands work I think it’s fine to do all of that > in a > > > minor release. > > > > > > Even moving the code to a separate module is fine as all the classes > are > > > internal and unlikely to be used in the wild. > > > On paper it’s an incompatible change, of course, but I think in this > case > > > it’s fine. > > > > > > My 2 cents, > > > Stan > > > > > > From: Sergey Antonov > > > Sent: 23 января 2019 г. 17:10 > > > To: dev@ignite.apache.org > > > Subject: [DISCUSSION] Control.sh global rework in apache ignite 3.0 > > > > > > Hello, Igniters! > > > > > > I think, we should rework control.sh utility in Apache Ignite 3.0 > > release. > > > I made umbrella ticket [1] for it. > > > > > > For a start we should move utitlity from ignite-core to separate module > > > [2]. It's enable using 3rd-party libraries, for example commons-cli > [3]. > > > > > > Also we should add logging to file [4] and stop using depricated > classes, > > > for example [5]. > > > > > > I'd like to get yours comments about control.sh. > > > > > > Let's collect comments and improvements and discuss them! > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11045 > > > [2] https://issues.apache.org/jira/browse/IGNITE-11046 > > > [3] http://commons.apache.org/proper/commons-cli/ > > > [4] https://issues.apache.org/jira/browse/IGNITE-10826 > > > [5] https://issues.apache.org/jira/browse/IGNITE-11047 > > > -- > > > BR, Sergey Antonov > > > > > > > > > > -- > > BR, Sergey Antonov > > > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com >
