On 08/17/2012 02:52 AM, Stuart Douglas wrote:
The big problem with this is that it does not work with the
deployment scanner.
Yeah, the deployment-scanner is always a story for itself. However i
think we could actually make it persist information and be aware of
overlays.
Having overlays as part of the deployment means the lifecycle is managed
together, so the deployment-scanner could define it's own invalidation
policy. May it be based on whether the content got removed or we have a
specific marker for that.
We could also think of providing a file-based overlay solution, managed
by the deployment scanner only. In the end people use the
deployment-scanner for a reason, so perhaps not having to worry about
the model or "content" folder could be interesting. This would not even
need to access persistent information though. Anyway just some ideas on
the side.
It also has to be specified on every re-deploy.
When you do a "remove" and "add" then yes. We do have specific
operations to replace the content and redeploy the deployment without
removing the information from the model.
I think the simplest solution here
is to just move the links under the deployment-overlays element and loose the
flexibility to link at different levels. e.g:
/deployment-overlay=myOverlay/deployment=test.war
/deployment-overlay=myOverlay/deployment=*.jar
Yes, i was not really going for the simplest solution for now - this
would most likely would be it :)