I have a fairly complicated build workflow for one of my Jenkins builds. The project contains two modules. Module M1 builds a service and module M2 builds the service client. M1 is dependent on M2 (don't ask me why). M2 needs stubs created from the ejb's in M1. So we are at an circular dependency which I tried to circumvent with following build order.
when running the final install, it bombs with:
[INFO] [install:install {execution: default-cli}]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The packaging for this project did not assign a file to the build artifact
[INFO] ------------------------------------------------------------------------
So I came up with the idea, that since I already use Jenkins and I am deploying anyway to our snapshot directory, I have nothing to worry and I can leave out the local deployment since it will pull the newer version from the snapshot repo anyway. The result was, that Jenkins archives the artifact for the job after it ran the install. Since I didn't run the final install, the version without stubs was deployed (from step 2 I believe).
Then, I configured the Jenkins job to explicitly archive my service client jar with the post build option in addition to the automatic archiving feature of the maven integration. The result was, that I had the service client jars archived for the Jenkins job. One was one the Project level (the desired version with stubs) and one on M2 (w/o stubs). Of course the version without stubs was deployed.
Any idea how I can get out of this dilemma, without changing the project structure. I can add stuff to the pom files as long as the developer desires are still fulfilled. The Jenkins job is my domain.
It sounds like you need to reorganize. Is it possible to factor out the server->client dependencies in the client into a separate jar, and change the dependency on the client to a dependency on this new jar?