I’m working on an application that consists of a base package and an extension package. Every time I update the base package in the development environment, I have to change the
<packageVersions> element in the metadata of some of the classes in the extension, so they use the latest version. Is it possible to specify that a class always uses the latest version of a package?
Update: We don’t really have a build process. I use Eclipse with the Force.com Perspective to develop the application and the extension. If a new version is released I use the standard Salesforce interface with a web browser (just via Setup -> Create -> Package -> etc..) After the new release is uploaded I install it in the development org for the extension. Maybe I would have to create an extra function in the install script that uses the metadata API to update the metadata of the org in which the package is installed?
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
At the risk of proposing a very low-tech but low-effort solution, what about just a simple script that (in your local, recently sync’d Eclipse workspace) traverses all your relevant
*-meta.xml files and does a simple string sed-like operation to bring them to your current version? Then you just do a top-level refresh in Eclipse, and all the files get uploaded that have been changed.
I know it’s low-tech, and that using some custom code around the metadata API is the “correct” approach, but you use Eclipse without a build process so this seems like the most simple solution to a not very complicated problem.
With a little modification, you could use my Ruby script to walk the file system with my namespacing script and update the metadata of package components to update them.
The script is here: https://github.com/jordanbaucke/sfdc-namespace-prefix
I will say that this is tentatively possible. But it will depend alot on your current build process.
The only way to achieve what you are suggesting is with the metadata api. You would need to push new versions of your *.cls-meta.xml files
One of the most common build tools for ISV’s is Jenkins (This is what my company uses) and Jenkins is great for something like this.
This is where your build process matters. There are a number of libraries that you can use to invoke the metadata api, whatever you choose you will then need to integrate into your build process somehow. I understand this is not a complete answer but without further details there isn’t much more I can suggest.
If you don’t have an automatic build process, then you are free write something in the language of your choice and run it manually as another step of your manual build.
The first think I would do is, if you are a Salesforce ISV partner, ask to get major push upgrades enabled, this will make installing the package into your extension orgs much easier
Then you can run the script to update the classes (and presumably pages triggers etc).
The last consideration I would make is: Your process might be manual now, but if your business grows that might not be as feasible make sure the scripts you write can be integrated into some sort of automatic build process (reiterating Jenkins is great)
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0