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&lt;benevides(a)redhat.com&gt; 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>

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&gt; >>> 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> >>>>

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&gt; >>>>> 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> >>>>>>

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&gt; >>>>>>> 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> >>>>>>>>

Yes, I think we can support only propeties for labels. On 1 Aug 2012, at 15:35, Rafael Benevides wrote: > 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&gt; >>>>>>>>> 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> >>>>>>>>>>