Answers: <p>I figured out how to get this job to run which took a number of very specific steps:</p>
  
  <p>1) The Maven3-Artifactory plugin will simply not do what I need it do here.  I still need this in my job though to actually execute my custom maven plugin from the project POM.  I configured the Build Environment for this plugin to NOT upload any build artifacts to Artifactory.</p>
  
  <p>2) I added the Generic Artifactory plugin that has the responsibility of taking the zip artifact from the Maven plugin and uploading it to our Artifactory repo.  I <strong>struggled</strong> to define an upload FileSpec that worked correctly.  I ended up using the Legacy Patterns option where I could define the upload artifact and the repo location based on a number of Environment Variables that have been already defined for me previously (more info on this in future steps).  The Download Details are effectively empty.</p>
  
  <p>3) The first Build Step is execution of the Maven build.</p>
  
  <p>4) The second build step is execution of a custom shell that will parse the maven build artifact zip file for information that is needed to derive the version number.  It then injects this version number into a temporary property file in the root of the job workspace.</p>
  
  <p>5) The third build step uses the Inject Environment Variables plugin to put the temporary property file into environment variables used by the Generic Artifactory Plugin Legacy Pattern.</p>
  
  <p>This seems to work well as a solution for my situation.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-05-30T14:19:31.820Z
Answers: 2018-05-30T14:19:31.820Z
Answers: maple_shaft
Body: <p>I am currently working on a custom Maven plugin that generates a build artifact in the form of a zip file with a dynamic version or build number.  The format of the file is something like</p>
  
  <pre><code>target/[artifactId]_[version or build].zip
  </code></pre>
  
  <p>Where [version or build] parameter is dynamically generated based on a snapshot of time, (Eg. [changeset24]-[changeset57]) on a parameterized Jenkins build where the user of the build will not necessarily know the latest changeset.  The plugin uses an API to determine the latest changeset, for example changset57, and then uses the starting changeset parameter to form the unique version/build of the zip artifact.</p>
  
  <p>This is meant to be a solution for streamlining the chaotic and manual process we face in our enterprise around delta based SQL scripts on hugely complicated schemas.  There is no clear promotion path up through environments for a single versioned database artifact.  It is a long story with a very immature devops organization and many frameworks and skill sets that do not mesh well, so I will spare the rest of the details here.</p>
  
  <p>Ultimately we need to specify not the JAR artifact for this build to upload to Artifactory, but the ZIP file that is being created here, however Maven does not seem to allow for us to change the hard coded <code>&lt;version&gt;</code> in the POM file, and even if we could, we need the ability to:</p>
  
  <ol>
  <li>Run the Maven build with custom plugin execution goal</li>
  <li>Parse the output file for the unique version number that is generated</li>
  <li>Override the <code>${VERSION}</code> or <code>${BUILD_NUMBER}</code> environment variables in Jenkins</li>
  <li>Upload the artifact to Artifactory with the new environment variable for version or build number being included in build info.</li>
  </ol>
  
  <p>The problem I have is that I seem to have trouble figuring out how to configure these 4 steps with the existing Maven3-Artifactory Jenkins plugins, nor with the Generic Artifactory Plugin using FileSpec JSON.  I don't see how I can inject a custom shell script to override environment variables here either between this process.</p>
  
  <p>Does anybody have any good suggestions of how I should configure this job?</p>
  
  <p><em>NOTE: Please don't suggest that my general approach is fundamentally bad or flawed or whatever.  That is not helpful because I am facing numerous technological and political constraints that prevent a more appropriate solution.</em></p>
  
Tags: <jenkins><maven><artifactory>
Title: Jenkins Artifactory Integration - Custom Maven plugin creating dynamic version/build
UserDisplayName: maple_shaft
ThreadText: # Jenkins Artifactory Integration - Custom Maven plugin creating dynamic version/build
  
  (Asked by: username_0 on 2018-05-21)
  
  I am currently working on a custom Maven plugin that generates a build artifact in the form of a zip file with a dynamic version or build number. The format of the file is something like
  
  ```
  target/[artifactId]_[version or build].zip
  
  ```
  
  Where [version or build] parameter is dynamically generated based on a snapshot of time, (Eg. [changeset24]-[changeset57]) on a parameterized Jenkins build where the user of the build will not necessarily know the latest changeset. The plugin uses an API to determine the latest changeset, for example changset57, and then uses the starting changeset parameter to form the unique version/build of the zip artifact.
  
  This is meant to be a solution for streamlining the chaotic and manual process we face in our enterprise around delta based SQL scripts on hugely complicated schemas. There is no clear promotion path up through environments for a single versioned database artifact. It is a long story with a very immature devops organization and many frameworks and skill sets that do not mesh well, so I will spare the rest of the details here.
  
  Ultimately we need to specify not the JAR artifact for this build to upload to Artifactory, but the ZIP file that is being created here, however Maven does not seem to allow for us to change the hard coded `<version>` in the POM file, and even if we could, we need the ability to:
  
  1. Run the Maven build with custom plugin execution goal
  2. Parse the output file for the unique version number that is generated
  3. Override the `${VERSION}` or `${BUILD_NUMBER}` environment variables in Jenkins
  4. Upload the artifact to Artifactory with the new environment variable for version or build number being included in build info.
  
  The problem I have is that I seem to have trouble figuring out how to configure these 4 steps with the existing Maven3-Artifactory Jenkins plugins, nor with the Generic Artifactory Plugin using FileSpec JSON. I don't see how I can inject a custom shell script to override environment variables here either between this process.
  
  Does anybody have any good suggestions of how I should configure this job?
  
  *NOTE: Please don't suggest that my general approach is fundamentally bad or flawed or whatever. That is not helpful because I am facing numerous technological and political constraints that prevent a more appropriate solution.*
  
  **Tags:** jenkins, maven, artifactory
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2018-05-30. Score: 1 | Accepted answer
  
  I figured out how to get this job to run which took a number of very specific steps:
  
  1) The Maven3-Artifactory plugin will simply not do what I need it do here. I still need this in my job though to actually execute my custom maven plugin from the project POM. I configured the Build Environment for this plugin to NOT upload any build artifacts to Artifactory.
  
  2) I added the Generic Artifactory plugin that has the responsibility of taking the zip artifact from the Maven plugin and uploading it to our Artifactory repo. I **struggled** to define an upload FileSpec that worked correctly. I ended up using the Legacy Patterns option where I could define the upload artifact and the repo location based on a number of Environment Variables that have been already defined for me previously (more info on this in future steps). The Download Details are effectively empty.
  
  3) The first Build Step is execution of the Maven build.
  
  4) The second build step is execution of a custom shell that will parse the maven build artifact zip file for information that is needed to derive the version number. It then injects this version number into a temporary property file in the root of the job workspace.
  
  5) The third build step uses the Inject Environment Variables plugin to put the temporary property file into environment variables used by the Generic Artifactory Plugin Legacy Pattern.
  
  This seems to work well as a solution for my situation.
  
  
  ---
  
  