<?xml version="1.0" encoding="UTF-8"?>
<plugin
   id="org.eclipse.jem.beaninfo"
   name="%pluginName"
   version="1.0.0"
   provider-name="%providerName"
   class="org.eclipse.jem.internal.beaninfo.adapters.BeaninfoPlugin">

   <runtime>
      <library name="beaninfo.jar">
         <export name="*"/>
         <packages prefixes="org.eclipse.jem.internal.beaninfo"/>
      </library>
   </runtime>
   <requires>
      <import plugin="org.eclipse.jem.proxy"/>
      <import plugin="com.ibm.etools.emf.event"/>
      <import plugin="org.eclipse.jdt.core"/>
      <import plugin="org.apache.xerces"/>
      <import plugin="org.eclipse.jem.workbench"/>
      <import plugin="org.eclipse.core.resources"/>
      <import plugin="org.eclipse.jdt.launching"/>
      <import plugin="org.eclipse.emf.ecore"/>
      <import plugin="org.eclipse.jem"/>
      <import plugin="org.eclipse.emf.ecore.xmi"/>
      <import plugin="com.ibm.etools.emf.workbench"/>
   </requires>


<!-- This extension point is for registering beaninfos based on classpath variable paths.
        Format is:
        <extension point="org.eclipse.jem..beaninfo.registrations">
          <variable path="avariablename" (or path="avariablename/something.jar")
               contributor="classname of an IConfigurationContributor">
            <beaninfos>
              <beaninfo kind="plugin" path="/apluginid/something.jar">
                <searchpath package="com.sun.corba.se.internal.ior"/>
                <searchpath package="org.eclipse.jem.beaninfo.testing.infos.project"/>
              </beaninfo>
              <searchpath package="com.sun.corba.se.internal.ior"/>
            </beaninfos>
          </variable>
        </extension>
        
        If it is of type "avariablename", then this info will be used for all variable classpath entries
        that start with this variable. This allows several bean class jars that are subpaths
        of a variable to share the same beaninfo information.
        
        If it is of type "avariablename/...", then this info will be used only for this particular
        path.
        
        If contributor is set, then using standard IExecutableExtension protocol, the contributor will
        instantiated and will be able to contribute to the remote vm. It needs to implement
        org.eclipse.jem.internal.proxy.core.IConfigurationContributor and can implement org.eclipse.core.runtime.IExecutableExtension
        if it needs parameters or to be called with the standard extension initialize information.
        
        There can be more than one for the same path, they will be concatenated together. Probably
        shouldn't do this in the same plugin, but it allows multiple plugins to contribute beaninfos
        to the same variable path. Though the final order is indeterminate since it is the order
        the extension points are processed.
        
        The <beaninfo> refer to the classes location that contains the beaninfo classes themselves
        to use with this variable path. There can be more than one. The <searchpath> within these are
        the searchpaths to use (in the order given) for that beaninfo class location.
        
        The <searchpath> not under a <beaninfo> are for when the beaninfo classes are located in the 
        jar the variable path points to. The jar in the variable path is in the actual project's
        classpath and buildpath. So in this the beaninfo classes are there too. This allows the packages
        to be added to the searchpath. -->
   <extension-point id="registrations" name="Registration of pre-defined beaninfos"/>
<!-- This extension point is registering beaninfo override xmi files. This documents will be used
        to pre-populate the beaninfos. Then they can say that the beaninfos from the remove vm
        are to merge into these beaninfos, or they can actually turn off introspection on the 
        remote vm on a per-class basis. The format is:
        
        <extension point="org.eclipse.jem.beaninfo.overrides">
          <override package="java" path="xyz/java"/>
          <override package="java.awt" path="xyzq/java/awt"/>          
        </extension>
        
        The package is matched on package for a class, and if it matches, it will take the
        path and append the non-matched portion of the package and class name and attach ".xmi" and see if that file exists. If it does, then that file is
        loaded with the overrides. It will search through all of the extensions with matching
        packages and applies them all. The order is indeterminate so the individual ones should
        not rely on ones from a different extension being applied first.
        
        A match is if the package of the class starts with a package from the overrides. For example,
        "java.awt.Component" will match overrides "java" and "java.awt". It will not match "java.a".
        It needs to match on a package fragment boundary (i.e. on the parts seperated by a period).
        
        So in the above example, if the class is java.awt.Component it will look for a file
        named "xyz/java/awt/Component.xmi". It will also match the second one, so it will also
        look for "yyzq/java/awt/Component.xmi".
        
        This allows you to have one directory for the lowest common part of your package names,
        and they would all be found in subdirectories of this.
        
        There is a special package mapping, called "..ROOT..". This is used to override java.lang.Object and
        any interface. It will use the ..ROOT...xmi file in the path, and it will apply the specified overrides
        to the java.lang.Object or the interface. This is used to apply a common consistent set of features
        to the root objects (Object and Interfaces are all root objects, i.e. there is no super type of these).
        In the diff file, to reference the root object in question, use notifier="#..ROOT..". An example extension point would be:
        
        <extension point="org.eclipse.jem.beaninfo.overrides">
          <override package="..ROOT.." path="platform:/plugin/myplugin/overrides"/>
        </extension>
        
        So in this case it will look for the file "platform:/plugin/myplugin/overrides/..ROOT...xmi".
        
        Since these can be in plugin directories, the path
        can use the "platform:/plugin/.../" format or it 
        can use the EMF URI Mapping extension point to access files within a plugin.
        -->
   <extension-point id="overrides" name="Registration of beaninfo override documents"/>

   <extension
         id="BeanInfoNature"
         name="%beaninfoNatureName"
         point="org.eclipse.core.resources.natures">
      <runtime>
         <run
               class="org.eclipse.jem.internal.beaninfo.adapters.BeaninfoNature">
         </run>
      </runtime>
   </extension>
   <extension
         point="org.eclipse.emf.ecore.generated_package">
      <package
            uri="http:///org/eclipse/jem/internal/beaninfo.ecore"
            class="org.eclipse.jem.internal.beaninfo.BeaninfoPackage">
      </package>
   </extension>
   <extension
         point="org.eclipse.team.core.fileTypes">
      <fileTypes
            type="text"
            extension="beaninfoConfig">
      </fileTypes>
      <fileTypes
            type="text"
            extension="override">
      </fileTypes>
   </extension>

</plugin>