[overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type

[ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.... ] Eric Wittmann edited comment on SRAMP-506 at 7/14/14 8:24 AM: -------------------------------------------------------------- Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want. I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin. The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places: * META-INF/maven/groupId/artifactId/pom.xml * META-INF/MANIFEST.MF * META-INF/maven/groupId/artifactId/pom.properties I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary. The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them). was (Author: eric.wittmann): Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want. I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin. The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places: * META-INF/maven/${groupId}/${artifactId}/pom.xml * META-INF/MANIFEST.MF * META-INF/maven/${groupId}/${artifactId}/pom.properties I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary. The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them). -- This message was sent by Atlassian JIRA (v6.2.6#6264)