Community
Participate
Working Groups
The current update manager site spec supports categories within the site. As far as I can tell, there is no equivalent anywhere in the provisioning API. This is not something the UI can define, because Repo and/or IU providers need to define the categories and tag IU's with a category. If site categories are to be supported, would it be generic concept in the API, or just a property defined on metadata repositories and IU's? If the latter, then any tooling we built to define and populate metadata repos would need to support defining these. As it is, I don't see that the end-user UI can help the user organize what they see in a metadata repo without underlying support.
I talked to Pascal who has an idea for dropping in IU's that define the categories and require the IU's in the category. Pinging Pascal to describe the idea here...
For this, rather than introducing another concept I was thinking that we could have IUs marked as "category" (either using a property or a capability). Such IU would list requirements on the IUs that belongs to the category. For example a "tool" category, could require "sdk [3.0.0)". With this model, the publication of the new bundles in a category requires the edition of the category IU to introduce the versions. To give more flexibility in the publication, one could imagine creating bridge IU that would provide the capabilities necessary for an IU to fall into a category, and require the actual IU. For example, let's assume there is a "foobar" category IU and a "zoo" IU given to me by a friend. To publish "zoo" under "foobar" and since IUs to be installed are immutable, I would create a "categoriesForZoo" IU that would provide a capability matching for some reqs of "foobar" and requires the "zoo" IU.Note that this approach also allows for multi-categorization of one IU. The nesting of categories would be achieved by having category IU requiring another category. The last problem is identification of what to show to the user, and for this I propose to have some marker in the categories IU. Not ideal but better than doing any fancy computation.
*** Bug 194239 has been marked as a duplicate of this bug. ***
I see two issues here: 1 - tooling that makes it easy for a repo administrator to create these IUs 2 - support in the UI itself to look for these IU's and organize the IU's presented to the user I can tackle #2 in advance of tooling if we want to demonstrate this capability soon. Perhaps in the M3 timeframe.
We need to think about how the IU's in the categories are presented. Since the IU's in a category are expressed as a capability, we need to map from the IU id to what we present to the user. Also, are we showing the users all of the versions of IU's that fit in the category, or are we coalescing them and presenting the user just the IU's name, and then somehow resolving what could be installed ahead of time?
Seems like in several of these related areas we are missing some cross cutting concern that would advise the user and the system. There is a category on the one hand, the wads and wads of IUs on another and then there should be some context or something that should inform the system of how to relate the two. Categories can have version numbers or ranges for their dependencies. This appears valuable. It also may imply a management cost to setting up and maintaining the category and a blurring in the distinction between categories and groups (e.g., why did I define a category rather than just create a group?) In any event, a category may well identify multiple versions of the same IU as Susan points out. Here it might make sense to simply list the common (or most recent) human readable name and let users choose. A couple other points: - Pascal mentioned in the call today the idea that people would define, in essence a dynamic, abstract category by defining requirements that might be met by many different IUs. For example, Category C might depend on things that supply the "Service" capability. Then all IUs that provide Services would appear in C. This is powerful and interesting. It may also raise further UI questions. - Is there an assumption that the things showing up in categories can be or should be directly installable? I know that technically it would be possible but is that the intention?
In discussions recently with Jeff, he has emphasized he wants it to be super easy for a random person to build their own view of the metadata and present it to users on a web page and such. So that they don't feel like they are authoring IU's when they create categories. That makes me wonder... ...should we support the ability to refer to an IU in a repo using a URL? So that people could author random web pages categorizing things however they wanted? Then those things could be downloaded and then discovered by p2?
This is interesting. In this case, do you think all repositories should be able to make their IUs through a URL, or do you think this is something that can only be achieved on certain kinds of repositories? To be cool I can't prevent to mention REST :-) Also going down that path, what is the relationship with this way to refer to IU and the metadata repository API? For example would we expect people authoring web pages referring to IUs being able to craft categories as complex as what you would find in a rich UI?
Setting milestone to M4 (I had hoped I would get to this for M3 but will not). >In this case, do you think all repositories should be able >to make their IUs through a URL, or do you think this is something that can >only be achieved on certain kinds of repositories? I was imagining it was supported by URLMetadataRepository. That you could get links to all of the IU's in the repo, and from each link you could get the properties of the IU's, etc. (Yes, a REST architecture). At some point you can actually download the IU. >For example would we expect people authoring web pages referring to IUs being >able to craft categories as complex as what you would find in a rich UI? I see it as being another tool for grouping IU's into categories, and don't see a reason it would be any less rich. If categories are just a property on an IU, then a web client could look for that property and know that a particular IU was just a category from the repo producer's point of view. They could incorporate it or ignore it. They also would know that something was a group, and therefore is a candidate to be installed. The main thing is that they could then refer to any IU they wanted, keep favorites lists, group them however they want on a web page. They could do it dynamically or statically, whatever they wish.
The path explored in the last comments is interesting. However I don't see that as a primary goal, and I would rather focus on doing categories in typical UI first. Also to ease the tracking of this idea, what about creating another bug?
Opened bug # 207594 for the URL discussion. Will look at the IU category approach in M4.
(In reply to comment #9) > They also would know that something was a group, > and therefore is a candidate to be installed. Just to be clear, anything can be installed not just groups. We are highlighting groups currently as a short term hack. "group-ness" should not in the end be a determining factor. In a way, that is what all of this discussion is about. How do we allow poeple to identify and maintain lists of interesting starting points.
I've released initial support for categories. In the absence of metadata generator support for categories, I currently create a dummy category called "Uncategorized" to ensure that something is shown in the UI. So all non-categorized IU's are shown in that category. I refactored the content providers and viewer elements so that the basic taxonomy of the viewer trees is specified via queries. A query provider is installed in a content provider, and it drives how the content expands. So, the end user UI uses categories to drive the tree, followed by the "Latest version" query. It also filters by group. The admin UI has preferences that drive whether categories, latest version only, groups only are used. I'm keeping this bug open for now because there is still more to do before it's complete: - need to do further testing with real category data. - need to test nested categories - can categories have versions? I don't think I'm handling the case yet with multiple categories/different versions. In the end user UI it makes sense to only show the latest version if any particular category IU. In the admin UI it might be interesting to show multiple versions based on a pref.
This is great news! Could you detail which properties you are checking for, or simply show the shape you are expecting so that we know exactly what to generate? By curiosity, how do you handle nesting categories?
I will attach a patch I made to the metadata generator to dummy up some categories. This patch generates categories that look like: Category1 Category 4 Category2 Category3 and sequentially assigns the various feature IU's to each category. The method Generator.generateCategory(String name, Set ius, IInstallableUnit nestedCategory) shows how to generate a particular IU. In particular, a generated IU: - has the property IInstallableUnit.PROP_CATEGORY_IU set to "true" - its required capabilities describe its members. This is a bit weird, in the sense that to get the members of a category, you query the repo for all IU's that satisfy ANY ONE of the required capabilities (rather than all). During generation time, we would typically generate a required capability of type IInstallableUnit.NAMESPACE_IU, whose value is the id of the IU in the category. - when we generate the category IU, it exports its own namespace so it can be nested in another category When the UI looks for categories, it queries for all IU's with the PROP_CATEGORY_IU. Once it has them all, it eliminates any categories that are referred to by another category. When the UI looks for members of a category, it looks for any IU who provides any of the capabilities of the category. I'm going to mark this bug as fixed from a UI point of view, though it needs more testing. But I think the next step is to generate better data through tooling or when we generate data for a site, we should respect its categories. Then we will find the next round of bugs and can open bugs on those issues.
Created attachment 83828 [details] metadata generator patch for dummy categories generates hard coded dummy categories. This patch is provided to show how the UI expects category IU's to be created.
Another assumption I make (shown in the patch) is that the category IU's name property will be set to its id. The name is what is shown to the user.
