I have a pureapp frame with one software component (system plugin)
in it. Every time i make changes in install.py, i have to "build
with binary" and "update to test environment" and deploy the frame
which ultimately create new instance and install other default
plugins and the one i created (takes more than 15-20 minutes).
Is there any way to make changes to my plugin only and re-run the frame
without redeploying the instance and other default plugins?
found the way....
my question was about IBM pure application (not added on the site yet)..
anyway trick is to add debug component and enable 'Resumable on script error' in the frame.
when execution fails, removing dump.json will resume the operation
Related
So I'm trying to build an auto-updater for my app. I've chosen the "Update downloader with silent version check". It's integrated with my launcher as well, like it can be seen in the first picture. I'd like if possible to remove the screen where the user is asked whether to launch the updater and just always execute it.
launcher integration
Screen to remove
My client would also like to have the auto-update process as unattended as possible. So it would need the following steps:
1) user starts launcher
2) auto-updater checks and finds new version
3) auto-updater downloads new version
4) auto-updater launches downloaded updater
5) auto-updater finishes and relaunches new version of the app
I've managed the first 4 steps but I can't manage to make it relaunch the app, or at least have an informative message saying that the user needs to relaunch it him/herself. I've added the Execute launcher action but it seems to either not launch or launch the previous version. Is there a tutorial or anything for this at it seems like my case is pretty standard? :(
Any help would be appreciated, as I've been struggling with this for a while.
Thanks
The background update functionality in install4j (since 7.0) is more suitable for your use case.
See
https://www.ej-technologies.com/products/install4j/whatsnew7.html
and search for "Background auto-update" to see screen shots.
To get started, add a "Background update downloader" application on the Installer->Screen & Actions step.
In the launcher wizard of a GUI launcher that should process scheduled update installers, go to the new "Auto-update integration" step and select the "Execute downloaded update installers at startup" check box. By default, the execution mode is set to "Unattended mode with progress dialog".
For services and command line launchers, the UpdateChecker API allows you to execute scheduled update installers programatically.
You can also execute the downloaded installer as soon as it's downloaded. The source file
samples/hello/gui/HelloGui.java
shows you how to interact with the background updater by using the API.
I've got an Maven-WAR-packaged JavaEE6 project here which has an EJB service layer and a JSF2-based web layer.
Every time I try to update source by JRebel plugin (Netbeans 8.1) it takes almost the same time than a full redeployment (considering even a Glassfish restart).
Does anyone here faced this kind of problem? Any tips, guidelines for a quick solution?
In NetBeans, the automatic deployment of the changes is automatically enabled. Make sure that the checkbox is unset if you want to use JRebel. Chances are that this is the reason why updating the app takes time.
Right click on the project -> Properties -> Run -> unset "Deploy on Save"
If this is not the case, shoot the email at support#zeroturnaround.com - they should help.
I apologize if this is not the right place to ask such question, but I'm at my wit's end since Embarcadero's forum won't allow me to post any question there.
I have enabled the "Deploy" feature in the C++ Builder IDE, to test out about the depending dll & bpl files of my application, when I'm done, I found myself trapped in an annoying state - I can't perform any debugging without connected to a remote pc (with their PAServer)! This is causing a HUGE problem for me as I will not be able to debug my application if I'm away from the office, i.e. I'm on a field service at my client's place or at home.
I tried deleting the deployment profile, but it just get recreated every-time I compile my project and there is a DEPLOY command upon running compiling and running the source code. I have to wait until the connection attempt to the remote pc time-out to continue testing the application by manually clicking the .exe of my application.
Is there any way to turn off the "Deploy" feature so that I can do debugging on my local machine just as before activating the "Deploy" feature?
I've found out where the profile was hiding and deleted it, now I can debug as usual.
In the Rad Studio help:
ms-help://embarcadero.rs_xe5/rad/Connection_Profile_Manager.html
On occasion, I have this same problem with DelphiXE5 (where the problem is that I forget how to get back to the default environment without losing my remote settings.)
Remote Deploy active:
The Revert option for the normal build/debug environment:
And finally, the previous Remote Deploy settings available via the same Target Platform context menu (i.e., Properties):
The Default Connection isn't something to be setup. To the contrary, it's really not a connection at all. The Revert... menu item essentially means Revert to local build & debug.
I have recently started developing an Eclipse plugin (which is basic stuff for now) and I am struggling with "default" way to run Eclipse plugin ("Run as Eclipse application").
The Eclipse is starting another instance with my plugin already installed in it (this is default behaviour).
The problem is that when I want to re-run my plugin project and I press "run" button again (or Ctrl + F11) (and the another Eclipse instance still running) I get following message:
"Could not launch the application because the associated workspace is currently in use by another Eclipse application".
The error makes sense, and when I close "testing" Eclipse instance I am able to run my plugin again.
The question is - "is it normal routine for plugin development?". Maybe I am missing something, e.g. special arguments for Eclipse?
This seems all pretty normal. The error message is since the run configuration is specifing a workspace and when you start a second instance using the same workspace it is locked and considered in use.
What I usually do when testing a plugin is to create a run configuration (click "Run...") where I disable all the plugins I wont need when testing. This makes sure that the test starts up a couple of seconds quicker. Make sure you save that run configuration as a *.launch file aswell, that makes it quicker to test the next time. Or it can be used to share the configuration.
There's a lot you can configure in the run configuration, such as eclipse arguments, vm argument, if you want environment variables set, etc. So be sure to experiment a little.
In your run configuration. Main tab->Workspace Data ->Location text box add this:
${workspace_loc}/../runtime-EclipseApplication${current_date:yyyyMMdd_HHmmss}
Note the suffix ${current_date:yyyyMMdd_HHmmss} by this every time you launch your application new workspace will be created. So you will not get any error message saying workspace is locked.
But be careful as the folder .metadata will be different for different instances as their work-spaces are different. Thus preferences stored/retrieved by different instances are NOT in sync.
You are probably missing one important point: Eclipse supports the Java hot code replacement. Therefore in many cases you can modify your Java code while your application Eclipse instance is running, save the code and continue without restarting.
If hot code replacement is not possible, Eclipse will tell you, so you always know whether the editing changes are applied to the running instance.
This works best with more recent versions of the JVM, so consider upgrading to the latest Java 7 version, even if you write code to be compliant with Java 1.5 or 6.
I have started a new job from a couple months, I work as front developer in a company where up until now everyone was using classic development patterns, but the goal is to move to a new ajax/rest services approach and that's what I do.
In our local development environment our apps run on Resin which runs inside Eclipse and get deployed as war files to C:\Resin\resin-pro-4.0.27\webapps
My problem is that I work mostly on css html and js files, static resources so I shouldn't need to restart Resin and wait 15 seconds (when it doesn't crash) to see the effect of every little piece of code I change.
Other problem is that I need to edit some files in external editors (sublime text for js, Crunch for LESS); I managed to make Eclipse open the external editor but even with the "Refresh using native hooks or polling" build option it takes a while to realize files have changed and restart Resin.
I also tried just working on the unpacked war in C:\Resin\resin-pro-4.0.27\webapps\appname but even there it takes like one minute before you can see the changes on the browser (is there some caching going on the server? can I disable it?)
I welcome any suggestion as all this is really hurting my productivity
inside Resin.xml <host><web-app> add:
<cache-mapping url-pattern="*.js" expires="0s"/>
<cache-mapping url-pattern="*.css" expires="0s"/>
<cache-mapping url-pattern="*.htm" expires="0s"/>
<cache-mapping url-pattern="*.html" expires="0s"/>
This used to work for me (in resin.xml)
<!--
- For production sites, change dependency-check-interval to something
- like 600s, so it only checks for updates every 10 minutes.
-->
<dependency-check-interval>2s</dependency-check-interval>
Also check resin.properties for a variable definition in newer versions.
However I'm currently having problems picking up changes without a full redeploy.