In this topic
About versioning your add-ins
The following guides you through the process of deploying two different versions of the same add-in project. The project contains a single button that in version 1.0, prints a "Hello, World!" message and version 2.0 prints a "Hello, World! Version no. 2" message. Versioning is significant because you do not need to create two separate projects to achieve the preceding workflow. The same project can be re-used and re-deployed with the updates getting pushed to your users. Depending on the deployment method you choose and the various approaches, see How to deploy your add-in. The scenario will be illustrated in the following workflow.
Verifying the initial add-in project works
Assuming you have already created an add-in project following the instructions in How to create an add-in project in Eclipse and a button following the directions in How to create an add-in button, this step is a little redundant; however, still valuable in cases where there has been time between the first version and the update you are looking to do now. In addition, testing and ensuring functionality gives you a base moving forward with modifications. Here are some additional considerations for this step in the process:
- Deploy and test your add-in on a machine using the same workflows used by the individuals who use the add-in you created.
- Backup your existing Eclipse add-in project in case you need to roll back to the previous working project.
- If errors exist in your current version of the add-in, make sure you can reproduce the case in your development environment. Do not fix the code before taking a snapshot.
To verify the add-in functionality, deploy the add-in, then test it.
Making improvements or adding new functionality
Now that you have a snapshot of your first version of the add-in, the next step looks at implementing your new functional requirements or making improvements to existing functionality. In this step, make any of the changes that are required in your existing project. You do not need to create a project; access your existing project and make the necessary changes. The following are some additional considerations for this step in the workflow:
- If you have many fixes that need to go into the next version of your add-in, try not to solve all of the fixes at one time. It is better to systematically fix one issue at a time and proceed to Step 3 and 4 of this workflow on the first testing iteration, then directly to Step 4 in subsequent testing iterations.
- Try to fix existing issues with your add-in first, then move on to new functionality second. Introducing new functionality without fixing existing issues might added additional unknowns into the equation when debugging broken source code.
- If you have many new functional pieces to add to your project, then add one piece of functionality at a time following the same pattern proposed.
In the scenario described, you need to replace the line of code that defines the JOptionPane message dialog with the following string: "Hello, World! Version no. 2." for version 2.0 of the add-in project. The code will look like the following in your button’s onClick() method:
[Java]
@Override public void onClick()throws IOException, AutomationException{
JOptionPane.showMessageDialog(null, "Hello, World! Version no. 2.");
}
Save the changes you’ve made in Eclipse and proceed to the next step.
Changing the version number
In the add-in editor for your Eclipse project, a version property exists. The version property allows you to set the version number for your add-in project. By default, the first version is set to version 1.0; however, it is possible to version your add-in starting at 0.1 and working your way up to version 1.0. If you used the default version number when creating the add-in project initially, then you can increment the version number to create a newer version of your add-in (for example: 1.1 or 2.0). The framework is flexible to both cases when increasing the version number of your add-in project. The convention used should follow the standard set in your organization.
For the previous scenario, simply change the version from 1.0 to 2.0 and save your Eclipse project.
Re-deploying the add-in
The following step requires you to re-deploy your add-in using one of the methods described in How to deploy your add-in.
Testing your update
Open up the ArcGIS Desktop application that the add-in was designed for and test it using the same workflow(s) that you expect the users to follow. If the testing does not succeed, then return to Eclipse and fix your code, re-deploy, and test again (note that on the second iteration you do not need to change the version number – this item only needs to be updated once in this workflow). Here are some considerations for this step of the process:
- Test workflows you expect your users to use when using your add-in.
- Try special cases to ensure your code covers the generic cases (if applicable) and that you do not make any assumptions in your code. For example, you might have the user browse for some vector data and they might accidentally select raster data. Your add-in should ideally be able to detect this type of an error and provide an appropriate message to the user.
- Test extreme cases. For example, if your add-in is designed to copy 1 feature class from one location to another, try copying 10, 20 or more.
- Re-test existing functionality to ensure it is fixed in your latest version.
Sharing the new version
The following step requires you to distribute your add-in using one of the methods described in How to deploy your add-in.
| Development licensing | Deployment licensing |
|---|---|
| ArcView | ArcView |
| ArcEditor | ArcEditor |
| ArcInfo | ArcInfo |