Application Descriptor

Last modified by Vincent Massol on 2024/02/26 17:52



Related Proposals

Application Descriptor

We discussed many times in the past about Application Descriptors. [ 1 ] [ 2 ]
Application Manager provides such a application descriptor in order to know how to handle Applications. Currently Application Manager is considered deprecated.

This brainstorming wants to tackle again this concept but a bit different. The differences are that: 

  • since the first definition of the descriptor things have changed and now we have many more automated ways to extract information instead of declaring it (example: Extension Manager can extract the version, name, description, dependencies, author, license from the pom; Translations can be automatically bundled, etc.). Application Descriptor should not duplicate data.
  • the descriptors should be targeted towards applications developers, not the machine, containing generic information about the application that is skin independent and feature independent. What I mean by skin/feature independent is that application developers should not be aware that we use their application in a certain way or by certain features and thus should not be needed to provide ApplicationPanelEntry classes, but just the icon of the application for example and the panel entry could be automatically created by the panel application.  

Integration with

Currently Extension Manager knows how to handle XAR files. The difference between a normal XAR and 'Applications' would be given by this Application Descriptor, saying that the XAR is installable (contains logic and not just text, backup data, etc.) and should be treated accordingly.

Default XWiki features that would use the application descriptors: 

  • Extension Manager - already extracting information from the .pom, could use application descriptor to store data that cannot be found in the pom
  • Repository
  • Administration - we provide an 'Applications' section where individual applications display their settings. The descriptor could have a link to the administrative page
  • AWM - can store data about the class, livetable columns, etc.
  • Rights 
  • Index - we could have an Application Index that list all the applications
  • Profile - can contain application specific user settings
  • Panels - AppBar (favorite mechanism), Applications panel
  • Activity Stream - could display application specific entries
  • WYSIWYG - specific macros
  • Search - specific filters
  • Search Suggest - could be extended to suggest application names
  • Help Wizard - tutorials about applications
  • etc.

All the above features would benefit from knowing that a certain XAR, space is not just a space, but an application. 


It is very important to define the purpose of this Application Descriptor (and if is ok to call it descriptor or any other name). IMO its main purpose is:
1) to help the application developer customise his application and give general directions of how XWiki should interact with it
2) old way that contained technical information about the application.
Of course the purposes kind of intersect and that's why is very hard to decide what fields the descriptor would cover.

The main need I see for introducing the descriptor is this overlapping of applications. In XWiki, applications are not isolated, but they call each other, display data one from another and they need a way to communicate, easily integrate each other.  Example of this is: adding application data in Administration, Profile, Search, etc.
Applications are becoming a major concept inside XWiki and needs to be defined accordingly. 

Some things we know about Applications: 

  • they have a name:
    that needs to be displayed in EM, Application Panel, Administration, etc. Problem: EM appends also the term 'Application', while the other don't, example "Calendar Application" vs. "Calendar".
  • they can be contained in one or more spaces:
    this is important since instead of adding the information inside the descriptor we could use the space WebPreferences. The problem is that some applications do not limit themselves to one space boundary (like the Forum app) and any setting we would have on a particular space (like a certain skin, panels set, etc.) would need to be copied on all application's spaces.
  • they can have an icon:
    we display the icon in EM, panels. We will need a bigger icon for the AppBar. Ideally the application developer should provide/attach the icons to the descriptor (eventually in different sizes) and let XWiki select the appropriate size according to the feature that is calling the app.
  • they are installed on a certain wiki:
    so they have an owner and they respect the rights set on that location
  • they have their own settings:
    currently this is integrated inside the main wiki Administration, but since we already mentioned an owner, normal user might want to customise the application.

Use Cases

UC: Be able to give a name to the application (ex. Forum)
UC: Be able to specify what types of entries the application handles (ex. Topics)
UC: Be able to define the structure of the application (class definition, applicable for AWM apps)
UC: Choose an icon for your application (that would be displayed in AppIndex, AppBar, Administration, Repository, etc.)
UC: Define who has access to your application (managed through wiki users + rights)
UC: Define the presentation of your application (managed by space panels, space skin, show docextra, enable comments, disable attachments zone, etc.)
UC: Be able to administrate the application entities (add more entity types - articles, threads; manage forum's categories, etc.)
UC: Be able to know what is the current application (depending on the current page)



  • name
  • id
  • ...
  • icon
  • ...
  • spaces - list of spaces that the application contains



Get Connected