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 <
http://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 <
http://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.
>>>>>
>>>>
>>