Custom Snap Pack versioning is broken?

organization’s shared folder is Project space’s / shared or project / shared ?

Can you provide some screenshot’s ?

@rpatrick00 when you referred as organization’s shared folder, is it global shared (shared) folder or projects/shared folder ?

Just to make sure we are focusing on the right issue, everything works fine as long as all of the different “versions” of the custom snap pack use the same VERSION number (in pom.xml, src/config/directives, and the snap’s @Version annotation).

Given that “built-in” snap pack versions are chosen at the global level (Manager => Snap Packs), my suspicion is that SnapLogic does not support versioning of custom snap packs where the version number itself is different.

Hi Robert.

Does the snap catalog show both versions of the pack? I would guess that it does. I think the idea with this scheme is to support deploying multiple distinct versions of a snap pack. If you prefer to replace an existing pack, you would use the same VERSION but a new build number.

So if you want to use the new version in your pipelines that have instances of the old version of the snaps, I believe you’d need to replace those older snap instances with new instances created using the new version.

Hope that helps.

Robert,

I’ve been testing this using a new snap pack created with our maven archetype.

I’ve been successfully able to update the version number and get the behavior you expect, where the new version just replaces the old one.

However, there are number of places where the version and build numbers need to match:

1. The VERSION property in the <properties> section of the pom. You’ve changed this to 2.
2. The sl_build property in the <properties> section. You’ve changed this to 1, correct?
3. The <version> at the top of the pom should be VERSION-sl_build, so in your case 2_1.
4. The VERSION in the config/directives file should be 2.
5. The @Version annotations on all of the snaps and accounts should have snap = 2.

Can you please verify all of that?

@ptaylor I can confirm all of this. I am able to see the new version of the snap but it seems like I am still picking up the old version’s custom account… ☹️

@ptaylor I am not sure what to say but I am seeing a problem.

In my release 1 branch (the one deployed in the global shared folder), line 78 of OdysseyApiAccount looks like this:

        if (String.class.isAssignableFrom(valueObj.getClass())) {

In version 2 of the OdysseyApiAccount, line 78 looks like this:

    private static final String PASSWORD_LABEL = "Password";

When I create the pipeline in my projects/Robert Patrick folder (where V2 of the snap is deployed), I am getting the following NullPointerException.

Pretty sure this proves that Version 1 of the Account class is being used…

@ptaylor here is what I have found:

1. I restarted by two groundplex servers and verified that no versions of the snaps are downloaded to either server.
2. I have version 1_47 deployed at the global shared level and 2_5 deployed at projects/Robert Patrick
3. I created a new pipeline in projects/Robert Patrick
4. I added a custom snap to the pipeline.
5. I created an account in projects/Robert Patrick and validated it
6. I configured the rest of the snap and added a JSONGenerator and Mapper
7. I still get the NullPointerException at line 78 in OdysseyApiAccount
8. When I look at the groundplexes, I see both 1_47 and 2_5 have been downloaded even though I am pretty sure that I am the only one using it right now…

@ptaylor thanks.

The other clue that I can give you is that if I change the new version numbers from 2 back to 1 and redeploy like this, everything works fine. I know the new version is picking up the new Account version because I have extra data in the new account version that the snaps depend on for “suggestions” and the suggestions are working in this configuration.

If I clear out everything and switch the version numbers back to 2, it doesn’t work.

@ptaylor I suppose, though it is certainly not desirable… Thanks for your help!