Community
Participate
Working Groups
Build Identifier: Virgo 2.1.0-M5 The artifact console only permits one upload at a time to be installed. http://localhost:8080/admin/web/artifact/overview.htm If a bundle can't be resolved, then the UI gives no error. Often, this is because of a missing dependency - but you don't know which one. If you have a self-consistent set of bundles, you really want to be able to throw all of them, such that they are (a) installed and then (b) started as a group, not individually. Reproducible: Always Steps to Reproduce: 1. Install two bundles, one after another 2. If the first bundle depends on the second bundle, the first bundle can't be installed 3. The problem grows exponentially with the number of bundles wishing to install
Thanks for reporting this. Marking as an enhancement. Please note this is not something we will have time to address before the 2.1.0 release.
I think putting this function into the admin console would over-complicate the user interface. However, there is a much better approach which is to place the bundles in a repository and then deploy a plan referring to the bundles. The bundles are then all installed before being started, so there won't be missing dependencies if the set is self-consistent. If the set isn't self-consistent, then the deployment fails with a resolver state dump, which can be analysed offline using the admin console OSGi state inspection tab, and the bundles are not installed into the live framework.
That answer makes no sense to me. Even if there were proposed UI changes, people are sufficiently used to multiple uploads in gmail attachments and for other file servers like dropbox, picture sharing sites etc. But HTML5 supports the "multiple" attribute on input type=file which is backwardly compatible with the ui and non html5 browsers. What I'm suggesting is the following: * put "multiple" in the HTML for the form * handle parsing more than one result in the form's upload fields on the server * do a separate iteration of "install" followed by "start" in the bundles uploaded http://dev.w3.org/html5/spec/forms.html#attr-input-multiple Being able to handle multiple files should be part of the html5 drag and drop api anyway, so having this feature here as well would be consistent.
By the way, I don't disagree that there are other or better ways for doing this. But those new to Virgo's admin interface won't know about them until after they are more comfortable with pars, plans etc. Having an application as a pre determined set of bundles is pretty common (eg through apache felix file install) and being able to select all would be a good way of doing demos. Perhaps the admin console could also link to documentation about pars and the like, or even allow (after uploading) a link to create a par from the just uploaded bundles. That way you encourage best practice and offer the functionality to use the ui to generate a par automatically. The concern I have is limiting it to a single bundle (which may fail due to missing dependencies) is likely to put people off using the admin console. Realistically the only single bundle examples are all hello world examples.
You make a fair point about newcomers. So the generalisation Virgo needs is the ability to deploy a set of artefacts together, i.e. they would all be installed before all (except of course fragments) being started. The changes required are as follows: * Extend the admin console UI to allow a set of artifacts to be selected for deployment. * Extend the deployer API to allow a set of artifacts to be deployed. Let's use the term "group" for such a set below. * Introduce a new artifact type of group similar to a non-atomic unscoped plan but anonymous and not resulting in a plan visible at runtime. * Extend the relevant pipeline stages to cope with groups. * Extend the deployer recovery log to cope with recovering a group. In particular, a crash after logging some but not all of a group must result in none of the group being recovered, so there will need to be a begin/end bracket in the log. * Cope with the situation where some of the artifacts in the group are plans which refer to other artifacts in the group. This would either be a restriction or, preferably, we would need to introduce a "group sorter" pipeline stage or transformation to restructure the group appropriately so that plan contents become children of plans. This would need to be done prior to plan resolution. Of course, all this would need unit and integration tests too. Unfortunately, this is too big an item to slip into 2.1.0, so will have to be deferred to a later release. However, it's an interesting extension which will have real benefit for new users, so we should see when we can prioritise it in.
We looked at this again in this morning's sprint planning meeting. Rather than introduce a new artefact type of "group" it turned out to be much cleaner and more uniform to generate an unscoped, non-atomic plan for this scenario. My initial reluctance to do this was that we would have to generate a name for the plan and I had hoped we could avoid this for a new artifact type, but this doesn't really fit in with the RuntimeArtifactModel which indexes artefacts by type, name, and version. So we'll need to generate a name for the plan and ensure this doesn't clash with any other plan names in use. So the revised proposal is to reference the selected artifacts in an unscoped, non-atomic plan and then deploy that plan. The main remaining question is how to make the artifacts available when resolving the plan, either initially or during recovery when Virgo is warm started. One approach would be to place the artifacts in a repository and somehow ensure that the repository indexed the artifacts before being queried to find them. But this requires us to crack open artifacts first to find out their names and versions simply in order to store the names and versions in the plan and later to query the repository looking for those exact same names and versions. This is inelegant apart from being a waste of performance. A better approach may be to generalise plans to allow them to refer to artifacts by URI as an alternative to type, name, and version. Then we can stage all the artifacts as usual and create a plan containing the staged URIs.
Done
