plugins/org.eclipse.wst.common.modulecore/schema/heirarchyFlattenParticipant.exsd

<?xml version='1.0' encoding='UTF-8'?>
<!-- Schema file written by PDE -->
<schema targetNamespace="org.eclipse.wst.common.modulecore" xmlns="http://www.w3.org/2001/XMLSchema">
<annotation>
      <appInfo>
         <meta.schema plugin="org.eclipse.wst.common.modulecore" id="heirarchyFlattenParticipant" name="heirarchyFlattenParticipant"/>
      </appInfo>
      <documentation>
         This extension point is to register a global level flatten participant
         which can be trusted to know about any and all approved nestings of various
         project types, specifically regarding child modules. 
         
         By registering a heirarchyParticipant via this extension point, you can allow
         your custom project / module type to be recognized as a child of another module type. 
         For example, your custom "car" archive project can be recognized as a child
         module of an ear project or web project.
         
         Parent modules and module delegates using a GlobalHeirarchyParticipant 
         or its provider are accepting that some potentially unknown module types
         may declare themselves to be child modules of the parent module. Risk
         is limited, however, as all that will change is whether a child component
         is marked as a child or not. This will have some effect on the publish or export
         events, however, as children modules will have their list of participants 
         used when a component is marked as a child module. If it is not marked as a child module, 
         the referenced component will instead be traversed normally. 
         
         As an example, if an unknown "car" project is referenced inside an ear project, 
         and if the "car" project is recognized as a child module, the "Car" project will
         have its participants assist in the publish 
         (ex, ignoring .java files,  optimizing itself according to logic consistent with the "car" project).
         
         If the car project is NOT recognized as a child, the nested files 
         will be traversed simply as a tree, and features such as including 
         .class files instead of .java files will not take place. 
         
         Parent modules that require complete control over which virtual components
         may be recognized as children should not allow their deployables to use the 
         GlobalHeirarchyParticipant at all. 
      </documentation>
   </annotation>

   <element name="extension">
      <annotation>
         <appInfo>
            <meta.element />
         </appInfo>
      </annotation>
      <complexType>
         <sequence>
            <element ref="heirarchyParticipant"/>
         </sequence>
         <attribute name="point" type="string" use="required">
            <annotation>
               <documentation>
                  
               </documentation>
            </annotation>
         </attribute>
         <attribute name="id" type="string">
            <annotation>
               <documentation>
                  
               </documentation>
            </annotation>
         </attribute>
         <attribute name="name" type="string">
            <annotation>
               <documentation>
                  
               </documentation>
               <appInfo>
                  <meta.attribute translatable="true"/>
               </appInfo>
            </annotation>
         </attribute>
      </complexType>
   </element>

   <element name="heirarchyParticipant">
      <complexType>
         <attribute name="class" type="string" use="required">
            <annotation>
               <documentation>
                  
               </documentation>
               <appInfo>
                  <meta.attribute kind="java" basedOn=":org.eclipse.wst.common.componentcore.internal.flat.IFlattenParticipant"/>
               </appInfo>
            </annotation>
         </attribute>
      </complexType>
   </element>

   <annotation>
      <appInfo>
         <meta.section type="since"/>
      </appInfo>
      <documentation>
         [Enter the first release in which this extension point appears.]
      </documentation>
   </annotation>

   <annotation>
      <appInfo>
         <meta.section type="examples"/>
      </appInfo>
      <documentation>
         [Enter extension point usage example here.]
      </documentation>
   </annotation>

   <annotation>
      <appInfo>
         <meta.section type="apiinfo"/>
      </appInfo>
      <documentation>
         This extension point is provisional API and may change in the future.
      </documentation>
   </annotation>

   <annotation>
      <appInfo>
         <meta.section type="implementation"/>
      </appInfo>
      <documentation>
         [Enter information about supplied implementation of this extension point.]
      </documentation>
   </annotation>


</schema>