"emuckenhuber" wrote :
| "scott.stark(a)jboss.org" wrote :
| | If we completely abstract out the deployment and admin content into a deployment
repository, then I can see a differentiation between a dynamic profile that is one define
by root urls against the deployment repository vs a profile that allows modifications to
both deployment collection make up and content changes.
| One thing i don't like about the current implementation is that a profile is more
| it's DeploymentRepository than it is defined by itself (the actual profile).
| Well i mean the implementation is not a big deal, just want to say that when talking
about the definition of a Profile,
| a DeploymentRepository should be optional.
| On the other hand this is actually the main point of this thread. Basically how the
DeploymentManager gets access
| to the low level source of a mutable profile.
| I'm not planning to change this yet - just an idea to think about :)
I'm begining to think that there is no point to a Profile without a
DeploymentRepository though. The reason is that at its most explicit a profile has a list
of URLs/URIs that define the deployments in some VFS. However, even include the VFS
protocol is an implicit repository notion that would more generally handled by the
DeploymentRepository and the profile would be relative paths against the repository. More
generally I'm working toward much more abstract profiles that have to be resolved
against a repository. The repository still is an implementation detail as there is no need
for it to be exposed from the profile, but the profile is also not useful without the
Your moving away from the Profile exposing deployments as VFSDeployment right? I don't
see the ProfileDeployment in trunk, is it somewhere yet?
View the original post :
Reply to the post :