[forge-dev] JBoss Stacks: Requirements
Rafael Benevides
benevides at redhat.com
Wed Aug 1 10:41:07 EDT 2012
It seens that making labels a Object we can parse the content.
After the tests I'll put more info.
Em 01-08-2012 11:35, Rafael Benevides escreveu:
> Sounds good!
>
> I'm making some tests with the Parser.
>
> The problem seems to be the root type of labels which I think that the
> format must be only Map<String, ?> in this case.
>
> I think that wont be possible to have two different types of labels :
>
> bom1
> labels: <- label is a map
> animals:
> breed:
>
> bom2
> labels: <- labels is a list
> - test1
> - test2: 2
>
> Em 01-08-2012 10:51, Pete Muir escreveu:
>> I'm not following that. Say we had:
>>
>> labels:
>> animals:
>> dog:
>> breed: collie
>> name: lassie
>> dog:
>> breed: labrador
>> name: spot
>>
>> then you could do:
>>
>> Map<String, Map<String, String>> animals = runtime.getLabel("animals");
>>
>> That is what I was thinking of.
>>
>>
>> On 1 Aug 2012, at 14:21, Rafael Benevides wrote:
>>
>>> Well, the problem in this case is not with the cast itself but the
>>> method signature would be useful only in map[key:value] structures
>>> where the value is always a string.
>>>
>>> I'm supposing that we can have structures like this: ['string',
>>> [listvalue1, listvalue2], [ {key1:value1} , {key2: value2} ] ] where
>>> strings and lists does not have names and some "things" can be on
>>> any level.
>>>
>>> maybe we can have two methods:
>>>
>>> public String getLabel(String label);<- Recursive search for map
>>> values based on its key
>>>
>>> public boolean hasLabel(String label);<- Recursive search for
>>> strings (alone or as a list item)
>>>
>>> Rafael Benevides | Senior Software Engineer
>>> Red Hat Brazil
>>> +55-61-9269-6576
>>>
>>> Better technology. Faster innovation. Powered by community
>>> collaboration.
>>> See how it works at redhat.com
>>>
>>>
>>> Em 31-07-2012 18:25, Pete Muir escreveu:
>>>> You can add a method like:
>>>>
>>>> public<T> List<T> getLabel(String name, T expectedType);
>>>>
>>>> which means the user can avoid a cast.
>>>>
>>>> On 31 Jul 2012, at 19:58, Rafael Benevides wrote:
>>>>
>>>>> I made some tests with a structure similar to what you suggested
>>>>>
>>>>> labels:
>>>>> - test1
>>>>> - test2: value2
>>>>> -
>>>>> - test31
>>>>> - test32 : value32
>>>>> -
>>>>> - test: 331
>>>>>
>>>>> This structure is possible making the labels property a
>>>>> List<Object>. So the person who uses the Parser will be
>>>>> responsible for cast labels[x] to String, List or Map.
>>>>>
>>>>> Is that ok for you ? If so, I'll change the labels from
>>>>> List<Properties> to List<Object> I don't think this cause a
>>>>> Branch update to Beta4.
>>>>>
>>>>> Em 31-07-2012 11:33, Pete Muir escreveu:
>>>>>> Rafael, is there a way, in the parser, to make the contents of a
>>>>>> label to be unconstrained? e.g. a label could contain a list of
>>>>>> things, recursively, as deep as we like. If we just parse that
>>>>>> into a recusive list<String> or list<properties> then it
>>>>>> should work I think.
>>>>>>
>>>>>> On 31 Jul 2012, at 15:34, Rafael Benevides wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> The latest is Beta3 -
>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/Beta3/stacks.yaml
>>>>>>>
>>>>>>> There is a minor format change in labels properties from Beta2
>>>>>>> (labels=List<String>) to Beta3 (labels=List<Properties>)
>>>>>>>
>>>>>>> Rafael Benevides | Senior Software Engineer
>>>>>>> Red Hat Brazil
>>>>>>> +55-61-9269-6576
>>>>>>>
>>>>>>> Better technology. Faster innovation. Powered by community
>>>>>>> collaboration.
>>>>>>> See how it works at redhat.com
>>>>>>>
>>>>>>>
>>>>>>> Em 31-07-2012 11:24, Pete Muir escreveu:
>>>>>>>> Max, your best source is
>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml
>>>>>>>> which I think is most up to date.
>>>>>>>>
>>>>>>>> There are three roots: BOMs, archetypes and runtimes. Runtimes
>>>>>>>> is what ties it all together though.
>>>>>>>>
>>>>>>>> On 31 Jul 2012, at 14:01, Max Rydahl Andersen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Sorry for getting in late (3 weeks PTO) - so if this is
>>>>>>>>> answered somewhere else please let me know :)
>>>>>>>>>
>>>>>>>>> Looking at the diagram i'm reading it as the runtime
>>>>>>>>> defines/contains the BOM/Archetypes since the runtime is the
>>>>>>>>> root or
>>>>>>>>> am I misreading this ?
>>>>>>>>>
>>>>>>>>> i.e. IMO an archetype has to be able to work with multiple
>>>>>>>>> versions, otherwise we need to release every archetype at
>>>>>>>>> every minor update of the runtime.
>>>>>>>>>
>>>>>>>>> Thus I assume i'm wrong in reading that, but just wanted to be
>>>>>>>>> sure "root of YAML file" is not the runtime.
>>>>>>>>>
>>>>>>>>> /max
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11 Jul 2012, at 14:00, Rafael Benevides
>>>>>>>>> <benevides at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Yesterday I started to work on this new yaml format and I
>>>>>>>>>> tried to capture all requirements that was discussed in this
>>>>>>>>>> Thread. The result was the following attached uml diagram.
>>>>>>>>>>
>>>>>>>>>> I think that's the better way to try comprehending what is
>>>>>>>>>> needed and what will be covered. Today (or maybe tomorrow)
>>>>>>>>>> I'll convert this idea to an example yaml file that is the
>>>>>>>>>> representation of the diagram.
>>>>>>>>>>
>>>>>>>>>> The closest of the idea is something like similar to:
>>>>>>>>>>
>>>>>>>>>> bom:&jboss-with-x
>>>>>>>>>> name: JBoss With X
>>>>>>>>>> description: lorem ipsum
>>>>>>>>>> otherProperties: otherValues
>>>>>>>>>> availableVersions:
>>>>>>>>>> - 1.0.0.Final
>>>>>>>>>> - 1.0.1.CR1
>>>>>>>>>>
>>>>>>>>>> bom:&jboss-with-y
>>>>>>>>>> name: JBoss With Y
>>>>>>>>>> description: lorem ipsum
>>>>>>>>>> otherProperties: otherValues
>>>>>>>>>> availableVersions:
>>>>>>>>>> - 1.0.0.Final
>>>>>>>>>> - 1.0.1.CR1
>>>>>>>>>>
>>>>>>>>>> runtime:&jbosseap6
>>>>>>>>>> version: 6.0
>>>>>>>>>> type: EAP
>>>>>>>>>> boms:
>>>>>>>>>> - *jboss-with-x
>>>>>>>>>> - *jboss-with-y
>>>>>>>>>> recommendedBOM: *jboss-with-x
>>>>>>>>>>
>>>>>>>>>> Em 03-07-2012 13:01, Rafael Benevides escreveu:
>>>>>>>>>>
>>>>>>>>>>> Em 03-07-2012 12:53, James Perkins escreveu:
>>>>>>>>>>>
>>>>>>>>>>>>> We could do that as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 7.0.1.Final:
>>>>>>>>>>>>> properties:
>>>>>>>>>>>>> arguments: -logmodule
>>>>>>>>>>>>> cli: not-available
>>>>>>>>>>>>>
>>>>>>>>>>>> I like this approach.
>>>>>>>>>>>>
>>>>>>>>>>> I like this approach either!
>>>>>>>>>>>
>>>>>>>>>> <Class Diagram.png>
>>>>>>>>>>
More information about the forge-dev
mailing list