[
https://issues.apache.org/jira/browse/ACE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13704991#comment-13704991
]
Marcel Offermans commented on ACE-368:
--------------------------------------
At some point we now "approve" a new version. That is where we also assemble
the artifacts that go into a deployment package. Our "approve" API allows the
call to fail, and we could make this call fail with an exception that explains
that we have two bundles with the same BSN in the deployment. Conceptually I
think that is the best point to fail, if we want to fail. If we don't want to
fail, like Angelo suggests, picking the highest version is the best option we
have, but somehow this does not feel entirely right as then the actual
deployment no longer matches what you see in the UI. So I would propose we take
the path of failing the "approve" and making sure we communicate that to the
user (that's probably the tricky part).
> More than one version of a bundle can end up in a deployment package
> --------------------------------------------------------------------
>
> Key: ACE-368
> URL: https://issues.apache.org/jira/browse/ACE-368
> Project: ACE
> Issue Type: Bug
> Components: Client Repository, Deployment, UI
> Affects Versions: 1.0.0
> Reporter: Marcel Offermans
>
> If you assign more than one version of a bundle to a target, for example by
> making two static associations from the same feature, both will indeed end up
> in the deployment package. It will then fail to install or roll back because
> the Deployment Admin implementation never catered for this case and could not
> quite recover from it.
> However, the problem is created already in the client, because you should
> never be allowed to end up with more than one version of a bundle. We
> probably need to discuss how to tell the user about this and decide if we
> should a) simply refuse to deploy, b) choose the highest version and drop the
> other or c) something else. :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
