Bug 1128720 - DTGov: Artifact undeployment not using classifier/type info
Summary: DTGov: Artifact undeployment not using classifier/type info
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: DT Governance
Version: 6.0.0 GA
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR1
: FUTURE
Assignee: Eric Wittmann
QA Contact: Stefan Bunciak
URL:
Whiteboard:
Depends On:
Blocks: 1146192
TreeView+ depends on / blocked
 
Reported: 2014-08-11 12:07 UTC by Eric Wittmann
Modified: 2025-02-10 03:42 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 03:42:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1030518 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1030518

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 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
Verified

Comment 12 Red Hat Bugzilla 2025-02-10 03:42:44 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


Note You need to log in before you can comment on or make changes to this bug.