Sounds like a pretty chart / table marketing will like to use. ----- Original Message ----- > From: "Pete Muir" <pmuir(a)redhat.com&gt; > To: jdf-dev(a)lists.jboss.org, "forge-dev List" <forge-dev(a)lists.jboss.org&gt;, "James Perkins" <jperkins(a)redhat.com&gt;, > "Max Andersen" <manderse(a)redhat.com&gt;, "Rafael Benevides" <rbenevid(a)redhat.com&gt; > Sent: Monday, July 2, 2012 6:33:59 PM > Subject: [jdf-dev] JBoss Stacks: Requirements > > All, > > I chatted with Max at JBoss World about requirements for what I'm > code-naming JBoss Stacks, which is a really an extension of the > JBoss BOMs project. > > The JBoss Stacks project takes all the BOMs, all the archetypes, and > all the runtimes, and identifies which work with which. This can > then be used by tools (like JBDS, Forge, Maven plugins) to correctly > configure users projects. > > The stacks project requires 3 different dictionaries: > > * available BOMs > * available archetypes > * available runtimes > > and the ability to see the intersection between these things (i.e. if > I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM > is recommended, what archetypes are available, what is recommended). > > The runtime should include a download URL, so that plugins such as > James' AS plugin for forge can download it. It should also contain a > some options. I'm not sure exactly what is needed here, but James > can provide details and what makes most sense. > > The runtimes should include what type they are (e.g. JBoss AS, EAP) > to allow categorisation, filtering, sorting > > The Yaml parser in use should be pluggable, to avoid introducing > uncessary extra dependencies > > There should be a recommended runtime per major version and per minor > version (so you can say "I want JBoss AS 7" and you get back AS > 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back > 7.0.2.Final). > > We're going to need to be careful about compat, eventually, so we > need to get everything in there, and get it right. We'll have a long > beta cycle ;-) > > There will be a client utility, written in Java. This should be a > single source file, which projects can copy in. It must have no > dependencies other than a Yaml parser. > > I think Rafael is going to take the lead on this. But we'll decide on > Monday next week. > > Pete > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev >

All, I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. The stacks project requires 3 different dictionaries: * available BOMs * available archetypes * available runtimes and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense.

The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. I think Rafael is going to take the lead on this. But we'll decide on Monday next week. Pete

On 3 Jul 2012, at 00:23, James Perkins wrote: > On 07/02/2012 03:33 PM, Pete Muir wrote: >> All, >> >> I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. >> >> The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. >> >> The stacks project requires 3 different dictionaries: >> >> * available BOMs >> * available archetypes >> * available runtimes >> >> and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). >> >> The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. > So far the only information I would need is the version number, the current version (both seem to be taken care of so far) and whether or not the version of AS requires the -logmodule argument for JBoss Modules. Really since that's kind of a special use case it could just be hard-coded into the plugin code, but having some kind of metadata for something like that would be ideal IMO. So, should we have: arguments: [ -logmodule, -someOtherArgument] or logmodule-argument: required I think the former makes more sense. >> The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting >> >> The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies >> >> There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). >> >> We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) >> >> There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. >> >> I think Rafael is going to take the lead on this. But we'll decide on Monday next week. >> >> Pete > Overall I think this is a great idea. It will be great not to have to hard-code versions and do a new release every time something new comes out. > > One suggestion for the YAML; So far, what we have doesn't cover all the requirements I wrote here. > I see there is a availableVersions, which is great, but I also think a supportedVersions could be useful. > For example in the Forge plugin there is an option to execute CLI commands. That CLI API wasn't available until 7.1.1 IIRC. It *should* work for 7.0.x, but some operations that are available 7.1.1 might not be available in 7.0.x. I'm not sure what this means. What would be "supported"? We could have a: supported: [cli, full-profile] for each version to indicate capabilities. Possibly we just generalise that, and your logmodule thing, to labels: [cli, logmodule] and use "labels" as a place to put extended metadata that some tools want to use. > Also the packaging type could be useful too. Again with the AS 7 plugin it's downloading a ZIP file and extracting the directory structure. I think I was assuming it would always be a zip... But we can add this.

On 3 Jul 2012, at 16:14, James Perkins wrote: > The main idea behind the supportVersions (probably a bad name) was something like: > availableVersions: 7.0.0.Final, 7.0.1.Final, 7.0.2.Final, 7.1.0.Final, 7.1.1.Final > supportedVersions: 7.1.0.Final, 7.1.1.Final > Just meaning all available version should work, but everything is only guaranteed to work with the supportedVersions. Maybe a Beta or CR could be in available, but not fully supported as well. Just a thought that really isn't a big deal. Yeah, I guess what I'm not getting, is *what* is supported in that version, as that will change over time. That's why I was proposing a "labels" system, so you can tag a version as having a capability (like cli or logmodule-needed or whatever). This way we keep the info (I think) you want, but make it expandable.

> What I think would be ideal if it's possible would be to have a properties section with name value pairs. Then things like the -logmodule or -someOtherArgument could be used for anything. We could do that as well. 7.0.1.Final: properties: arguments: -logmodule cli: not-available

> I would think the AS downloads would always be a zip as well. If other consumers have no use for a packaging type it can be left off. Really if we can have a properties section it could be used in there if needed. Let's leave it out for now, and Max can comment when he is back.

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!

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!

Sorry James, _/otherProperties/_ was just a way to not write all those properties that is present in the diagram: type, url, version, etc Please, consider the diagram - and it's properties :) - as a guide that I'll to generate the yaml file. 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 11-07-2012 14:02, James Perkins escreveu: > The only thing I could think of is if we could also have > otherProperties for each available version. Other than that it looks > great to me. > > On 07/11/2012 05:00 AM, Rafael Benevides 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! > > -- > James R. Perkins > JBoss by Red Hat > >

Only comment is that we should have a labels: property, that allows arbitrary metadata to be attached to each top level item (bom, archetype, runtime), which will provide an extensible way for tools to interact with the data format. On 11 Jul 2012, at 13:00, Rafael Benevides 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! >

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

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

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.

> Sorry, Is there any special reason for you to prefer copying > instead of dependency that I didn't realize? Yes, dependencies are evil.

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

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>

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

All, I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. The stacks project requires 3 different dictionaries: * available BOMs * available archetypes * available runtimes and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. I think Rafael is going to take the lead on this. But we'll decide on Monday next week. Pete _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

Hi Everybody, Jay, Jonathan, Brian We are cataloging the Archetypes on JDF (as you can see on Pete's email below). Part of the Job was done - Get the YAML file format - https://github.com/jboss-jdf/jdf-stack/blob/master/stacks.yaml - YAML file Parser - https://github.com/jboss-jdf/jdf-stack/blob/master/Parser.java Those informations (BOMs, Runtimes, Archetypes) will be presented on JDF site. A preview can be found here: http://site-jdf.rhcloud.com/stack/stacks/ So the main point is: Do you want the errai, html5 and richfaces archetypes included also ?

Thank you 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 02-07-2012 19:33, Pete Muir escreveu: > > All, > > I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. > > The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. > > The stacks project requires 3 different dictionaries: > > * available BOMs > * available archetypes > * available runtimes > > and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). > > The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. > > The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting > > The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies > > There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). > > We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) > > There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. > > I think Rafael is going to take the lead on this. But we'll decide on Monday next week. > > Pete

We only want to know if you approve that. And will be helpful if you send the groupid:artifactId of the archetypes you want to include also :D I'll do the rest. 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 30-07-2012 10:36, Jay Balunas escreveu: > > > On Jul 30, 2012, at 9:12 AM, Rafael Benevides wrote: > >> Hi Everybody, >> >> Jay, Jonathan, Brian >> >> We are cataloging the Archetypes on JDF (as you can see on Pete's email below). >> >> Part of the Job was done >> >> - Get the YAML file format - https://github.com/jboss-jdf/jdf-stack/blob/master/stacks.yaml >> - YAML file Parser - https://github.com/jboss-jdf/jdf-stack/blob/master/Parser.java >> >> Those informations (BOMs, Runtimes, Archetypes) will be presented on JDF site. A preview can be found here: http://site-jdf.rhcloud.com/stack/stacks/ >> >> So the main point is: Do you want the errai, html5 and richfaces archetypes included also ? > > What would be needed to get them there? Depending on this, I think it would be good to include these archetypes in the list. > >> >> Thank you >> 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 02-07-2012 19:33, Pete Muir escreveu: >>> >>> All, >>> >>> I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. >>> >>> The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. >>> >>> The stacks project requires 3 different dictionaries: >>> >>> * available BOMs >>> * available archetypes >>> * available runtimes >>> >>> and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). >>> >>> The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. >>> >>> The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting >>> >>> The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies >>> >>> There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). >>> >>> We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) >>> >>> There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. >>> >>> I think Rafael is going to take the lead on this. But we'll decide on Monday next week. >>> >>> Pete > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

You mean like http://site-jdf.rhcloud.com/stack/plugin-jdf/ ? On 30 Jul 2012, at 15:19, George Gastaldi wrote: > Hi all, > > Instead of a client utility, what do you say about creating a Forge plugin for this and use Forge ? > > Em 30/07/2012, às 10:51, Rafael Benevides <benevides(a)redhat.com&gt; escreveu: > >> We only want to know if you approve that. And will be helpful if you send the groupid:artifactId of the archetypes you want to include also :D >> >> I'll do the rest. >> 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 30-07-2012 10:36, Jay Balunas escreveu: >>> >>> On Jul 30, 2012, at 9:12 AM, Rafael Benevides wrote: >>> >>>> Hi Everybody, >>>> >>>> Jay, Jonathan, Brian >>>> >>>> We are cataloging the Archetypes on JDF (as you can see on Pete's email below). >>>> >>>> Part of the Job was done >>>> >>>> - Get the YAML file format - https://github.com/jboss-jdf/jdf-stack/blob/master/stacks.yaml >>>> - YAML file Parser - https://github.com/jboss-jdf/jdf-stack/blob/master/Parser.java >>>> >>>> Those informations (BOMs, Runtimes, Archetypes) will be presented on JDF site. A preview can be found here: http://site-jdf.rhcloud.com/stack/stacks/ >>>> >>>> So the main point is: Do you want the errai, html5 and richfaces archetypes included also ? >>> >>> What would be needed to get them there? Depending on this, I think it would be good to include these archetypes in the list. >>> >>>> >>>> Thank you >>>> 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 02-07-2012 19:33, Pete Muir escreveu: >>>>> All, >>>>> >>>>> I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. >>>>> >>>>> The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. >>>>> >>>>> The stacks project requires 3 different dictionaries: >>>>> >>>>> * available BOMs >>>>> * available archetypes >>>>> * available runtimes >>>>> >>>>> and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). >>>>> >>>>> The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. >>>>> >>>>> The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting >>>>> >>>>> The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies >>>>> >>>>> There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). >>>>> >>>>> We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) >>>>> >>>>> There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. >>>>> >>>>> I think Rafael is going to take the lead on this. But we'll decide on Monday next week. >>>>> >>>>> Pete >>>>> >>> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev

cc'ing in Fred and Snjezana for back ground info Fred/Snjezana you know we got the problem of projectexamples/central is currently limited to handle a known set of archetypes against a known set of runtimes - Pete and others have been working on this thing called a stacks.yml which helps define which Stacks, bom, archetype, runtime that works together and even provided a little utility class to parse and traverse this file. Example of this is at https://github.com/jboss-jdf/jdf-stack/blob/Beta2/stacks.yaml picture outlining the format. Pete et.al. you guys got any other pointers or docs for this or is the above all there is to it ? (I think it is ;)

Snjezana/Fred: Would be great if you had questions/input on this format from perspective of the tools. On my first glance its looking really good but I'll need to find some time to go over all the scenarios we have and see if we can get it to fit in and/or what we need to change to handle the higher flexibility here.

/max On 30 Jul 2012, at 16:29, Pete Muir <pmuir(a)redhat.com&gt; wrote: > You mean like http://site-jdf.rhcloud.com/stack/plugin-jdf/ ? > > > On 30 Jul 2012, at 15:19, George Gastaldi wrote: > >> Hi all, >> >> Instead of a client utility, what do you say about creating a Forge plugin for this and use Forge ? >> >> Em 30/07/2012, às 10:51, Rafael Benevides <benevides(a)redhat.com&gt; escreveu: >> >>> We only want to know if you approve that. And will be helpful if you send the groupid:artifactId of the archetypes you want to include also :D >>> >>> I'll do the rest. >>> 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 30-07-2012 10:36, Jay Balunas escreveu: >>>> >>>> On Jul 30, 2012, at 9:12 AM, Rafael Benevides wrote: >>>> >>>>> Hi Everybody, >>>>> >>>>> Jay, Jonathan, Brian >>>>> >>>>> We are cataloging the Archetypes on JDF (as you can see on Pete's email below). >>>>> >>>>> Part of the Job was done >>>>> >>>>> - Get the YAML file format - https://github.com/jboss-jdf/jdf-stack/blob/master/stacks.yaml >>>>> - YAML file Parser - https://github.com/jboss-jdf/jdf-stack/blob/master/Parser.java >>>>> >>>>> Those informations (BOMs, Runtimes, Archetypes) will be presented on JDF site. A preview can be found here: http://site-jdf.rhcloud.com/stack/stacks/ >>>>> >>>>> So the main point is: Do you want the errai, html5 and richfaces archetypes included also ? >>>> >>>> What would be needed to get them there? Depending on this, I think it would be good to include these archetypes in the list. >>>> >>>>> >>>>> Thank you >>>>> 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 02-07-2012 19:33, Pete Muir escreveu: >>>>>> All, >>>>>> >>>>>> I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. >>>>>> >>>>>> The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. >>>>>> >>>>>> The stacks project requires 3 different dictionaries: >>>>>> >>>>>> * available BOMs >>>>>> * available archetypes >>>>>> * available runtimes >>>>>> >>>>>> and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). >>>>>> >>>>>> The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. >>>>>> >>>>>> The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting >>>>>> >>>>>> The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies >>>>>> >>>>>> There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). >>>>>> >>>>>> We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) >>>>>> >>>>>> There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. >>>>>> >>>>>> I think Rafael is going to take the lead on this. But we'll decide on Monday next week. >>>>>> >>>>>> Pete >>>>>> >>>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >

On Jul 30, 2012, at 9:51 AM, Rafael Benevides wrote: > We only want to know if you approve that. And will be helpful if you > send the groupid:artifactId of the archetypes you want to include also :D Awesome!! I think this will be a good listing to get people started. The AeroGear HTML5/Mobile archetype used in JBoss Central is located at: Group: org.jboss.aerogear.archetypes Artifact: jboss-html5-mobile-archetype Version: 1.0.0.M4b This corresponds to the same html5/mobile kitchensink quickstart that is in JDF. > > I'll do the rest. > Rafael Benevides | Senior Software Engineer > Red Hat Brazil > +55-61-9269-6576 > > Better technology. Faster innovation. Powered by community collaboration. > See how it works atredhat.com <http://redhat.com> > > Em 30-07-2012 10:36, Jay Balunas escreveu: >> >> On Jul 30, 2012, at 9:12 AM, Rafael Benevides wrote: >> >>> Hi Everybody, >>> >>> Jay, Jonathan, Brian >>> >>> We are cataloging the Archetypes on JDF (as you can see on Pete's >>> email below). >>> >>> Part of the Job was done >>> >>> - Get the YAML file format - >>> https://github.com/jboss-jdf/jdf-stack/blob/master/stacks.yaml >>> - YAML file Parser - >>> https://github.com/jboss-jdf/jdf-stack/blob/master/Parser.java >>> >>> Those informations (BOMs, Runtimes, Archetypes) will be presented >>> on JDF site. A preview can be found here: >>> http://site-jdf.rhcloud.com/stack/stacks/ >>> >>> So the main point is: Do you want the errai, html5 and richfaces >>> archetypes included also ? >> >> What would be needed to get them there? Depending on this, I think >> it would be good to include these archetypes in the list. >> >>> >>> Thank you >>> Rafael Benevides | Senior Software Engineer >>> Red Hat Brazil >>> +55-61-9269-6576 >>> >>> Better technology. Faster innovation. Powered by community collaboration. >>> See how it works atredhat.com <http://redhat.com/> >>> >>> Em 02-07-2012 19:33, Pete Muir escreveu: >>>> All, >>>> >>>> I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. >>>> >>>> The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. >>>> >>>> The stacks project requires 3 different dictionaries: >>>> >>>> * available BOMs >>>> * available archetypes >>>> * available runtimes >>>> >>>> and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). >>>> >>>> The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. >>>> >>>> The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting >>>> >>>> The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies >>>> >>>> There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). >>>> >>>> We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) >>>> >>>> There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. >>>> >>>> I think Rafael is going to take the lead on this. But we'll decide on Monday next week. >>>> >>>> Pete >> > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org <mailto:jdf-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/jdf-dev

Thanks Jay, Jonathan, Brian Archetypes added to https://github.com/jboss-jdf/jdf-stack/blob/Beta3/stacks.yaml Jay, HTML5 was already there through groupId: org.jboss.spec.archetypes artifact Id : jboss-html5-mobile-archetype version: 7.0.2.CR2 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 30-07-2012 23:34, Brian Leathem escreveu: > Jay, Jonathan, Brian _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

On Jul 31, 2012, at 5:26 PM, Pete Muir wrote: > I think this is the right one for HTML5 :-) > > http://search.maven.org/#artifactdetails%7Corg.jboss.aerogear.archetypes%... Stop reading my mind! I was literally just writing the same email ;-) > On 31 Jul 2012, at 20:37, Rafael Benevides wrote: > >> Thanks Jay, Jonathan, Brian >> >> Archetypes added to https://github.com/jboss-jdf/jdf-stack/blob/Beta3/stacks.yaml >> >> Jay, >> >> HTML5 was already there through >> >> groupId: org.jboss.spec.archetypes >> artifact >> Id >> : jboss-html5-mobile-archetype >> version: >> 7.0.2.CR2 >> >> >> >> >> >> 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 30-07-2012 23:34, Brian Leathem escreveu: >>> Jay, Jonathan, Brian >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev

Hi Rafael, This project sounds great! Anything that can help people sort through all the dependencies they need to get started with Errai will be a big help. Our Kitchen Sink archetype is org.jboss.errai.archetypes: jboss-errai-kitchensink-archetype: 2.0.2.Final. There will also soon be a 2.1.0-SNAPSHOT, but it's probably best to stick with the released version for JBoss Stacks.

-Jonathan From: "Rafael Benevides" <benevides(a)redhat.com&gt; To: "Pete Muir" <pmuir(a)redhat.com&gt; Cc: jdf-dev(a)lists.jboss.org, "forge-dev List" <forge-dev(a)lists.jboss.org&gt;, "James Perkins" <jperkins(a)redhat.com&gt;, "Max Andersen" <manderse(a)redhat.com&gt;, "Jay Balunas" <jbalunas(a)redhat.com&gt;, "Jonathan Fuerth" <jfuerth(a)redhat.com&gt;, "Brian Leathem" <bleathem(a)redhat.com&gt; Sent: Monday, July 30, 2012 9:12:50 AM Subject: Re: JBoss Stacks: Requirements Hi Everybody, Jay, Jonathan, Brian We are cataloging the Archetypes on JDF (as you can see on Pete's email below). Part of the Job was done - Get the YAML file format - https://github.com/jboss-jdf/jdf-stack/blob/master/stacks.yaml - YAML file Parser - https://github.com/jboss-jdf/jdf-stack/blob/master/Parser.java Those informations (BOMs, Runtimes, Archetypes) will be presented on JDF site. A preview can be found here: http://site-jdf.rhcloud.com/stack/stacks/ So the main point is: Do you want the errai, html5 and richfaces archetypes included also ? Thank you 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 02-07-2012 19:33, Pete Muir escreveu: All, I chatted with Max at JBoss World about requirements for what I'm code-naming JBoss Stacks, which is a really an extension of the JBoss BOMs project. The JBoss Stacks project takes all the BOMs, all the archetypes, and all the runtimes, and identifies which work with which. This can then be used by tools (like JBDS, Forge, Maven plugins) to correctly configure users projects. The stacks project requires 3 different dictionaries: * available BOMs * available archetypes * available runtimes and the ability to see the intersection between these things (i.e. if I'm on runtime version 1.2.3.Final, what BOMs are possible, what BOM is recommended, what archetypes are available, what is recommended). The runtime should include a download URL, so that plugins such as James' AS plugin for forge can download it. It should also contain a some options. I'm not sure exactly what is needed here, but James can provide details and what makes most sense. The runtimes should include what type they are (e.g. JBoss AS, EAP) to allow categorisation, filtering, sorting The Yaml parser in use should be pluggable, to avoid introducing uncessary extra dependencies There should be a recommended runtime per major version and per minor version (so you can say "I want JBoss AS 7" and you get back AS 7.1.1.Final or you can say "I want JBoss AS 7.0" and you get back 7.0.2.Final). We're going to need to be careful about compat, eventually, so we need to get everything in there, and get it right. We'll have a long beta cycle ;-) There will be a client utility, written in Java. This should be a single source file, which projects can copy in. It must have no dependencies other than a Yaml parser. I think Rafael is going to take the lead on this. But we'll decide on Monday next week. Pete _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev