<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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 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><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. </div><div>See how it works at <a 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 definitions, just to try to future proof a bit.<br>* 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.<br>* We should add the org.jboss.spec BOMs :-) These will make a better default for the runtimes<br>* 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)<br>* I don't think we need properties as, labels will cover this (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 nested classes) to make it easier for people to add to their 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 format is right here: <a href="https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml">https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml</a> <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 to illustrate how it should be. The archetypes will also follow the same structure.<br><br>I committed the parser on the same repo because the parser is tied to the file format.<br><br>The Stacks class is now the root of the Yaml file ( more 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 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" width="1000" height="762" src="cid:part2.09090707.03000304@redhat.com"><br></blockquote><br></blockquote></blockquote><br></div></body></html>