Community
Participate
Working Groups
Currently the kernel deployer 'faults-in' dependencies from the repository chain that are not present when an artifact collection is being resolved. This provisioning saves a lot of time and documentation effort in the packaging of applications, and means that pars or wars don't have to contain everything. The drawback is that if there are a lot of optional component dependencies (and there nearly always are), the deployer will attempt to get them all from the repository chain. If the chain had a remote repository with a lot of components in it (the EBR, for example?) then a deployment could easily be bloated and >very< slow to resolve. If the deployer >never< provisioned optional dependencies there would be two consequences: 1 the EBR would only be used to provision mandatory dependencies -- this avoids the EBR in the chain problem and speeds up resolution (things are orders of magnitude simpler without optionals); 2 applications that want to exploit optional dependencies WONT GET THEM provisioned UNLESS THEY EXPLICITLY deploy them. Apps today might behave differently, but the workaround is simple -- put the optionals you really want into a plan with your app, and deploy the plan. Since plans can refer to plans, the 'required optional' can be placed at the correct place in the packaging tree. This is an enhancement, since a way of controlling this behaviour (for backwards compatibility) would appear to be necessary, and is yet to be designed.
With reference to bug 315869, one way of controlling the behaviour proposed by this bug would be to use a plan attribute setting of dependencies=noinstalloptional. This would make the behaviour switchable on a plan basis, which seems not unreasonable.
