Changes don't touch js code at all. Just .java / .m / .h. I *did* do what Jesse suggested with the project.pbxproj references for iOS. Still ended up creating symlink source files anyways though, just so that I can fs.readlink them upon uninstall and figure out which project references to remove.
For Android, you can link in CordovaLib without a symlink by doing what I did for the test/ project ( https://github.com/apache/cordova-android/blob/master/test/settings.gradle). You could probably link in all the plugin sources by listing them out in the gradle file as well, but that would be far more work. I noted on the first of the JIRAs, but I *did* test all of this out on a windows 8 VM and it worked fine. Without admin, you get a permissions error, with admin rights, it works fine. Since this flag is just for plugin authors, I don't think it's a big deal that on Windows it requires admin. That said, if someone wants to put the work in to rejigger it to not need them, that's good too! And hey... I hear Windows 10 is around the corner... Maybe with such a big version jump it will have userland symlinks!? On Mon, Jan 26, 2015 at 6:51 PM, Jesse <[email protected]> wrote: > The same trick is available from xcode, which means the file or folder gets > added to the project, but it is 'referenced' from it's location, without > copying local. I too prefer the approach of NOT needing to symlink, > > Again, to Andrew, did you test any of this on windows? Android Studio is > available for windows too right, how much of your install base is on > windows? > > Also, didn't mention this earlier, but how are we handling the differences > between checkin js plugin state and runtime js plugin state? In order to > run and load correctly js-module code needs to be wrapped in a > cordova.define(...) call. > > > > > @purplecabbage > risingj.com > > On Mon, Jan 26, 2015 at 3:31 PM, Murat Sutunc <[email protected]> > wrote: > > > I've some concerns about linking workflow in Windows. > > Having admin rights in a cmd prompt is not desirable - there are many > > cases where a user might not have the rights. I'm currently investigating > > `Junctions` to see if it will work for this scenario. Alternatively we > can > > do the trick Jesse suggested earlier for Windows. I'll follow up with a > PR > > later to enable this for Windows devs. > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of Andrew > > Grieve > > Sent: Monday, January 26, 2015 8:50 AM > > To: Andrew Grieve > > Cc: dev > > Subject: Re: FYI: Created a plugin to help with local plugin development > > > > And... now: > > > > createmobilespec.sh --linkplatforms > > > > and > > > > createmobilespec.sh --link > > > > is and alias for > > > > createmobilespec.sh --linkplugins --linkplatforms > > > > So, for iOS and Android, this will create a project where you can edit > > native files in both plugins and platform and the changes will be > reflected > > in cordova-ios, cordova-android, cordova-plugin-foo* repos! > > > > Also - looks like I had accidentally hardcoded --browserify to be on on > > Thursday. > > Fixed now, but if you noticed mobilespec being funny, it's because > > --browserify was on. > > > > > > > > On Thu, Jan 22, 2015 at 10:30 PM, Andrew Grieve <[email protected]> > > wrote: > > > > > Implemented the iOS approach: > > > https://issues.apache.org/jira/browse/CB-8354 > > > > > > createmobilespec.sh --linkplugins --android --ios > > > > > > This lets you (after command-line building once in Android's case): > > > 1. open the project in Android Studio or Xcode 2. edit plugin .java / > > > .m / .h 3. see the change reflected in your local cordova-plugin-foo > > > directories > > > > > > Also added: > > > > > > createmobilespec.sh --browserify > > > > > > which does what you think it does. > > > > > > > > > On Mon, Jan 5, 2015 at 9:49 PM, Andrew Grieve <[email protected]> > > > wrote: > > > > > >> Thought about Windows, but didn't test on it. Figured since --link > > >> was a hot-off-the-press flag, that if there were bugs with it we > > >> could keep iterating. > > >> > > >> iOS approach makes sense to me. I've added it to the JIRA. > > >> > > >> On Mon, Jan 5, 2015 at 6:53 PM, Jesse <[email protected]> > wrote: > > >> > > >>> Andrew, did you test your changes in Android Studio for Windows? I > > >>> am curious how well symlinks work there. > > >>> Visual Studio and XCode both support adding file/folder references, > > >>> which would mean that saving a changed plugin native file would save > > >>> it to it's original location. This is the way I have typically > > developed plugins: > > >>> - install once > > >>> - change file paths in the IDE to point to the plugin-repo directly > > >>> - debug / iterate / add functionality in the IDE > > >>> - once satisfied, remove the plugin, and re-install the way a mortal > > >>> user would, smoke test > > >>> - publish > > >>> > > >>> essentially, avoiding constant re/un/installing > > >>> > > >>> > > >>> @purplecabbage > > >>> risingj.com > > >>> > > >>> On Mon, Jan 5, 2015 at 12:56 PM, Andrew Grieve > > >>> <[email protected]> > > >>> wrote: > > >>> > > >>> > Along these lines, I likewise got frustrated with my workflow and > > >>> added a > > >>> > new feature to "cordova plugin add --link". > > >>> > > > >>> > Instead of just creating symlink in the plugins/ directory, it now > > >>> > also creates symlinks for .java files, so that you can edit plugin > > >>> > .java > > >>> files > > >>> > in Android Studio, and hitting save will cause the original plugin > > >>> .java > > >>> > file to be updated! > > >>> > > > >>> > Worth experimenting with for other platforms as well I think, but > > >>> > this setup does require the IDE & build tools to play nicely with > > >>> > symlinks (which is why I did it for Android only). > > >>> > > > >>> > https://issues.apache.org/jira/browse/CB-8244. > > >>> > > > >>> > On Mon, Dec 1, 2014 at 5:13 PM, Michal Mocny <[email protected]> > > >>> wrote: > > >>> > > > >>> > > Took the opportunity to use our new plugin hooks and created a > > >>> plugin to > > >>> > > automate a tedious task I've been doing a lot of recently: > > >>> > > plugin re-installation. > > >>> > > > > >>> > > https://github.com/mmocny/cordova-plugin-plugin-auto-upgrade > > >>> > > > > >>> > > As per the README: > > >>> > > ================ > > >>> > > > > >>> > > This plugin with automatically upgrade (re-install) a set of > > >>> > > plugins (specified by you) before every cordova prepare. This is > > >>> > > useful if > > >>> you > > >>> > are > > >>> > > doing plugin development and would like to automatically > > >>> > > synchronize > > >>> your > > >>> > > app with any changes made to your plugin. > > >>> > > > > >>> > > Install the plugin: cordova plugin add > > >>> > > org.apache.cordova.labs.pluginAutoUpgrade > > >>> > > > > >>> > > At root of your app, create a pluginAutoUpgrade.json file, which > > >>> looks > > >>> > > like: > > >>> > > > > >>> > > { > > >>> > > "PLUGIN_ID": "PLUGIN_INSTALL_PATH", > > >>> > > "PLUGIN_ID2": "PLUGIN_INSTALL_PATH" > > >>> > > } > > >>> > > > > >>> > > ================ > > >>> > > > > >>> > > This is useful if you are making changes to a plugin inside the > > >>> plugin's > > >>> > > directory structure. > > >>> > > > > >>> > > For more meaty plugin work, you are possibly better off making > > >>> > > native changes inside platforms/ and js changes inside plugins/, > > >>> > > and being > > >>> very > > >>> > > careful to not clobber your work (or use the build/run scripts > > >>> directly > > >>> > to > > >>> > > skip prepare entirely). I'm considering improving that workflow > > >>> > > as > > >>> well. > > >>> > > > > >>> > > For now, I've found this plugin useful for minor plugin work. > > >>> Sharing in > > >>> > > case you do, too. > > >>> > > > > >>> > > -Michal > > >>> > > > > >>> > > > >>> > > >> > > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > >
