2

I am consuming SOAP web services in my application. I am generating jaxb classes using maven by providing wsdl at build time. Now these wsdls are getting changed for each higher environement i.e. Dev, Integration, Stage and Prod.

That means I will have to build my project everytime I move up the environment. This would violate the deployment rule - The tested build should be moved up the environment till Prod.

How can I avoid rebuilding of the application everytime I move up the environment and also have jaxb classes as per wsdl of that environment.

Khuzi
  • 2,792
  • 3
  • 15
  • 26
  • You should not change WSDL for different environments. – lexicore Mar 13 '18 at 08:02
  • I do not own the web service part. I am just a consumer. The team which is exposing web services have different wsdl url for different environment however, the wsdl structure and everything else is same. – Khuzi Mar 13 '18 at 13:04
  • @Khuzi did you manage to solve your issue? if not please check https://stackoverflow.com/questions/2490737/how-to-change-webservice-url-endpoint – Tinus Jackson Mar 12 '19 at 08:39

2 Answers2

2

I believe that it is not possible to change JAXB classes without a re-build. But, here I am wondering whether the structure of the WSDL (not taking about data values) is changing from environment to environment? If it is all together a different WSDL, obviously you need a fresh build.

In the above scenario, you may use Maven Profile feature.

If it is the same WSDL (only data values changes as per environment), then it is your code logic should be generic enough to work with different possible data values. If it is so, a single build should be working in all the environment.

EDIT - As per Op comments

Yes I am using maven profile for environment based build. And, the wsdl structure is going to be same across the environments so code break is not a problem. I was just wondering if there is way to this scenario.

As per the comments, I feel that it is not a build related area, but related to deployment of an artifact with below assumption:

  1. Once tested in test environment, the build would work perfectly in other environment.
  2. The build would be able to pick right internal config based on a parameter provided externally. e.g. If Java app build is having a env-dev.config and env-prod.config files, then based on a JVM flag -Denv=prod; it should pick right config file at runtime.

With this assumptions, you do not need a maven profile. Now coming to deployment, you may use some kind of webstore. e.g. a maven repository. The deployment script should pick the artifacts from the webstore and deploy it.

The process flow may be summarized as:

  • Use a CI (continuous integration) tool like Jenkin to make a test build.
  • In the CI tool, make a provision to upload the artifacts to webstore as part of post-build step. E.g. You may upload to your local maven repository server.
  • As part of deployment, the deployment script would get the artifacts from webstore and deploy on the test environment.
  • Deploy the artifact on test environment through above mechanism. Perform the testing.
  • If a bug is found during testing, fix the bug and re-build/deploy through CI tool.
  • Again use CI tool for stage/prod deployment. Please note that you need to simply skip build process. This would be a deployment-only process.
  • The deployment process should always pick latest (or a configurable version). So, version control is an important aspect.
Gyanendra Dwivedi
  • 5,511
  • 2
  • 27
  • 53
  • Thanks. Yes I am using maven profile for environment based build. And, the wsdl structure is going to be same across the environments so code break is not a problem. I was just wondering if there is way to this scenario. – Khuzi Mar 13 '18 at 03:30
  • @Khuzi I have added a way to do this. Please check. – Gyanendra Dwivedi Mar 13 '18 at 15:39
  • CI is already in place for my application. The artifacts are getting stored in Artifactory and getting delpoyed from there using Jenkins. And there is no build for stage and prod, just deployment. This does not solve my problem. But after lot of research I understand, this is not a problem in-fact. I would go ahead with QA tested build to be deployed on stage and prod without rebuilding it. Let there be QA generated Jaxb classes on stage and prod. Thanks for taking efforts though for digging into this scenario. – Khuzi Apr 05 '18 at 18:42
2

Try using maven to FILTER PROPERTIES in wsdl files during the build process. For your example, you could replace the ${ws.url} placeholder in your WSDL with the corresponding value from your properties file by including the replacement text in your pom file.

mhasan
  • 3,703
  • 1
  • 18
  • 37