Ok, Pete.

Well, But there are lot of other files that the parser results as Archetype, Bom, MajorRelease, MinorRelease, Runtime, RuntimeType, and Stacks classes

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. 

Sorry, Is there any special reason for you to prefer copying instead of dependency that I didn't realize?

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

Em 17-07-2012 12:56, Pete Muir escreveu:

Basically, the idea is to avoid a dependency, and allow people to just copy and paste the class into their project.

On 17 Jul 2012, at 16:51, Rafael Benevides wrote:

"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."

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 ?

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


Em 17-07-2012 11:31, Pete Muir escreveu:

Hi Rafael,

This is starting to look really good!

* I think we should add a labels: property to the BOM definitions, just to try to future proof a bit.
* 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.
* We should add the org.jboss.spec BOMs :-) These will make a better default for the runtimes
* 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)
* I don't think we need properties as, labels will cover this (a consumer can use a label to set up the right properties)

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.


On 17 Jul 2012, at 02:19, Rafael Benevides wrote:

The latest version of the JBoss Stacks format is right here: https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml 
I think that this format finally met our requirements.

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.

I committed the parser on the same repo because the parser is tied to the file format.

The Stacks class is now the root of the Yaml file ( more detail on attached diagram - modified since last email ).

The API use is simple as:

Stacks stacks = parser.parse(inputStream);

After we just navigate on the graph (various paths are possible):

stacks.getAvailableBoms().get(SOME);
stacks.getAvailableRuntimes().get(SOME);
stacks.getMajorReleases().get(SOME).getMinorReleases().get(OTHER).getRecommendedRuntime().getBoms().get(ANOTHER).
stacks.getMinorReleases().get(SOME).getRecommendedRuntime().getRecommendedBOM().getAvailableVersions();

Now I will update the jdf-plugin to use the jdf-stack parser API.