[jira] Resolved: (SM-1977) Support exploded JBI artifacts

["Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>]

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

Jean-Baptiste Onofré resolved SM-1977.
--------------------------------------

    Resolution: Won't Fix
      Assignee: Jean-Baptiste Onofré

1/ We should stay JBI spec compliant
2/ JBI is quite deprecated

> Support exploded JBI artifacts
> ------------------------------
>
>                 Key: SM-1977
>                 URL: https://issues.apache.org/jira/browse/SM-1977
>             Project: ServiceMix
>          Issue Type: New Feature
>          Components: servicemix-core
>            Reporter: Jean-Baptiste Onofré
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 3.3.3
>
>
> For example, in JBoss application server, you can deploy JEE artifacts in an exploded format.
> In place of deploying a file my.ear or my.war, you can deploy a directory my.ear or my.war. The JBoss deployer is able to see in the resource is a ZipEntry or a Directory.
> I could be interesting to do the same in the ServiceMix and NMR deployer around JBI artifacts.
> The users could be able to deploy a sa.zip directory containing su.zip directories.
> Like this, it's possible to easily change the xbean.xml without repackaging and regenerating the zip files.
> To achieve this, we need:
> - to upgrade the deployer in ServiceMix 3 and NMR to detect if the artifact is a ZipEntry or a directory
> - to upgrade the jbi-maven-plugin to provide an exploded JBI artifact (without the zip packaging)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira