Sharing Global Elements Across Mule Flows - mule-studio

What is the recommended way to permit import of global elements across flows. I am using mule studio version 3.4, by using the import tag I am able to access global elements defined in my but running the flow within mule studio generates following errors java.lang.IllegalArgumentException: A service named already exists.
<spring:beans>
<spring:import resource="name of flow xml where global elements are defined"/>
</spring:beans>
Is there an alternate way to share global elements?

Bit late to the party but I just came across this issue and it was because I had imported a common mule config into another config that was in the same project/application.
In my case I had a single project set up in AnypointStudio that had two configs with completely separate flows. On top of this I had a third config with "common" sub-flows that I use in the other two. This common config was also in the same project. I had imported the common config into the other two configs but this is unnecessary as it's already available to both if they're all in the same project. This seems to mean the common config is brought in several times causing conficts with the common flows elements names.
Long story short...try remove imports like this that are in the same project:
<spring:beans>
<spring:import resource="classpath:mule-common-config.xml" />
</spring:beans>

Encountered this issue while trying to run mule application from Anypoint Studio 6.4.2. I believe the error is mule's way of complaining that the XML resource has been imported already. Checking for any duplicate imports could help in tackling this issue.

If your mule-config.xml lies in a location , e.g. "packaged/serviceframework" then use below code snippet, i.e. by providing the path of the xml file instead of just the file name.
<spring:beans>
<spring:import resource="classpath:packaged/serviceframework/mule-config.xml" />
</spring:beans>

Related

Ecore EMF PackageNotFoundException

I have to work with a project I didn't wrote myself. It uses Ecore EMF (I have no experience with this) and I can't figure out how to solve this error:
At some point the program loads a .xmi file with this function: org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI()
And this results in this error:
org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri 'platform:/plugin/Animals/model/Animals.ecore' not found. (file:/C:/Users/model917.xmi, 2, 193)
It seems like the file model917.xmi exists and is not the origin of this error. I think the problem is caused because the Animals.ecore file is not found. In the model917.xmi file I found this statement:
xmlns: Animals ="platform:/plugin/Animals/model/Animals.ecore
So I think the model in file model917.xmi uses another model defined in Animals.ecore which can't be found and causes the error.
I have access to the Animals.ecore file and found out that EMF/ecore uses something like a registry to find such files. So it seems like I have to add the Animals.ecore file to this registry and I found some answers online which didn't work and I run out of ideas what to try next. Can someone give me an easy way to register this file so it will be found? I am using Eclipse if this is relevant/maybe there is an easy way to do it with Eclipse.
Usually, EMF-based softwares should rely on the so-called "namespace URI" (nsURI) of EPackages, which are usually of the form "http://foo/bar/Animals".
"http://foo/bar/Animals" should be registered in the EMF Registry and dispatch depending on your actual runtime situation to a URI that looks like "platform:/plugin/bar.foo/Animals.ecore" (when file Animals.ecore is deployed in an Eclipse plugin for an Eclipse-based application), or "platform:/resource/bar.foo/Animals.ecore" (when file Animals.ecore is deployed in the workspace of the running Eclipse-based application) or even "file:///path/to/Animals.ecore" (anywhere on the filesystem).
Technically you can use any of those URI forms as long as they are correctly resolved at runtime, but you must understand that not all URIs make sense in all contexts, for instance "platform:/" URIs only make sense in Eclipse-based context. nsURIs are supposed to be resolveable in all contexts (thanks to the registry!)
Is your code meant to be running in the context of an Eclipse-based application ? Then the project containing Animals.ecore should be deployed as a plugin, and I am guessing it is currently not.
Is your code meant to be standalone? Then the reference in your xmi file, to the ecore file, should not be of the form "platform:/..." but rather of the form "http://foo/bar/Animals" (the nsURI of the EPackage that is the root element of Animals.ecore)

Use TeamCity 9 REST API to turn on Versioned Settings

I like to turn on Versioned Settings for my TeamCity projects, so that it commits its configuration in XML to the source control. However now I am seeking to do some automation around project creation leveraging the REST API. However, I can't figure out a way to turn on Versioned Settings via this API. Does anyone know how to do this? Is it supported?
This is not a direct and full answer yet, because it does not use the REST API, but this is an (admittedly hacky) way to accomplished the same thing in an automated way—and perhaps it will lead to a way to do it more properly through the API. Turns out that the file which stores this configuration is config\projects\<project-id>\pluginData\plugin-settings.xml under the TeamCity Data Directory. The documentation, under the section on Direct Modifications of Configuration Files says,
The files under the config directory can be edited manually (unless explicitly noted). The changes will be taken into account without the server restart. TeamCity monitors these files for changes and rereads them automatically when modifications or new files are detected. Bear in mind that it is easy to break the physical or logical structure of these files, so edit them with extreme caution. Always back up your data before making any changes.
Please note that the format of the files can change with newer TeamCity versions, so the files updating procedure might need adjustments after an upgrade.
I found that if I write this XML to said configuration file
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<versionedSettings rootId="Bitbucket" enabled="true" showChanges="true" buildSettings="PREFER_VCS" />
</settings>
then it not only registered the setting, but actually went ahead and did the initial commit of the settings. That's a win, though I still wish I could do it through a more stable API. Note: this XML will be different depending on the precise setup of your version settings—this represents my preferred configuration.
If anyone knows how to take this to the next level by doing it through the API I would still appreciate it.
If it is an option to upgrade to TeamCity 10 (which it is for me), it appears that TeamCity 10 supports this though the REST API! I will confirm that it solved what I needed after doing the upgrade.

How can I deploy an upgrade of my product which contains a file with version lower than the already deployed file?

I have a msi component which deploys a file MyFile.dll. I have a test machine in which my product already deployed MyFile.dll, which has version 09.99.99.99.
Now I'm writing a major upgrade which will deploy a new version of MyFile.dll with version 05.23.76.123. After execution on the test machine, MyFilee.dll is removed... I need to change or repair to correctly deploy it.
How can I force the deployment of MyFile.dll regardless of its injected version number?
PS: This is happening on our test machines only. The product we delivered to our users has files with version numbers consistent with release history.
There are several ways in Windows Installer to do this but they all have their complications. IMO I would just rebuild the same source code as the old DLL but with a newer higher version and keep it simple.
This is perfectly possible. As said here, you may specify the REINSTALLMODE property and set it to "amus" or "dmus" depending on whether you want to always overwrite files or simply overwrite files with different version:
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
Note that you'll get this warning when compiling your installer though:
warning LGHT1076: ICE40: REINSTALLMODE is defined in the Property table. This may cause difficulties.
Downgrading a file isn't really straightforward and has issues. As pointed out earlier, you can change the component GUIDs and get this to work. However, it really depends on where your RemoveExistingProducts is sequenced. If its sequenced at a point where the older product is removed and the newer product is installed, then it might work.
There is not really a straight forward and documented way. All the available options are just hacks.
Is this just for your test environment?
If yes, then you could use REINSTALLMODE="amus" in the property table and achieve what you are looking to.
However, this is just for your testing and is not advised to be suggested to your end users.
Regards,
Kiran Hegde

Getting Error: Object of type 'archiveDir' and path '....vbproj.zip' cannot be created while doing Packageweb configuration with teamcity

I am trying to configure packageweb with teamcity. But getting the following error:-
I am passing it the parameters for publishing and also it is not transforming the config file. even that parameter is mentioned in the file. any idea what I am doing wrong here.
PAcakgeweb ref: http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx
I ran into a similar problem, so while I'm sure you don't have a use for this answer eight months later, I will post this anyway in case someone else experiences the same issue.
Assuming that you're using TeamCity to compile your project, you'll need to add the PackageWeb targets file into the web project file so that it runs the SlowCheetah transform s at compile time.
For me, this meant unloading the web project in Visual Studio and adding in the following imports target right down at the bottom of the file, just before the closing /Project tag;
<Import Project="_Package\Sedodream.Package.targets" />
You can read more about this here and here.

Strange GWT Error with external jar on server side

I want to use a external jar (Apache Mahout) on the server side of my GWT Applicatopn.
As far as i know using external jars on the server side shouldn't cause an error. Only on the client side but when i try to run the code i get the following error:
"no source code is available for de.unimannheim.paniscus.server..."
Whats wrong here ?
Please help me i need to solve this for my thesis
Hi guys i created now an collbaorative.gwt.xml where i inherited all classes from apache mahout that are used within de.unimannheim.paniscus.server.collaborative but it's still not working. Sorry i'm helpless whats wrong here ?
I agree with Dusty Campbell, you should not inherit the jar in the *.gwt.xml. The <inherits> tag in the *.gwt.xml specifies gwt-modules which should be inherited. So only client-side-compatible code can be inherited.
Citation from the gwt docs: "<inherits name="logical-module-name" /> : Inherits all the settings from the specified module as if the contents of the inherited module's XML were copied verbatim. Any number of modules can be inherited in this manner"
see also: http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html#DevGuideInheritingModules
My guess is that you (by mistake) use a class from the "de.unimannheim.paniscus.server" package in client-side or shared code. Even just an import statement (import de.unimannheim.paniscus.server.*) will cause this exception.