I am a huge fan of Jetbrains "AppCode". But due to the variety of projects I have some depending on older XCode versions and others can be the latest and greatest. It's great that we can have multiple XCode installations side-by-side. But is this also possible with AppCode? I remember that back a couple of years, the EAP version could be installed side-by-side with the stable release. This would also already help, but I cant even find a separate EAP download anymore.
Anybody any tips for me?
You can use JetBrains Toolbox to install as many product versions as you like side by side with the automatic update (optional) and rollback support.
In Toolbox you can set certain product versions to stick to the specific installed version and do not offer the updates.
Major IDE versions do not share the configuration and can be even run at the same time. Minor version can be also configured to use different folders for config/plugins/caches if needed.
Related
I want to know what is the difference between installing HortonWorks HDP vs installing the components directly from Apache projects? One thing I can think of is that Horton works probably has the packages aligned so that the version of each component is compatible with that of the others within the suite, while getting them directly from Apache projects, I may have to handle version compatibility myself. Is that correct? Is there any other difference involved ignoring the support subscription aspect of it.
Thanks.
There are a lot of differences between "roll your own" and using a distribution. Some of the most obvious include:
All of the various components and versions have been tested and built to work together - incompatibility between versions (e.g. Hive, Hadoop, Spark, etc.) can be a painful problem to sort through on your own
Most distribution providers, including Hortonworks, will bring patches in from unstable releases into stable releases, so even for the "same" version (e.g. Hive 1.2.1) you're getting a better release than vanilla - these can include both bug fixes and "safe" feature changes
Most distribution providers, including Hortonworks, provide some flavor of centralized platform management. I'm a big fan of Ambari (the one that comes with HDP), for example - it makes configuration and monitoring significantly easier than coordinating a vanilla install
I would strongly recommend against trying to deploy vanilla, unless it's just for learning and playing. HDP community edition is free (both definitions) and a major improvement over doing it yourself. My last deployment of HDP was entirely based on the community edition.
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...
I would like to distribute an application that depends on several PyPI-packaged libraries. I have carefully selected certain versions of some of these libraries as newer versions (in some cases) are incompatible. My installer downloads them (with pip) at install-time and sets up the environment for the application. But how long are those versions going to be available? 6 hours? 2 years? Anything in between?
I'm basically looking for some sort of policy that tells me how long those versions of libraries are going to be hosted on PyPI (and who makes that decision).
In-before-"distribute them yourself": That is an answer to a different question.
This is really about how PyPI works, not how I distribute my application.
The friendly people in #python tell me that authors can delete any version of their packages at any time.
The only way to indemnify yourself against a version of something becoming nuked is to (assuming their license allows it) ship it yourself.
There is an argument for continuous integration against the latest versions on PyPI but that does assume there will be a new version and that the author doesn't just delete the whole thing. CI is just a good practice here, not a panacea.
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.
With the new firefox we are shipping more and more libraries as the XPom interfaces we interact with are changing. We are at 10 dlls and increasing, each with a size of almost 2M.
This size is a concern for some users.
While we look at restructuring the library to seperate the parts we can make common between them, we are thinking about how we might reduce space on the disk while supporting version upgrades.
For instance, user has FireFox 3.6 and 4.0 installed and when our product is installed we install a dll for each version. When Firefox is 4.0 upgraded (say to 6.0) how might we now install from the msi the missing dll for 6.0 support.
Any ideas on how we could achieve this?
Are we worrying for no reason?
My first thought was we 'AllowAdvertise' and when FF tries to load the dll as directed by chrome it will cause the install, it doesn't seem to work.
My first reaction is to suggest that you move away from XPCOM and towards js-ctypes. After all, this is the direction that Mozilla is pushing extension developers (see Wladimir Palant's comments for example). If there isn't anything in your binary code that absolutely positively requires use of XPCOM, you'll be much happier to ship a DLL that interfaces with JS when needed via js-ctypes.
I guess that your extension is Windows-only so supporting multiple platforms is not an issue. A possible short-term solution:
Have a separate extension package for each Firefox version, mark it as compatible with this Firefox version only (e.g. minVersion 4.0 and maxVersion 4.*).
When your extension is installed, install the version that is compatible with user's installed Firefox version.
Make sure that your extensions have an updateURL entry that is pointing to your server. It is important to have %APP_VERSION% in the URL.
Make sure to test Firefox betas and prepare a new extension version in time for the next Firefox release (releases are scheduled on Tuesdays every 6 weeks, next release being on September 27th).
Configure your server to indicate different packages as updates depending on the Firefox version used. So an update check with %APP_VERSION% 4.0.1 would be sent to extension-ff4.xpi while %APP_VERSION% 6.0 would get extension-ff6.xpi.
Firefox will always check for extension updates when the application is updated. If you can give it a compatible update it will install it. But preparing new packages every six weeks requires tons of effort and I guess that you want to refactor your code/move to js-ctypes ASAP. Oh, and I think that you need to ignore the unlikely scenario that some user has more than one Firefox version installed.