Hi Jessica, Yes it makes sense. The reason why I started refactoring the code in the remote tools is to try and isolate the functionality we need to move to the separate plugin. Instead of moving everything in the first place, I am trying to reduce the code to single points of control without modifying the actual functionalities of the Helpers. I can do the refactoring the other way around, but I think this way is cleaner because I would be clear what we need to keep in the helpers and what to drop.
Thanks, Ioana -----Original Message----- From: Zhang, Jessica Sent: Friday, April 26, 2013 9:31 PM To: Grigoropol, IoanaX; yocto@yoctoproject.org Subject: RE: [yocto] [PATCH 0/4] Initial changes for developing a common remote plugin Hi Ioana, I thought we're going to create a common remote util plugin first then modify the remotetools and bc.ui to use this new remote util plugin. From your patch series, the 1st path seems you're doing that but the following 3 you are making changes to remote tools files. I'd like us to focus on creating this common util first then switch to modify the other plug-ins by using this common util. I'd expect this common util will contain classes that host all the functions that currently exist in RemoteHelper.java in bc.ui jzhang/windows-build and RSEHelper.java in remotetools. There are many duplicate codes in these classes that we should abstract them out to put in this common util plug-in. Does this make sense? Also, please add License header in new files if you are going to introduce any. Thanks, Jessica -----Original Message----- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Ioana Grigoropol Sent: Friday, April 26, 2013 7:32 AM To: yocto@yoctoproject.org Subject: [yocto] [PATCH 0/4] Initial changes for developing a common remote plugin - create a separate plugin in which to drop all tools needed for remote support - will leave it empty until all functionalilty is properly separated & the util remote code is clearly distinguised - code refactoring for remote tools plugin in order to simplify code and create single point of control over commands stages [Yocto #4362] Ioana Grigoropol (4): Initial commit for remote separate plugin Refactor Model(s) to display customized messages Unify preProcess for all commands models Add default behaviour for commands for post processing Signed-off-by: Ioana Grigoropol <ioanax.grigoro...@intel.com> plugins/org.yocto.remote.utils/.classpath | 7 ++ plugins/org.yocto.remote.utils/.project | 28 ++++++ .../.settings/org.eclipse.jdt.core.prefs | 7 ++ .../org.yocto.remote.utils/META-INF/MANIFEST.MF | 10 +++ plugins/org.yocto.remote.utils/build.properties | 4 + .../src/org/yocto/remote/utils/Activator.java | 50 +++++++++++ .../yocto/sdk/remotetools/actions/BaseModel.java | 89 +++++++++++++------- .../sdk/remotetools/actions/OprofileModel.java | 53 ++++-------- .../sdk/remotetools/actions/PowertopModel.java | 47 ++++------- .../sdk/remotetools/actions/SystemtapModel.java | 34 ++++---- .../yocto/sdk/remotetools/actions/Ust2Model.java | 63 ++++---------- .../sdk/remotetools/actions/UstModelLegacy.java | 54 ++++-------- 12 files changed, 243 insertions(+), 203 deletions(-) create mode 100644 plugins/org.yocto.remote.utils/.classpath create mode 100644 plugins/org.yocto.remote.utils/.project create mode 100644 plugins/org.yocto.remote.utils/.settings/org.eclipse.jdt.core.prefs create mode 100644 plugins/org.yocto.remote.utils/META-INF/MANIFEST.MF create mode 100644 plugins/org.yocto.remote.utils/build.properties create mode 100644 plugins/org.yocto.remote.utils/src/org/yocto/remote/utils/Activator.java -- 1.7.9.5 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
