<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Ok, Pete.<br>
    <br>
    Well, But there are lot of other files that the parser results as
    Archetype, Bom, MajorRelease, MinorRelease, Runtime, RuntimeType,
    and Stacks classes<br>
    <br>
    I think that copying all Parser classes will be harder to people
    maintain than a using it as dependency, specially when the file
    format gets updated. <br>
    <br>
    Sorry, Is there any special reason for you to prefer copying instead
    of dependency that I didn't realize?<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 12:56, Pete Muir escreveu:
    <blockquote
      cite="mid:EB561EA0-6760-4A55-8763-8FFC774132D8@redhat.com"
      type="cite">Basically, the idea is to avoid a dependency, and
      allow people to just copy and paste the class into their project.
      <div><br>
        On 17 Jul 2012, at 16:51, Rafael Benevides wrote:<br>
        <br>
        <blockquote type="cite">"Also, we need to get the Parser down to
          one file (i.e. use nested&nbsp;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&nbsp;Example of how do you that is should be used instead
          of&nbsp;instantiating or injecting the parser ?<br>
          <br>
          <div>Rafael Benevides | Senior JBoss Consultant</div>
          <div>Red Hat Brazil</div>
          <div>+55-61-9269-6576</div>
          <div><br>
          </div>
          <div>Better technology. Faster innovation. Powered by
            community collaboration.&nbsp;</div>
          <div>See how it works at <a moz-do-not-send="true"
              href="http://redhat.com">redhat.com</a></div>
          <br class="Apple-interchange-newline">
          <br>
          Em 17-07-2012 11:31, Pete Muir escreveu:<br>
          <blockquote
            cite="mid:797DB4D8-E1F7-4D25-844C-820BCC717ECA@redhat.com"
            type="cite">Hi Rafael,<br>
            <br>
            This is starting to look really good!<br>
            <br>
            * I think we should add a labels: property to the
            BOM&nbsp;definitions, just to try to future proof a bit.<br>
            * I think we need a groupId on the BOMs, as we probably
            will&nbsp;need to include some in other groupIds at some point.
            We could&nbsp;default it org.jboss.boms.<br>
            * We should add the org.jboss.spec BOMs :-) These will make
            a&nbsp;better default for the runtimes<br>
            * I think recommendedBOM on the runtime should be
            defaultBom&nbsp;(notice the case change), as this seems to make
            more sense to me&nbsp;(same for recommendedArchetype)<br>
            * I don't think we need properties as, labels will cover
            this&nbsp;(a consumer can use a label to set up the right
            properties)<br>
            <br>
            Also, we need to get the Parser down to one file (i.e.
            use&nbsp;nested classes) to make it easier for people to add to
            their&nbsp;project.<br>
            <br>
            <br>
            On 17 Jul 2012, at 02:19, Rafael Benevides wrote:<br>
            <br>
            <blockquote type="cite">The latest version of the JBoss
              Stacks&nbsp;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&nbsp;just to illustrate how it should be. The
              archetypes will also&nbsp;follow the same structure.<br>
              <br>
              I committed the parser on the same repo because the parser
              is&nbsp;tied to the file format.<br>
              <br>
              The Stacks class is now the root of the Yaml file (
              more&nbsp;detail on 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&nbsp;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&nbsp;API.<br>
              <img name="Class Diagram.png"
                id="74b95004-b27b-4794-83e0-e9451f9afbb7"
                apple-width="yes" apple-height="yes"
                src="cid:part3.05040003.06090606@redhat.com"
                width="1000" height="762"><br>
            </blockquote>
            <br>
          </blockquote>
        </blockquote>
        <br>
      </div>
    </blockquote>
  </body>
</html>