Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-3517

Module descriptor additions


    • Icon: New Feature New Feature
    • Resolution: Obsolete
    • Icon: Neutral Neutral
    • 4.5
    • None
    • core
    • None

      In the light of changes for IoC (MAGNOLIA-2569), we need to introduce a couple of new elements in the module descriptors.
      http://wiki.magnolia-cms.com/display/DEV/Concept+IOC+in+Magnolia contains some background information.

      Changes are in flux, but so far, we've identified the following:

      • components
        • component - with an optional key attribute, and possibly with a scope attribute. This is a replacement for components registered via properties. The key can be used to replace an already registered component. If no key is provided, one might bump into AmbiguousComponentResolutionException (or whatever equivalent exception other containers might throw), but this also allows dependencies on collections of certain types. TBD: do we introduce a different element for repository-configured components, or do we determine if the value is a class or a repository path by analyzing the string ?
        • provider or factory - optional key attribute. With this we will explicitly register factories for types of components (instead of the current mechanism that checks if the instantiated class is a factory)
        • composer - tbd. This could be used to register container-specific "composers", i.e a special type of component which will register components on the container by code rather than by adding more elements to the module descriptor. (So this could be, for example, picocontainer-specific, using more complex component configuration/registration (jmx for example?)
      • transformers - for content2bean. TBD: perhaps these can simply be registered as {{component}}s.
      • moduleID or moduleKey or moduleCoordinates? - unrelated to IoC, but it's as good a moment to introduce it as any. This is the equivalent of the groupId:artifactId:version of Maven/Aether. We will need this to download modules into Magnolia, and might also help avoiding potential naming conflicts, which could easily arise with our current short-naming scheme.

        Acceptance criteria

              pbaerfuss Philipp Bärfuss
              gjoseph Magnolia International
              0 Vote for this issue
              0 Start watching this issue