We have MuleSoft applications and they are deployed in Mule Runtime. We need recommendations on patching MuleSoft applications. The patch can be either in MuleSoft Runtime itself or can be in application.
MuleSoft's recommendation on patching a MuleRuntime is available at https://support.mulesoft.com/s/article/How-to-apply-patches-to-Mule-4-x.
Here, the recommendation to patch MuleRunTime is to replace the jars/plug-in. But with this, how can we maintain/know the version of patch that is applied.
What is the recommended way to patch a application which is deployed in MuleRunTime.
Any help/recommendation on this is appreciated. Thanks.
You can look at infrastructure automation tools that auto install your runtime with the correct patches etc like puppet, chef and so many other tools. So that your runtime is always using the correct doenedencies and is repeatable. Which tool depends on your organisation.
Or just as with your code you can version control your runtime or install scripts in git etc.
The Mule runtime will log its own version and the versions of each plugin and applied patch, whenever it starts your app. So check the log from the last time you started and you'll see the current version and patch level.
So trust the recommendations in the help document you cited in the OP. As Ryan says, you can use any dev-ops tools favored in your organization. (If you don't have a favorite, Maven is integrated very nicely with Anypoint Studio and can help with this.)
Related
I'm looking for a solution on how to deal with API versions in ANYpoint API manager. At the moment it is possible to create a new version of an API. But it is not possible to distinguish between different OTAP environment. In my situation it could be possible that a test environment has a newer API version than production. Do anyone recognize this issue and how did you solve it?
Currently, there are no environment promotion capabilities per se in Anypoint Platform. Having said that, there are a number of things that you can do that can help in that regard, for example:
- You can export an API from Organization A and import it on Organization B.
- You may define different sub organizations, to reflect your OTAP environment structure.
In general, it is not strictly bad that on QA, Stage or UAT environment, you have a newer API version than in Production, if you plan to implement such version in there.
Just my 2c, Nahuel.
As far as i understand if we want are going to create multiple apis then RAML versioning should be followed. what i do i can share with others.
development raml version= 0.1.0
First major release version=1.0.0
if there is any minor change then we can do 1.0.1
if there is any major contract breaking change then we can use 2.0.0.
As mentioned in the Bluemix guide, I tried installing the Bluemix tool plugin on eclipse(Mars) with Java 7 installed on my Ubuntu machine.
1). Through the eclipse market place where Bluemix tool is present and the same fails with the following error when installation is nearly over:
Cannot complete the install because one or more required items could not be found.
Software currently installed: IBM Bluemix Tools 1.0.5.v20150801_1001
(com.ibm.cftools.feature.feature.group 1.0.5.v20150801_1001)
Missing requirement: Bluemix Tools 1.0.6.v20150801_1001
(com.ibm.cftools.branding 1.0.6.v20150801_1001)
requires 'bundle org.eclipse.jst.server.core 0.0.0' but it could not be found
Cannot satisfy dependency:
From: Cloud Tools Branding UI Plugin 1.0.2.v20150801_1001
(com.ibm.cftools.branding.ui 1.0.2.v20150801_1001)
To: package com.ibm.cftools.branding.internal 0.0.0
Cannot satisfy dependency:
From: IBM Bluemix Tools 1.0.5.v20150801_1001
(com.ibm.cftools.feature.feature.group 1.0.5.v20150801_1001)
To: com.ibm.cftools.branding.ui [1.0.2.v20150801_1001]
I checked this exception and found a description about it in the eclipse web page. However, the remedy is missing for this particular problem.
2). Besides I tried to install the same via WASdev, but I ended up with the following error:
No repository found at http://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/updates/cloud/V1.0
However, the same page is accessible from any web browser. Also, I have checked my proxies and they are fine.
Please let me know if there is any solution or what I am doing wrong here. Thanks.
Are you using Eclipse for Java EE Developers edition? It is required that edition to satisfy some bundle requirements.
A few pointers:
An Eclipse update site needs to have a site.xml - check if the location actually has one.
Your install error points to a missing jst component. That's Eclipse "core" stuff. So it seems your access to the original Eclipse update site needs to be checked
Check your Eclipse install, do you have rights to all the files?
Hope this helps
As mentioned, the error message you are receiving (not able to resolve "org.eclipse.jst.server.core") is due to the installation process not being able to locate this package. This package is provided by the same Eclipse marketplace entry or DHE update site from which you are installing (and so you should not see this error when installing from our marketplace or update site). I have confirmed that the provided update site URL is correct and installation works as expected on my own Ubuntu installation.
A few other suggestions, or for users that see the same problem:
This may be a hiccup with DHE or with your connection to the update site. I would suggest trying the installation again.
Try a fresh install of Eclipse to ensure that no other dependencies are interfering with your installation. The Java EE package 'Eclipse IDE for Java EE Developers' available for download from Eclipse.org will include the required package that is mentioned in your error message (though as previously mentioned, this should not be necessary as this package is bundled with our update site/marketplace entry).
Ensure you are NOT using the default version of Eclipse available from the Eclipse Software Center, which is often several versions behind.
If this doesn't help, feel free to provide more information about your current installation (version details, method of installation, any other details) to help us reproduce.
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 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'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.