[forge-dev] JBoss Stacks: Requirements

Pete Muir pmuir at redhat.com
Tue Jul 17 12:13:02 EDT 2012


I would basically like to offer the option of copy and paste.

On 17 Jul 2012, at 17:13, Rafael Benevides wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120717/77c80491/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Class Diagram.png
Type: image/png
Size: 155529 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/forge-dev/attachments/20120717/77c80491/attachment-0001.png 


More information about the forge-dev mailing list