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

[Eric Wittmann (JIRA)]

    [ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984692#comment-12984692 ] 

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).


> Maven repository facade. Add extended type
> ------------------------------------------
>
>                 Key: SRAMP-506
>                 URL: https://issues.jboss.org/browse/SRAMP-506
>             Project: S-RAMP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: David virgil naranjo
>            Assignee: David virgil naranjo
>
> It is necessary to add the possibility of setting a different s-ramp type.
> By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)