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(a)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>
>>>>>>>>>