Re: [forge-dev] JBoss Stacks: Requirements

Em 17-07-2012 13:08, Pete Muir escreveu: > > On 17 Jul 2012, at 17:09, Rafael Benevides wrote: > >> Ok, Pete. >> >> Well, But there are lot of other files that the parser results as Archetype, Bom, MajorRelease, MinorRelease, Runtime, RuntimeType, and Stacks classes > > Right, which is why I said we need to look at using nested classes. Now I get the idea. >> Sorry, Is there any special reason for you to prefer copying instead of dependency that I didn't realize? > > Yes, dependencies are evil. LOL :D >> >> 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. >>>>>> >>>>> >>> >