"emuckenhuber" wrote :
| Hmm, there are some use cases where you don't need any repository.
| For example the transient application profile managed by the DeploymentManager.
| This will be just a hashMap containing the isCopyContent == false deployments, so that
they
| are also visible in the ManagementView.
| But it's still a independent profile, which can be activated / deactivated by the
DeploymentManager.
|
Ok, so an issue with that is how do we store admin edits of such profiles?
"emuckenhuber" wrote :
| Furthermore i think a VFS/uri does not make up a profile, as you still can could have
a different (maybe static) profile,
| where you create non-vfs based deployments - this is now also possible with the
abstraction of ProfileDeployment (although not fully implemented)
|
Right, the profiles I'm working on don't have URIs either as they are described in
terms of criteria that need to be resolved.
"emuckenhuber" wrote :
| Although i also think that there is something missing - but more in the sense of a
ResourceDiscovery or ProfileSource.
| Something where you can share the same source and don't need to maintain the
profile root uris in each profile.
| Maybe this also matches somehow to the work you want to do with a
DeploymentRepository?
|
| Can you provide some more information and/or use cases why you think this is not
enough?
| I mean maybe i'm just missing something :)
|
What's missing is a generic ProfileBootstrap that can have different ways of
specifying subprofiles that should be included. For example, the deployers and base
services would be specified via criteria, user apps specified via a uri to one or more
apps defined in a jboss tools project. I'm going to review the changes in trunk
tonight, but it is probably more of a notion of a resolver that I'm thinking of.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206151#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...