Can't build/install/configure multiple copies of the client about symphonyelectron HOT 30 CLOSED

if you want to build dmg, it is all still there, we just plan on supporting only pkg format. if you want to build dmg, then do these two at the cmd line:
npm run prebuild
node_modules/.bin/build --mac

from symphonyelectron.

How will users install multiple copies of the application, for different pods, simultaneously with the supported pkg format installer?

from symphonyelectron.

Also, the commands above still emit an installer (albeit in dmg format), not a raw .app file.

To clarify, the end result I'm looking for is two .app files, each of which is configured to use a different pod. I don't mind if that's achieved via a pkg or a dmg file or anything else.

from symphonyelectron.

we have never supported that in the past. not something our typical customer wants. there are ways around, you could manually edit the url in symphony.config file.

from symphonyelectron.

As mentioned above, most Foundation members and all of your enterprise customers have this requirement.

from symphonyelectron.

if you look in the dist directory, you will see Symphony.app (next to the dmg). you could edit the Symphony.app/Contents/config/Symphony.config file in there and have a different url for each copy of the Symphony.app

from symphonyelectron.

And how do I create a second .app file with a different name, configured against a different pod?

from symphonyelectron.

just copy the Symphony.app and rename to Symphony-xyz.app and edit config file as above.

from symphonyelectron.

Where "as above"?

from symphonyelectron.

four comments above :-)

from symphonyelectron.

you might also run into another issue... only a single instance of the app can run at a time. this is because we have a protocol handler implemented and it would be confusing otherwise which app to invoke, likely causing lots of confusion. so if you need to run multi-instances simultaneously, then we might have to provide some way to work around this. if you are building yourself anyway, you could just turn off by modifying code here: https://github.com/symphonyoss/SymphonyElectron/blob/master/js/main.js#L44

from symphonyelectron.

That seems a tad involved for end users who have this same requirement (i.e. Foundation members & all of your enterprise customers), surely?

from symphonyelectron.

So here's (part of) a script that seems to work correctly (note: requires that the handy jq tool be installed):

sed -i .bak 's/if (!isDevEnv \&\& shouldQuit) {/if (!isDevEnv \&\& shouldQuit \&\& false) {/g' ./js/main.js
npm install
npm run unpacked-mac
mkdir -p ./dist/tmp
cp ./dist/mac/Symphony.app/Contents/config/Symphony.config ./dist/tmp/Symphony.config
jq '.url="https://foundation.symphony.com"' ./dist/tmp/Symphony.config > ./dist/mac/Symphony.app/Contents/config/Symphony.config
cp -R ./dist/mac/Symphony.app /Applications/Symphony-Foundation.app

The last two lines can be repeated for each pod that needs to be configured into a separate binary (with a different target name in the cp command).

from symphonyelectron.

(apologies for close/reopeon - accidentally clicked the wrong button)

Any updates on being able to simultaneously run multiple instances of SymphonyElectron against different pods?

As of rev 04c5b8d the workarounds above are no longer sufficient - running a second copy of SymphonyElectron causes the first running instance to terminate.

from symphonyelectron.

@VikasShashidhar please assist peter here, thanks.

from symphonyelectron.

@pmonks We are looking into this. Will update you soon.

from symphonyelectron.

Any updates on this @VikasShashidhar ? I've been tracking the latest commits and this issue persists (starting a second copy of the Symphony app causes the first one to terminate).

from symphonyelectron.

@pmonks The latest builds don't have this feature yet. Although we have some leads, there's no easy way to implement this. @lneir and I will be having a discussion with Thibaud regarding this today. Will update you after our discussions.

from symphonyelectron.

@pmonks We are waiting for Thibaud's inputs for this. Will update you.

CC: @lneir

from symphonyelectron.

Thanks @VikasShashidhar. I am still able to build multiple binaries using the tricks described above, but continue to be unable to run more than one of those binaries at a time (running a second one causes the first to terminate).

from symphonyelectron.

As of rev 99f3f86 this issue has gone away. I'm again able to run two copies of the client in parallel, configured against different pods using the config file hacks described above.

from symphonyelectron.

As of rev 992503e this issue is back again.

from symphonyelectron.

@pmonks We'll take a look at this.

from symphonyelectron.

@VishwasShashidhar I take it you took a look at this? What did you find, and how did it lead to this issue being closed?

from symphonyelectron.

@pmonks We do not plan to support this feature of having multiple instances. However, you can still connect to different pods without having to modify the Symphony.config file by passing a command line argument --url while starting the app.

On macOS, you can do so as below:
/Applications/Symphony.app/Contents/MacOS/Symphony --url="https://my.symphony.com"

On Windows, you can do so as below:
C:\Program Files\Symphony\Symphony\Symphony.exe --url="https://my.symphony.com"

from symphonyelectron.

@pmonks We do not plan to support this feature of having multiple instances.

Why not? This is an ubiquitous requirement for users of the Enterprise product, as well as most members of the Symphony open source community.

from symphonyelectron.

@pmonks We do not plan to support this feature of having multiple instances.

Why not? This is an ubiquitous requirement for users of the Enterprise product, as well as most members of the Symphony open source community.

@pmonks Understandable, but some use cases cannot be handled with multiple instances. For example, opening the app from an external browser using a custom protocol url like symphony://, in which case, we wouldn't know which instance to open. There'll also be a case where notifications are shown for both the instances which would be redundant.

from symphonyelectron.

If the protocol URL identifies the pod, it would be trivial for the correct instance of the app to open. Ditto notifications - I believe those too are pod-specific, and therefore could be trivially targeted to the app instance configured for that pod.

from symphonyelectron.

@pmonks I'll take this with the product team & get back.

from symphonyelectron.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from symphonyelectron.