[jira] [Updated] (NPANDAY-536) Ability to map different role properties when packaging an Azure cloud service

["Brett Porter (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NPANDAY-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brett Porter updated NPANDAY-536:
---------------------------------

    Fix Version/s: Backlog

> Ability to map different role properties when packaging an Azure cloud service
> ------------------------------------------------------------------------------
>
>                 Key: NPANDAY-536
>                 URL: https://issues.apache.org/jira/browse/NPANDAY-536
>             Project: NPanday
>          Issue Type: Improvement
>    Affects Versions: 1.5.0-incubating
>            Reporter: Brett Porter
>             Fix For: Backlog
>
>
> In the current implementation, the call to CSPACK will always use the artifact ID for the rolename of a dependency that is a web or worker role. However, this may not be the case - so it should be possible to create a mapping, and to generate that with the project importer.
> Likewise, currently a single framework version can be passed to the azure plugin and is used to populate the role property for each dependency, but it may be possible that the project was from a different SDK version. This can be hard to detect from the artifact, unless additional data is written to the repository, but it could be configurable as above.
> Something like the following would be suitable:
> {code:xml}
> <roleMappings>
>   <roleMapping>
>     <artifactId>My.WebRole</artifactId>
>     <roleName>WebRole</roleName>
>     <frameworkVersion>3.5</frameworkVersion>
>   </roleMapping>
> </roleMappings>
> {code}
> Alternatively, the packaging plugins could generate this information and store in the local repository, then retrieve it as part of the packaging process to create the right role properties file - but it may be difficult if some dependencies need to be used after this was originally considered.



--
This message was sent by Atlassian JIRA
(v6.2#6252)