Whenever there is a new update of the worklight studio available in the eclipse market place I install it to get the latest fixes. When I restart eclipse after installing an update, Worklight triggers some kind of process to update my project to the new version. During this process worklight does some black voodoo and updates some files.
I suppose that once I commit these files, the entire team should download and install the new update from the eclipse market place? Because it can't be a good idea to work with an old version of Worklight Studio on a project that was already updated to work with a newer version.
Are there any best practices on this topic?
Is it a good idea to update your worklight studio on a regular base? I'm not talking about minor or major versions, just a new patch which is available in the eclipse marketplace. Take for example an update from platformVersion="6.2.0.00.20140701-1500" to platformVersion="6.2.0.00.20140724-2139"
If you choose to stick with one specific version, how do you distribute this to new members in your development team? Should you keep a copy somewhere? And what happends then if you need a fix?
I suppose that once I commit these files, the entire team should
download and install the new update from the eclipse market place?
Because it can't be a good idea to work with an old version of
Worklight Studio on a project that was already updated to work with a
newer version.
If you do not work alone, and you upgrade your Worklight Studio version (which then does "black voodoo" and updates the project's files) and you then deliver your changes to your SCM, then yes - your team members must upgrade their Worklight Studio plug-in as well.
Are there any best practices on this topic?
As a Worklight development team member, my advise is: if we publish a fix to Eclipse Marketplace / IBM Fix Central - yes, install it.
That said, you can also review the list of fixed bugs ("APARs") in IBM Fix Central and decide whether you'd like to upgrade your installation.
Before doing so, you can opt to first install this fix in a new Eclipse and workspace and make sure your project is not getting broken. If you feel all is OK, upgrade your main development environment and instruct your team members to do the same, then, migrate the project using the new Worklight Studio version and deliver your changes to the SCM.
If you choose to stick with one specific version, how do you
distribute this to new members in your development team? Should you
keep a copy somewhere? And what happends then if you need a fix?
Branch your code in the SCM based on the version? But why create headache...
Related
I need to build my project with Worklight version 6.1.0.02.20141216-0421, but I didn't find it. Please who has this version ?
If you absolutely must have this specific build, you can find it here if you use Worklight Consumer Edition, or here if you use Worklight Enterprise Edition, if you are an IBM customer with a valid support entitlement.
However, if there isn't a very specific reason that you absolutely must have this specific build, I strongly agree with Idan's answer that you should use the most recent iFix build available on IBM Fix Central. As of right now, the latest build contains fixes for 93 separate APARs that are not contained in the build you are asking about (from more than 2 years ago).
That is an extremely old build and unless this build was an official iFix release - it will no longer exist. So, if you are an IBM customer you can look for this build number in the IBM Fix Central website.
Note however that you should always use the latest available iFix release... and not a build from more than two years ago, especially for production. If you will request official support, you will be told to use the latest build.
We have a worklight i/OS hybrid application built and deployed to the worklight console using RTC jazz team build and the ant-builder ant tasks (6.1.0.1). The ipa packaging is done on a separate machine, though using the same level of Worklight Studio (6.1.0.1).
I've compared the wlapp files that are generated, and they are basically identical except for some whitespace characters (tabs, line feeds), probably due to the different environments (Windows vs AIX), and the following:
index.html
"WORKLIGHT_NATIVE_VERSION": "3921556017",
"WORKLIGHT_PLATFORM_VERSION": "6.1.0.01.20140311-2356",
"WORKLIGHT_NATIVE_VERSION": "1475155033",
"WORKLIGHT_PLATFORM_VERSION": "6.1.0.01.20140311-2356",
deployment.data
native=3921556017
native=1475155033
However, the direct update never happens when the wlapp is updated on the server.
on the WL.Client.connect call, the following json comes back as part of the response
gadgetProps":{"directUpdate":{},"ENVIRONMENT":"iphone"}
What are we missing here? What can be preventing the direct update from triggering?
Any help would be greatly appreciated.
The 6.1.0.1 iFix version 6.1.0.01.20140518-1532 from IBM Fix Central seems to have resolved this problem for us.
And what if you are not using ant, but rather built the project in Worklight Studio straight to Xcode from then install the .ipa and test Direct Update. Does it work?
From your question it is not clear whether or not you've confirmed one or the other.
Regardless, since the v6.1.0.1 build you are using, several Direct Update-related fixes were introduce; one with close proximity to the error you mention (directUpdate:{ }), so I suggest to to open a PMR in order to receive the latest available iFix (not yet available at IBM Fix Central).
I used top be able to integrate a StarTeam plugin with MyEclipse using this update site URL: http://altd.borland.com/update/eclipse3.6/site.xml
But using newer versions of MyEclipse, this plugin no longer can install, I get this error:
Cannot complete the install because one or more required items could not be found.
Software being installed: StarTeam 2009 R2 Eclipse 3.6 Client 11.0.0.97v20111028-1643 (com.borland.starteam_3.6.feature.group 11.0.0.97v20111028-1643)
Missing requirement: StarTeam 2009 R2 Eclipse 3.6 Client 11.0.0.97v20111028-1643 (com.borland.starteam_3.6.feature.group 11.0.0.97v20111028-1643) requires 'org.eclipse.platform.feature.group [3.6.0,4.0.0)' but it could not be found
Does anyone have the same problem and found a workaround? I am willing to consider any option... so far my best option seems to be to downgrade Eclipse to an older version where the plugin still works. But I want to see if there's a better alternative out there
Found out the answer by a support rep from the group responsible for the plugin.
Firstly, they no longer offer the plugin via that site URL. You download their plugins from their ftp: ftp://ftp.microfocus.com/download/
and Secondly, they do not yet have a plugin that supports the latest verison of Eclipse, they are still working on it...
I would strongly discourage trying to use StarTeam with Eclipse. Ever since StarTeam 5.3, Borland has been trying to play catch-up with Eclipse. In my experience their clients have never worked well with Eclipse even when they did work. Moves in particular were handled very poorly, and resulted in duplicate files in StarTeam. Even worse was trying to use IBM WebSphere/RAD with Eclipse and StarTeam/Eclipse plugin, because IBM and Borland always required different versions of Eclipse and were ultimately incompatible. For a short time there was a time where RAD 6 and StarTeam 2009 (I believe) were both working on the same Eclipse, but the Synchronization was problematic from Eclipse to StarTeam as mentioned. There was a time when Borland had planned on replatforming the StarTeam Client on top of Eclipse, but not sure what ever happened to that plan.
I have just upgrade my Eclipse client running Juno to Worklight 5.0.6 developer edition (5.0.6.20130311-0918)
The projects upgrade fine, but when building them and deploying to the local worklight server I get a constant 'persistency data access problem' This occurs across all of my projects and has only been seen since the update.
Any idea on what is causing this problem and how to solve?
I would add a screen shot of the issue but I am not allowed
Based on your comment - in 5.0.6, the database schema has changed, so you have missing tables now. In the Developer Edition of Worklight, upgrade is not supported (this is handled when purchasing a license and using the IBM Installation Mananger for installing Worklight).
Do you mean "HSQL"? What is "Web SQL?"
In any case you will need to clean your database so that it will be re-created, this time with the missing tables.
If you use the default database provided by Worklight (HSQL), go to your Eclipse Workspace and delete the WorklightServerHome folder. Then, re-build your application.
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.