[wildfly-dev] Managed exploded deployments

[Emmanuel Hugonnet]

On 10/06/2016 17:06, Brian Stansberry wrote:
> On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote:
>>
>>
>> On 10/06/2016 16:22, David M. Lloyd wrote:
>>> On 06/10/2016 08:38 AM, Brian Stansberry wrote:
>>>> Emmanuel Hugonnet has been working on a long requested feature to have
>>>> WildFly support "managed exploded deployments." We have a requirements
>>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
>>>> I just wanted to point that out to the list so anyone interested can
>>>> have a look, and comment on this thread or on the document.
>>>>
>>>> A managed deployment is one where the user provided content is copied by
>>>> the server/host controller into its internal content repo and then
>>>> thereafter that copy is what is used. I estimate that 99%+ of all zipped
>>>> deployments in WildFly are managed. With an unmanaged deployment the
>>>> user provides the server with the local FS path to the content and then
>>>> the server directly uses that content. All exploded deployments are
>>>> unmanaged, as we don't support managed yet.
>>>>
>>>> We propose to add 5 new operations to the deployment resource:
>>>>
>>>> explode (to convert and archive deployment to exploded)
>>>
>>> Hmmm.
>>>
>>> Is deployment explosion really an deployer concern, or is it a
>>> deployment provider concern?  Consider:
>>>
>>> * The deployment provider is the one who will know whether or not
>>> his/her deployment will function correctly with or without exploding.
>>> * The deployment will have been tested in the desired configuration
>>> (exploded or unexploded).
>>> * Making this a deployer/administrator concern means that he/she must
>>> ensure that the extra step(s) taken in development and testing are also
>>> replicated in production.
>>>
>>> Wouldn't it make more sense to have some deployment control metadata
>>> (maybe even just a MANIFEST header) that says whether the particular
>>> archive should be exploded?
>>>
>>> Also, I don't think it's clear that you always want to explode the outer
>>> archive if an inner archive is to be exploded (I'm not sure that's
>>> necessarily implied by the proposed design, but it certainly would be in
>>> the recursive case).  In particular it's definitely useful to explode
>>> WARs inside of EARs that need not be exploded.
>>>
>>> Explode!!
>>>
>>> (eom)
>>
>> I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in a development environment. so this mecanism is
>> transparent from the developer point of vuiew.
>> You have the same functionalities as with the scanner with hopefully a better control over the deployment management.
>> Also this means you can develop on a remote server or even on a domain without having to rebuild the whole archive everytime.
>>
> 
> So would you use the 'explode' operation in your netbeans plugin, i.e. 
> start archived and explode? I'm curious if the JBDS guys will.

Well it depends. On NetBeans you have a "Deploy on Save" checkbox so that the 'build' (since the build process it externalized in Netbeans)
will no longer produce an archive but a list of changes.
So I might need to explode the deployment somewhere in time.


> 
> I suspect it would be used as a convenience; i.e. instead of the tool 
> initially uploading 100 files, it uploads a zip and explodes it. And 
> then either way it begins to manipulate the few files that the tool 
> regards as eligible for update without redeploy (.html, .css, etc.)

That's also a use case (depending on producing an archive in the first place).

Emmanuel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/71e86e50/attachment.bin