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
