| Key: |
MNG-3695
|
| Type: |
New Feature
|
| Status: |
Open
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Mark Hobson
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
Currently, a dependency's version or a dependency's version and scope can be managed in dependency management, but a dependency's scope alone cannot be managed. For example, we cannot express the following:
Of course it does work if we also specify a version, but there are times when we want to merely control the scope and not change the resolved version. When we try the above example we get:
|
|
Description
|
Currently, a dependency's version or a dependency's version and scope can be managed in dependency management, but a dependency's scope alone cannot be managed. For example, we cannot express the following:
Of course it does work if we also specify a version, but there are times when we want to merely control the scope and not change the resolved version. When we try the above example we get:
|
Show » |
|
Allow dependencies' scopes to be managed without explicit versions
How do you know its provided until you actually try to deploy it? The container of choice may change over time or even be multiple and as such the 'provided' depdendency might not make any sense.
I prefer to build one distributable that does not change across containers cause that way you know its the same one that ends up in production. Perhaps the containers need to filter out the relevant artifacts at load time....perhaps using the implementation details in the manifest?