|Summary:||DTGov: Artifact undeployment not using classifier/type info|
|Product:||[JBoss] JBoss Fuse Service Works 6||Reporter:||Eric Wittmann <eric.wittmann>|
|Component:||DT Governance||Assignee:||Eric Wittmann <eric.wittmann>|
|Status:||VERIFIED ---||QA Contact:||Stefan Bunciak <sbunciak>|
|Version:||6.0.0 GA||CC:||ppecka, rwagner, sbunciak, soa-p-jira|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Eric Wittmann 2014-08-11 12:07:04 UTC
Description of problem: When deploying an artifact we first try to undeploy the previous version. This is not currently taking into consideration the classifier or type. The result is that if artifact.jar is deployed followed by artifact-classes.jar, we end up undeploying artifact.jar. Version-Release number of selected component (if applicable): FSW 6.0.0.GA How reproducible: Always Steps to Reproduce: 1. Set up DTGov to deploy JavaArchive artifacts use file copy for the deployment target config. 2. Deploy an artifact from maven where the maven project is configured to also produce -classes.jar and -sources.jar (for example) Actual results: The target deployment directory *should* have three artifacts: a) artifact.jar b) artifact-classes.jar c) artifact-sources.jar Expected results: The target deployment directory will only have one artifact: a) example: artifact-sources.jar The actual artifact may vary depending on the config of the maven pom.
Comment 1 Eric Wittmann 2014-08-11 12:11:40 UTC
I fixed this and commited the change to the product branch for FSW 6.0.
Comment 2 Rick Wagner 2014-08-11 18:53:25 UTC
Hi Eric, Can you please supply a commit id? Thanks, Rick
Comment 3 Eric Wittmann 2014-08-11 19:03:29 UTC
Comment 5 Eric Wittmann 2014-09-22 13:41:52 UTC
My original Steps to Reproduce for this issue is flawed and confusing (because I am flawed and confused). My apologies. Updated here: Steps to Reproduce: 1. Set up DTGov to deploy JavaWebApplication artifacts using file copy for the deployment target config. 2. Set up DTGov to *not* deploy JavaArchive artifacts 3. Deploy a WAR project artifact using maven (mvn deploy) where the maven project is configured to also produce -classes.jar 4. Once deployed via maven, the S-RAMP repository will contain two artifacts: project-v1.war, project-v1-classes.jar 5. DTGov will kick in and deploy the project.war artifact 6. The result will be a single deployed artifact (project.war) in the target file location 7. Now increment the maven version in the project's pom.xml 8. Do another "mvn deploy" 9. S-RAMP will now have two more artifacts: project-v2.war and project-v2-classes.jar 10. Dtgov will kick in and try to deploy project-v2.war. However, when it tries to find the previous version of project-v2.war it *MAY* find project-v1-classes.jar instead of project-v1.war. The reason for #10 is that the code was not considering that there might be multiple artifacts in S-RAMP with the same maven GAV coordinates but different classifiers.
Comment 6 Rick Wagner 2014-09-24 18:02:36 UTC
The status of this bug is in question. Eric, could you please validate if the source is on the 'product branch', and if so move this bug to 'MODIFIED'? Thanks, Rick
Comment 7 Eric Wittmann 2014-09-24 18:24:47 UTC
My mistake for not moving it into MODIFIED state. I have confirmed that the code exists in the latest patch (double-checked by testing *and* by decompiling the .class file in question).
Comment 10 Stefan Bunciak 2015-03-02 13:38:03 UTC