<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    "Also, we need to get the Parser down to one file (i.e. use nested
    classes) to make it easier for people to add to their project."<br>
    <br>
    I think that i didn't get the point of what you suggested. Any
    Example of how do you that is should be used instead of
    instantiating or injecting the parser ?<br>
    <br>
    <pre class="moz-signature" cols="72">Rafael Benevides | Senior JBoss Consultant
Red Hat Brazil
+55-61-9269-6576

Better technology. Faster innovation. Powered by community collaboration. 
See how it works at redhat.com
</pre>
    <br>
    Em 17-07-2012 11:31, Pete Muir escreveu:
    <blockquote
      cite="mid:797DB4D8-E1F7-4D25-844C-820BCC717ECA@redhat.com"
      type="cite">Hi Rafael,
      <div><br>
      </div>
      <div>This is starting to look really good!</div>
      <div><br>
      </div>
      <div>* I think we should add a labels: property to the BOM
        definitions, just to try to future proof a bit.</div>
      <div>*&nbsp;I think we need a groupId on the BOMs, as we probably will
        need to include some in other groupIds at some point. We could
        default it org.jboss.boms.</div>
      <div>* We should add the org.jboss.spec BOMs :-) These will make a
        better default for the runtimes</div>
      <div>* I think recommendedBOM on the runtime should be defaultBom
        (notice the case change), as this seems to make more sense to me
        (same for recommendedArchetype)</div>
      <div>* I don't think we need properties as, labels will cover this
        (a consumer can use a label to set up the right properties)</div>
      <div><br>
      </div>
      <div>Also, we need to get the Parser down to one file (i.e. use
        nested classes) to make it easier for people to add to their
        project.</div>
      <div><br>
      </div>
      <div><br>
        On 17 Jul 2012, at 02:19, Rafael Benevides wrote:<br>
        <br>
        <blockquote type="cite">The latest version of the JBoss Stacks
          format is right here:&nbsp;<a moz-do-not-send="true"
            href="https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml">https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml</a>&nbsp;<br>
          I think that this format finally met our requirements.<br>
          <br>
          For now, I put only JBoss EAP 6.0 and JBoss AS 7.0.0 runtimes
          just&nbsp;to illustrate how it should be. The archetypes will also
          follow the&nbsp;same structure.<br>
          <br>
          I committed the parser on the same repo because the parser is
          tied&nbsp;to the file format.<br>
          <br>
          The Stacks class is now the root of the Yaml file ( more
          detail on&nbsp;attached diagram - modified since last email ).<br>
          <br>
          The API use is simple as:<br>
          <br>
          Stacks stacks = parser.parse(inputStream);<br>
          <br>
          After we just navigate on the graph (various paths are
          possible):<br>
          <br>
          stacks.getAvailableBoms().get(SOME);<br>
          stacks.getAvailableRuntimes().get(SOME);<br>
stacks.getMajorReleases().get(SOME).getMinorReleases().get(OTHER).getRecommendedRuntime().getBoms().get(ANOTHER).<br>
stacks.getMinorReleases().get(SOME).getRecommendedRuntime().getRecommendedBOM().getAvailableVersions();<br>
          <br>
          Now I will update the jdf-plugin to use the jdf-stack parser
          API.<br>
          <img name="Class Diagram.png"
            id="74b95004-b27b-4794-83e0-e9451f9afbb7" apple-width="yes"
            apple-height="yes"
            src="cid:part2.09090707.03000304@redhat.com" width="1000"
            height="762"><br>
        </blockquote>
        <br>
      </div>
    </blockquote>
  </body>
</html>