Resourcefiles deployment deadlock?

Hi!

I'm currently setting up a simple GitLab CI/CD pipeline for an API proxy, which works just fine. I'm using the apigee-config-maven-plugin and the apigee-edge-maven-plugin in combination. I'm updating proxy specific configurations (in this case only KVMs) first and then deploy the proxy.

Now I wanted to include a simple Java callout and I'm not sure how to do this, because I am getting conflicts regarding the revisions since both the proxy's revision and the resource file's revision have to match. When I'm trying to deploy the proxy first (which includes the Java callout policy), I'm getting an error that the JAR does not exist for this revision. When I'm trying to upload the JAR for the new revision first, I'm getting an error that the proxy revision does not exist.

I feel that this is some kind of deadlock and I'm not sure how to resolve this issue. What's the recommended way for this?

Thanks in advance

Solved Solved
0 5 157
2 ACCEPTED SOLUTIONS

I think the easy way out is to import the API Proxy with the resources it uses, including the JAR, all at once as a bundle. Then deploy the imported revision. I would think the maven plugins would do that for you. Not sure. Maybe @Sai Saran Vaidyanathan can comment.

Another way to avoid the problem is to upload the JAR as an environment-scoped or organization-scoped resource. Refer to it as you normally would in the Java callout.

View solution in original post

HI @Patrick Zinner

As @Dino-at-Google mentioned, you can package it within your proxy itself. Check this sample I have. In that sample, the callout directory has the Java code and a pom file. At the very end, the jar generated is copied to the bundle's resources/java directory. So in your pipeline, you can first trigger the callout pom file and then trigger the bundle's pom file. With that the latest jar is pushed to the code and then the other pom can package the overall apipoxy and push it to Apigee. With this you don't have to worry about using the Resource file operation and have conflicts with revision. This is much cleaner actually as you have complete control of what is getting deployed.

Let me know if it works or not. If there are still issues, let me know, we can discuss

View solution in original post

5 REPLIES 5

I think the easy way out is to import the API Proxy with the resources it uses, including the JAR, all at once as a bundle. Then deploy the imported revision. I would think the maven plugins would do that for you. Not sure. Maybe @Sai Saran Vaidyanathan can comment.

Another way to avoid the problem is to upload the JAR as an environment-scoped or organization-scoped resource. Refer to it as you normally would in the Java callout.

Yes, I did not see that this was possible. Thanks a lot!

HI @Patrick Zinner

As @Dino-at-Google mentioned, you can package it within your proxy itself. Check this sample I have. In that sample, the callout directory has the Java code and a pom file. At the very end, the jar generated is copied to the bundle's resources/java directory. So in your pipeline, you can first trigger the callout pom file and then trigger the bundle's pom file. With that the latest jar is pushed to the code and then the other pom can package the overall apipoxy and push it to Apigee. With this you don't have to worry about using the Resource file operation and have conflicts with revision. This is much cleaner actually as you have complete control of what is getting deployed.

Let me know if it works or not. If there are still issues, let me know, we can discuss

Thank you, works like a charm!

Glad it worked !