Hi all, As part of the "new organization" plan, it's a good time to update stacks format since it will be hosted on the new github organization. I've analyzed the changes need and attached a Stacks 1.1 proposal to see if everyone agrees on that or if should we keep using 1.0 format Changes from 1.0 to 1.1 - Rename Licenses to Metadata Justification: I've been using Licenses today as an metadata section to avoid repeating metadatas like version, repositories, licenses, etc: https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 Workaround: Leave it as it is - add repositoryURL and extraRepositories to BomVersion. Justification: I've been using labels to to tag what repositories are Required: https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 - Some BOMs needs more than one repo as JPP ( JPP is built on top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 that is built on top of EAP 6.0.0) Workaround: Create an standard tag called *repositories* and add every non maven central repository required. So I'd like to here your thoughts about it and analyze possible impacts on this format change. OBS.: Remember that stacks 1.0 repo is planned to be moved to jboss-developer github organization. So it's a good change to update it. The 1.0 and 1.1 should coexist for a while and maybe stacks-client should have a "migration" feature to permit a smooth transition. 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 _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: > Hi all, > > I'm resurrecting this subject because Forge Team started to > brainstorm about the Stacks Add-on to Forge. > > Max, > > Do you have some thoughts/considerations on this: > > - Change format (getting the opportunity of repo location change) > vs > - Still using the same format with workarounds I would like that Fred B. takes a look at this and give his feedback since he been doing most of the license/repositoryurl workarounds we need. But from top of my head: I don't see how stacks 1.0 can change location (i.e. url) since that will break JBDS 7.0/JBT 4.1 users. Are you really talking about a physical move, or simply where you would out the "next" version ? The 1.0 url is stuck and should stay there for years from what I can see. About "rename licenses to metdata"...I never realized those names were tied to element defined as licenses. Shouldn't it be licenses AND releaseversions or something ? what other metadata is needed here ? ...and if it is just to avoid repeating it is this just like "entities" like in a DTD ? About "repositoryUrl and extrarepositories" to bomversion then this seem to be a variation on how we in eclipse decides wether we need to add something to the users settings.xml or not ? In that case then repositoryurl/extrarepositories are not the only information relevant. Its more relevant to know which key artifacts to look for. We added that to our own examples metadata - Fred knows more. Then based on the availability of these artifaacts we either warn or not. If a warning we then suggest to add maven.enterprise.redhat.com/techpreview/all to the ~/.m2/settings.xml. We do *not* add invidivual repositories (like EAP600 and EAP601) to users settings nor pom.xml - that would be bad form IMO. In any case - I don't think repositoryurl and extrarepositories are good on its own - needs more info. My biggest gotcha with upcoming changes is how the tools can/should cope with archetypes not having enterprise flag anymore. That at least from where I'm looking changes the workflow we need to provide to the user since we just starts with user requesting "Create a JavaEE Web app" ...and how do we ensure the archetypes stay consistent (before just a simple flag) now its spread between multiple repositories/archetype versions. /max > > Thanks > > Em 12/07/13 10:47, Rafael Benevides escreveu: >> Hi all, >> >> As part of the "new organization" plan, it's a good time to update >> stacks format since it will be hosted on the new github organization. >> I've analyzed the changes need and attached a Stacks 1.1 proposal to >> see if everyone agrees on that or if should we keep using 1.0 format >> >> Changes from 1.0 to 1.1 >> >> - Rename Licenses to Metadata >> >> Justification: I've been using Licenses today as an metadata >> section to avoid repeating metadatas like version, >> repositories, licenses, etc: >> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >> >> Workaround: Leave it as it is >> >> - add repositoryURL and extraRepositories to BomVersion. >> >> Justification: I've been using labels to to tag what >> repositories are Required: >> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >> >> - Some BOMs needs more than one repo as JPP ( JPP is built on >> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >> that is built on top of EAP 6.0.0) >> >> Workaround: Create an standard tag called *repositories* and >> add every non maven central repository required. >> >> So I'd like to here your thoughts about it and analyze possible >> impacts on this format change. >> OBS.: Remember that stacks 1.0 repo is planned to be moved to >> jboss-developer github organization. So it's a good change to update >> it. The 1.0 and 1.1 should coexist for a while and maybe >> stacks-client should have a "migration" feature to permit a smooth >> transition. >> >> 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 >> >> >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev >

On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: > I probably missed it but where does it say the enterprise flag goes > away for archetypes? thats in the other thread(s) about changing the way things are released/versioned. Here it was suggested archetypes would be productized similar to quickstarts, thus there would be forks/duplicates instead of one version we could use and then toggle between one or the other target..thus no enterprise flag. At least thats how I understood the proposal and we should work with Rafael on that. /max > Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >> >> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>> Hi all, >>> >>> I'm resurrecting this subject because Forge Team started to >>> brainstorm about the Stacks Add-on to Forge. >>> >>> Max, >>> >>> Do you have some thoughts/considerations on this: >>> >>> - Change format (getting the opportunity of repo location change) >>> vs >>> - Still using the same format with workarounds >> >> I would like that Fred B. takes a look at this and give his feedback >> since he been doing most of the license/repositoryurl workarounds we >> need. >> >> But from top of my head: >> >> I don't see how stacks 1.0 can change location (i.e. url) since that >> will break JBDS 7.0/JBT 4.1 users. Are you really talking about a >> physical move, or simply where you would out the "next" version ? >> The 1.0 url is stuck and should stay there for years from what I can >> see. >> >> About "rename licenses to metdata"...I never realized those names >> were tied to element defined as licenses. Shouldn't it be licenses >> AND releaseversions or something ? what other metadata is needed >> here ? ...and if it is just to avoid repeating it is this just like >> "entities" like in a DTD ? >> About "repositoryUrl and extrarepositories" to bomversion then this >> seem to be a variation on how we in eclipse decides wether we need >> to add something to the users settings.xml or not ? In that case >> then repositoryurl/extrarepositories are not the only information >> relevant. Its more relevant to know which key artifacts to look for. >> We added that to our own examples metadata - Fred knows more. >> >> Then based on the availability of these artifaacts we either warn or >> not. If a warning we then suggest to add >> maven.enterprise.redhat.com/techpreview/all to the >> ~/.m2/settings.xml. We do *not* add invidivual repositories (like >> EAP600 and EAP601) to users settings nor pom.xml - that would be bad >> form IMO. In any case - I don't think repositoryurl and >> extrarepositories are good on its own - needs more info. >> >> My biggest gotcha with upcoming changes is how the tools can/should >> cope with archetypes not having enterprise flag anymore. That at >> least from where I'm looking changes the workflow we need to provide >> to the user since we just starts with user requesting "Create a >> JavaEE Web app" ...and how do we ensure the archetypes stay >> consistent (before just a simple flag) now its spread between >> multiple repositories/archetype versions. >> >> >> /max >> >>> >>> Thanks >>> >>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>> Hi all, >>>> >>>> As part of the "new organization" plan, it's a good time to update >>>> stacks format since it will be hosted on the new github organization. >>>> I've analyzed the changes need and attached a Stacks 1.1 proposal >>>> to see if everyone agrees on that or if should we keep using 1.0 >>>> format >>>> >>>> Changes from 1.0 to 1.1 >>>> >>>> - Rename Licenses to Metadata >>>> >>>> Justification: I've been using Licenses today as an metadata >>>> section to avoid repeating metadatas like version, >>>> repositories, licenses, etc: >>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>> >>>> >>>> Workaround: Leave it as it is >>>> >>>> - add repositoryURL and extraRepositories to BomVersion. >>>> >>>> Justification: I've been using labels to to tag what >>>> repositories are Required: >>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>> >>>> >>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>> that is built on top of EAP 6.0.0) >>>> >>>> Workaround: Create an standard tag called *repositories* and >>>> add every non maven central repository required. >>>> >>>> So I'd like to here your thoughts about it and analyze possible >>>> impacts on this format change. >>>> OBS.: Remember that stacks 1.0 repo is planned to be moved to >>>> jboss-developer github organization. So it's a good change to >>>> update it. The 1.0 and 1.1 should coexist for a while and maybe >>>> stacks-client should have a "migration" feature to permit a smooth >>>> transition. >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> jdf-dev mailing list >>>> jdf-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>> >

You're right Max. That was the proposal. And we should think a little bit more about the workflow since the plan is to change Archetypes GAV to: org.jboss.archetypes.eap: jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X I believe that the "product focus" idea is to have this EAP archetypes as the default of "Create a Java EE XXX app..." (without enterprise flag) but my concern is about the setup of EAP repository setup.

I could be wrong but that's is how I understand that part of the plan. Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>I probably missed it but where does it say the enterprise flag >>goes away for archetypes? > >thats in the other thread(s) about changing the way things are >released/versioned. > >Here it was suggested archetypes would be productized similar to >quickstarts, thus >there would be forks/duplicates instead of one version we could use >and then toggle >between one or the other target..thus no enterprise flag. > >At least thats how I understood the proposal and we should work with >Rafael on >that. > > >/max > >>Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>> >>>On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>Hi all, >>>> >>>>I'm resurrecting this subject because Forge Team started to >>>>brainstorm about the Stacks Add-on to Forge. >>>> >>>>Max, >>>> >>>>Do you have some thoughts/considerations on this: >>>> >>>>- Change format (getting the opportunity of repo location change) >>>>vs >>>>- Still using the same format with workarounds >>> >>>I would like that Fred B. takes a look at this and give his >>>feedback since he been doing most of the license/repositoryurl >>>workarounds we need. >>> >>>But from top of my head: >>> >>>I don't see how stacks 1.0 can change location (i.e. url) since >>>that will break JBDS 7.0/JBT 4.1 users. Are you really talking >>>about a physical move, or simply where you would out the "next" >>>version ? The 1.0 url is stuck and should stay there for years >>>from what I can see. >>> >>>About "rename licenses to metdata"...I never realized those >>>names were tied to element defined as licenses. Shouldn't it be >>>licenses AND releaseversions or something ? what other metadata >>>is needed here ? ...and if it is just to avoid repeating it is >>>this just like "entities" like in a DTD ? >>>About "repositoryUrl and extrarepositories" to bomversion then >>>this seem to be a variation on how we in eclipse decides wether >>>we need to add something to the users settings.xml or not ? In >>>that case then repositoryurl/extrarepositories are not the only >>>information relevant. Its more relevant to know which key >>>artifacts to look for. We added that to our own examples >>>metadata - Fred knows more. >>> >>>Then based on the availability of these artifaacts we either >>>warn or not. If a warning we then suggest to add >>>maven.enterprise.redhat.com/techpreview/all to the >>>~/.m2/settings.xml. We do *not* add invidivual repositories >>>(like EAP600 and EAP601) to users settings nor pom.xml - that >>>would be bad form IMO. In any case - I don't think repositoryurl >>>and extrarepositories are good on its own - needs more info. >>> >>>My biggest gotcha with upcoming changes is how the tools >>>can/should cope with archetypes not having enterprise flag >>>anymore. That at least from where I'm looking changes the >>>workflow we need to provide to the user since we just starts >>>with user requesting "Create a JavaEE Web app" ...and how do we >>>ensure the archetypes stay consistent (before just a simple >>>flag) now its spread between multiple repositories/archetype >>>versions. >>> >>> >>>/max >>> >>>> >>>>Thanks >>>> >>>>Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>Hi all, >>>>> >>>>>As part of the "new organization" plan, it's a good time to >>>>>update stacks format since it will be hosted on the new >>>>>github organization. >>>>>I've analyzed the changes need and attached a Stacks 1.1 >>>>>proposal to see if everyone agrees on that or if should we >>>>>keep using 1.0 format >>>>> >>>>>Changes from 1.0 to 1.1 >>>>> >>>>> - Rename Licenses to Metadata >>>>> >>>>> Justification: I've been using Licenses today as an metadata >>>>> section to avoid repeating metadatas like version, >>>>> repositories, licenses, etc: >>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>> >>>>> >>>>> Workaround: Leave it as it is >>>>> >>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>> >>>>> Justification: I've been using labels to to tag what >>>>> repositories are Required: >>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>> >>>>> >>>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>> that is built on top of EAP 6.0.0) >>>>> >>>>> Workaround: Create an standard tag called *repositories* and >>>>> add every non maven central repository required. >>>>> >>>>>So I'd like to here your thoughts about it and analyze >>>>>possible impacts on this format change. >>>>>OBS.: Remember that stacks 1.0 repo is planned to be moved >>>>>to jboss-developer github organization. So it's a good >>>>>change to update it. The 1.0 and 1.1 should coexist for a >>>>>while and maybe stacks-client should have a "migration" >>>>>feature to permit a smooth transition. >>>>> >>>>>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 >>>>> >>>>> >>>>>_______________________________________________ >>>>>jdf-dev mailing list >>>>>jdf-dev(a)lists.jboss.org >>>>>https://lists.jboss.org/mailman/listinfo/jdf-dev >>>> >>

Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>You're right Max. >> >>That was the proposal. And we should think a little bit more about >>the workflow since the plan is to change Archetypes GAV to: >>org.jboss.archetypes.eap: >>jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >> >>I believe that the "product focus" idea is to have this EAP >>archetypes as the default of "Create a Java EE XXX app..." >>(without enterprise flag) but my concern is about the setup of EAP >>repository setup. > >That part is the smallest problem ;) We already support it. > >Try create an enterprise archetype in JBDS while running with >~/.m2/settings.xml that does >*not* have access to the enterprise artifacts. We'll warn and guide >you to add maven.repository url) > >We do that based on a list of key artifacts we check - this is >currently outside stacks.yml, >but could probably make sense to add this bit of info so other than >jbds can do similar things. > >My main concern is how to find out which archetypes that matches and >how to toggle/manage them. Shouldn't this new GAV change help you to find out ?

> >/max > > >>I could be wrong but that's is how I understand that part of the plan. >> >> >>Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>I probably missed it but where does it say the enterprise flag >>>>goes away for archetypes? >>> >>>thats in the other thread(s) about changing the way things are >>>released/versioned. >>> >>>Here it was suggested archetypes would be productized similar to >>>quickstarts, thus >>>there would be forks/duplicates instead of one version we could >>>use and then toggle >>>between one or the other target..thus no enterprise flag. >>> >>>At least thats how I understood the proposal and we should work >>>with Rafael on >>>that. >>> >>> >>>/max >>> >>>>Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>> >>>>>On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>Hi all, >>>>>> >>>>>>I'm resurrecting this subject because Forge Team started >>>>>>to brainstorm about the Stacks Add-on to Forge. >>>>>> >>>>>>Max, >>>>>> >>>>>>Do you have some thoughts/considerations on this: >>>>>> >>>>>>- Change format (getting the opportunity of repo location change) >>>>>>vs >>>>>>- Still using the same format with workarounds >>>>> >>>>>I would like that Fred B. takes a look at this and give his >>>>>feedback since he been doing most of the >>>>>license/repositoryurl workarounds we need. >>>>> >>>>>But from top of my head: >>>>> >>>>>I don't see how stacks 1.0 can change location (i.e. url) >>>>>since that will break JBDS 7.0/JBT 4.1 users. Are you really >>>>>talking about a physical move, or simply where you would out >>>>>the "next" version ? The 1.0 url is stuck and should stay >>>>>there for years from what I can see. >>>>> >>>>>About "rename licenses to metdata"...I never realized those >>>>>names were tied to element defined as licenses. Shouldn't it >>>>>be licenses AND releaseversions or something ? what other >>>>>metadata is needed here ? ...and if it is just to avoid >>>>>repeating it is this just like "entities" like in a DTD ? >>>>>About "repositoryUrl and extrarepositories" to bomversion >>>>>then this seem to be a variation on how we in eclipse >>>>>decides wether we need to add something to the users >>>>>settings.xml or not ? In that case then >>>>>repositoryurl/extrarepositories are not the only information >>>>>relevant. Its more relevant to know which key artifacts to >>>>>look for. We added that to our own examples metadata - Fred >>>>>knows more. >>>>> >>>>>Then based on the availability of these artifaacts we either >>>>>warn or not. If a warning we then suggest to add >>>>>maven.enterprise.redhat.com/techpreview/all to the >>>>>~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>(like EAP600 and EAP601) to users settings nor pom.xml - >>>>>that would be bad form IMO. In any case - I don't think >>>>>repositoryurl and extrarepositories are good on its own - >>>>>needs more info. >>>>> >>>>>My biggest gotcha with upcoming changes is how the tools >>>>>can/should cope with archetypes not having enterprise flag >>>>>anymore. That at least from where I'm looking changes the >>>>>workflow we need to provide to the user since we just starts >>>>>with user requesting "Create a JavaEE Web app" ...and how do >>>>>we ensure the archetypes stay consistent (before just a >>>>>simple flag) now its spread between multiple >>>>>repositories/archetype versions. >>>>> >>>>> >>>>>/max >>>>> >>>>>> >>>>>>Thanks >>>>>> >>>>>>Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>Hi all, >>>>>>> >>>>>>>As part of the "new organization" plan, it's a good time >>>>>>>to update stacks format since it will be hosted on the >>>>>>>new github organization. >>>>>>>I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>proposal to see if everyone agrees on that or if should >>>>>>>we keep using 1.0 format >>>>>>> >>>>>>>Changes from 1.0 to 1.1 >>>>>>> >>>>>>> - Rename Licenses to Metadata >>>>>>> >>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>> section to avoid repeating metadatas like version, >>>>>>> repositories, licenses, etc: >>>>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Workaround: Leave it as it is >>>>>>> >>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>> >>>>>>> Justification: I've been using labels to to tag what >>>>>>> repositories are Required: >>>>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>> >>>>>>> >>>>>>> >>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>> that is built on top of EAP 6.0.0) >>>>>>> >>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>> add every non maven central repository required. >>>>>>> >>>>>>>So I'd like to here your thoughts about it and analyze >>>>>>>possible impacts on this format change. >>>>>>>OBS.: Remember that stacks 1.0 repo is planned to be >>>>>>>moved to jboss-developer github organization. So it's a >>>>>>>good change to update it. The 1.0 and 1.1 should coexist >>>>>>>for a while and maybe stacks-client should have a >>>>>>>"migration" feature to permit a smooth transition. >>>>>>> >>>>>>>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 >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>jdf-dev mailing list >>>>>>>jdf-dev(a)lists.jboss.org >>>>>>>https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>> >>>> >>

On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: > > Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>> You're right Max. >>> >>> That was the proposal. And we should think a little bit more about the workflow since the plan is to change Archetypes GAV to: org.jboss.archetypes.eap: jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>> >>> I believe that the "product focus" idea is to have this EAP archetypes as the default of "Create a Java EE XXX app..." (without enterprise flag) but my concern is about the setup of EAP repository setup. >> >> That part is the smallest problem ;) We already support it. >> >> Try create an enterprise archetype in JBDS while running with ~/.m2/settings.xml that does >> *not* have access to the enterprise artifacts. We'll warn and guide you to add maven.repository url) >> >> We do that based on a list of key artifacts we check - this is currently outside stacks.yml, >> but could probably make sense to add this bit of info so other than jbds can do similar things. >> >> My main concern is how to find out which archetypes that matches and how to toggle/manage them. > > Shouldn't this new GAV change help you to find out ? I would rather not rely on GAV to decide that if can be avoided. But your suggestion is that the group "org.jboss.archetypes.eap" decides it - which would be the "non-product" version ? there is no 1-to-1 mapping. Thing is that we loose the ability to toggle when the mvn wizard is running - the decision have to be made upfront. But I think we'll just have to drop that "feature" and force users to know more upfront - possibly in the case no runtime is known give them a choice of possible archetypes for JavaEE ? Fred - do you forsee issues/concerns ? /max >> >> /max >> >> >>> I could be wrong but that's is how I understand that part of the plan. >>> >>> >>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>> I probably missed it but where does it say the enterprise flag goes away for archetypes? >>>> >>>> thats in the other thread(s) about changing the way things are released/versioned. >>>> >>>> Here it was suggested archetypes would be productized similar to quickstarts, thus >>>> there would be forks/duplicates instead of one version we could use and then toggle >>>> between one or the other target..thus no enterprise flag. >>>> >>>> At least thats how I understood the proposal and we should work with Rafael on >>>> that. >>>> >>>> >>>> /max >>>> >>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>> >>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I'm resurrecting this subject because Forge Team started to brainstorm about the Stacks Add-on to Forge. >>>>>>> >>>>>>> Max, >>>>>>> >>>>>>> Do you have some thoughts/considerations on this: >>>>>>> >>>>>>> - Change format (getting the opportunity of repo location change) >>>>>>> vs >>>>>>> - Still using the same format with workarounds >>>>>> >>>>>> I would like that Fred B. takes a look at this and give his feedback since he been doing most of the license/repositoryurl workarounds we need. >>>>>> >>>>>> But from top of my head: >>>>>> >>>>>> I don't see how stacks 1.0 can change location (i.e. url) since that will break JBDS 7.0/JBT 4.1 users. Are you really talking about a physical move, or simply where you would out the "next" version ? The 1.0 url is stuck and should stay there for years from what I can see. >>>>>> >>>>>> About "rename licenses to metdata"...I never realized those names were tied to element defined as licenses. Shouldn't it be licenses AND releaseversions or something ? what other metadata is needed here ? ...and if it is just to avoid repeating it is this just like "entities" like in a DTD ? >>>>>> About "repositoryUrl and extrarepositories" to bomversion then this seem to be a variation on how we in eclipse decides wether we need to add something to the users settings.xml or not ? In that case then repositoryurl/extrarepositories are not the only information relevant. Its more relevant to know which key artifacts to look for. We added that to our own examples metadata - Fred knows more. >>>>>> >>>>>> Then based on the availability of these artifaacts we either warn or not. If a warning we then suggest to add maven.enterprise.redhat.com/techpreview/all to the ~/.m2/settings.xml. We do *not* add invidivual repositories (like EAP600 and EAP601) to users settings nor pom.xml - that would be bad form IMO. In any case - I don't think repositoryurl and extrarepositories are good on its own - needs more info. >>>>>> >>>>>> My biggest gotcha with upcoming changes is how the tools can/should cope with archetypes not having enterprise flag anymore. That at least from where I'm looking changes the workflow we need to provide to the user since we just starts with user requesting "Create a JavaEE Web app" ...and how do we ensure the archetypes stay consistent (before just a simple flag) now its spread between multiple repositories/archetype versions. >>>>>> >>>>>> >>>>>> /max >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> As part of the "new organization" plan, it's a good time to update stacks format since it will be hosted on the new github organization. >>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 proposal to see if everyone agrees on that or if should we keep using 1.0 format >>>>>>>> >>>>>>>> Changes from 1.0 to 1.1 >>>>>>>> >>>>>>>> - Rename Licenses to Metadata >>>>>>>> >>>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>>> section to avoid repeating metadatas like version, >>>>>>>> repositories, licenses, etc: >>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Workaround: Leave it as it is >>>>>>>> >>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>> >>>>>>>> Justification: I've been using labels to to tag what >>>>>>>> repositories are Required: >>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>> >>>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>>> add every non maven central repository required. >>>>>>>> >>>>>>>> So I'd like to here your thoughts about it and analyze possible impacts on this format change. >>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved to jboss-developer github organization. So it's a good change to update it. The 1.0 and 1.1 should coexist for a while and maybe stacks-client should have a "migration" feature to permit a smooth transition. >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jdf-dev mailing list >>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>> >>>>> >>> >

From the Forge perspective, I don't think it matters much here. What we need is a list of Product stacks and all recommended GAVs for dependencies thereof. This will allow us to resolve against the Stack and pre-populate (or even hide pre-defined values entirely) as users execute commands. I'm interested, how do you plan to use this metadata in JBDS? ~Lincoln ----- Original Message ----- From: "Lincoln Baxter" <lbaxter(a)redhat.com&gt; To: "Pete Muir" <pmuir(a)redhat.com&gt; Cc: "Max Rydahl Andersen" <max.andersen(a)redhat.com&gt;, "jdf-dev" <jdf-dev(a)lists.jboss.org&gt;, "George Gastaldi" <ggastald(a)redhat.com&gt; Sent: Friday, August 16, 2013 2:02:13 PM Subject: Re: [jdf-dev] Stacks 1.1 format proposal Looks like the link to the stacks.yaml file is broken on this guide btw- http://www.jboss.org/jdf/stack/plugin-jdf/ ----- Original Message ----- From: "Pete Muir" <pmuir(a)redhat.com&gt; To: "Max Rydahl Andersen" <manderse(a)redhat.com&gt; Cc: "Rafael Benevides" <benevides(a)redhat.com&gt;, "Fred Bricon" <fbricon(a)redhat.com&gt;, "jdf-dev" <jdf-dev(a)lists.jboss.org&gt;, "Max Rydahl Andersen" <max.andersen(a)redhat.com&gt;, "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "George Gastaldi" <ggastald(a)redhat.com&gt; Sent: Friday, August 16, 2013 1:14:01 PM Subject: Re: [jdf-dev] Stacks 1.1 format proposal Can't we add metadata to stacks for this particular thing: product: eap enterprise: true|false and then you can pick the one you want. On 16 Aug 2013, at 09:17, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >> >> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>> You're right Max. >>>> >>>> That was the proposal. And we should think a little bit more about the workflow since the plan is to change Archetypes GAV to: org.jboss.archetypes.eap: jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>> >>>> I believe that the "product focus" idea is to have this EAP archetypes as the default of "Create a Java EE XXX app..." (without enterprise flag) but my concern is about the setup of EAP repository setup. >>> >>> That part is the smallest problem ;) We already support it. >>> >>> Try create an enterprise archetype in JBDS while running with ~/.m2/settings.xml that does >>> *not* have access to the enterprise artifacts. We'll warn and guide you to add maven.repository url) >>> >>> We do that based on a list of key artifacts we check - this is currently outside stacks.yml, >>> but could probably make sense to add this bit of info so other than jbds can do similar things. >>> >>> My main concern is how to find out which archetypes that matches and how to toggle/manage them. >> >> Shouldn't this new GAV change help you to find out ? > > I would rather not rely on GAV to decide that if can be avoided. > > But your suggestion is that the group "org.jboss.archetypes.eap" decides it - > which would be the "non-product" version ? there is no 1-to-1 mapping. > > Thing is that we loose the ability to toggle when the mvn wizard is running - the decision have to be made upfront. > > But I think we'll just have to drop that "feature" and force users to know more upfront - > possibly in the case no runtime is known give them a choice of possible archetypes for JavaEE ? > > Fred - do you forsee issues/concerns ? > > /max > >>> >>> /max >>> >>> >>>> I could be wrong but that's is how I understand that part of the plan. >>>> >>>> >>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>> I probably missed it but where does it say the enterprise flag goes away for archetypes? >>>>> >>>>> thats in the other thread(s) about changing the way things are released/versioned. >>>>> >>>>> Here it was suggested archetypes would be productized similar to quickstarts, thus >>>>> there would be forks/duplicates instead of one version we could use and then toggle >>>>> between one or the other target..thus no enterprise flag. >>>>> >>>>> At least thats how I understood the proposal and we should work with Rafael on >>>>> that. >>>>> >>>>> >>>>> /max >>>>> >>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>> >>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm resurrecting this subject because Forge Team started to brainstorm about the Stacks Add-on to Forge. >>>>>>>> >>>>>>>> Max, >>>>>>>> >>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>> >>>>>>>> - Change format (getting the opportunity of repo location change) >>>>>>>> vs >>>>>>>> - Still using the same format with workarounds >>>>>>> >>>>>>> I would like that Fred B. takes a look at this and give his feedback since he been doing most of the license/repositoryurl workarounds we need. >>>>>>> >>>>>>> But from top of my head: >>>>>>> >>>>>>> I don't see how stacks 1.0 can change location (i.e. url) since that will break JBDS 7.0/JBT 4.1 users. Are you really talking about a physical move, or simply where you would out the "next" version ? The 1.0 url is stuck and should stay there for years from what I can see. >>>>>>> >>>>>>> About "rename licenses to metdata"...I never realized those names were tied to element defined as licenses. Shouldn't it be licenses AND releaseversions or something ? what other metadata is needed here ? ...and if it is just to avoid repeating it is this just like "entities" like in a DTD ? >>>>>>> About "repositoryUrl and extrarepositories" to bomversion then this seem to be a variation on how we in eclipse decides wether we need to add something to the users settings.xml or not ? In that case then repositoryurl/extrarepositories are not the only information relevant. Its more relevant to know which key artifacts to look for. We added that to our own examples metadata - Fred knows more. >>>>>>> >>>>>>> Then based on the availability of these artifaacts we either warn or not. If a warning we then suggest to add maven.enterprise.redhat.com/techpreview/all to the ~/.m2/settings.xml. We do *not* add invidivual repositories (like EAP600 and EAP601) to users settings nor pom.xml - that would be bad form IMO. In any case - I don't think repositoryurl and extrarepositories are good on its own - needs more info. >>>>>>> >>>>>>> My biggest gotcha with upcoming changes is how the tools can/should cope with archetypes not having enterprise flag anymore. That at least from where I'm looking changes the workflow we need to provide to the user since we just starts with user requesting "Create a JavaEE Web app" ...and how do we ensure the archetypes stay consistent (before just a simple flag) now its spread between multiple repositories/archetype versions. >>>>>>> >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> As part of the "new organization" plan, it's a good time to update stacks format since it will be hosted on the new github organization. >>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 proposal to see if everyone agrees on that or if should we keep using 1.0 format >>>>>>>>> >>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>> >>>>>>>>> - Rename Licenses to Metadata >>>>>>>>> >>>>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>> repositories, licenses, etc: >>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Workaround: Leave it as it is >>>>>>>>> >>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>> >>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>> repositories are Required: >>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>> >>>>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>>>> add every non maven central repository required. >>>>>>>>> >>>>>>>>> So I'd like to here your thoughts about it and analyze possible impacts on this format change. >>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved to jboss-developer github organization. So it's a good change to update it. The 1.0 and 1.1 should coexist for a while and maybe stacks-client should have a "migration" feature to permit a smooth transition. >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: > > Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>> You're right Max. >>> >>> That was the proposal. And we should think a little bit more about >>> the workflow since the plan is to change Archetypes GAV to: >>> org.jboss.archetypes.eap: >>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>> >>> I believe that the "product focus" idea is to have this EAP >>> archetypes as the default of "Create a Java EE XXX app..." (without >>> enterprise flag) but my concern is about the setup of EAP >>> repository setup. >> >> That part is the smallest problem ;) We already support it. >> >> Try create an enterprise archetype in JBDS while running with >> ~/.m2/settings.xml that does >> *not* have access to the enterprise artifacts. We'll warn and guide >> you to add maven.repository url) >> >> We do that based on a list of key artifacts we check - this is >> currently outside stacks.yml, >> but could probably make sense to add this bit of info so other than >> jbds can do similar things. >> >> My main concern is how to find out which archetypes that matches and >> how to toggle/manage them. > > Shouldn't this new GAV change help you to find out ? I would rather not rely on GAV to decide that if can be avoided. But your suggestion is that the group "org.jboss.archetypes.eap" decides it - which would be the "non-product" version ? there is no 1-to-1 mapping. Thing is that we loose the ability to toggle when the mvn wizard is running - the decision have to be made upfront. But I think we'll just have to drop that "feature" and force users to know more upfront - possibly in the case no runtime is known give them a choice of possible archetypes for JavaEE ? Fred - do you forsee issues/concerns ? /max >> >> /max >> >> >>> I could be wrong but that's is how I understand that part of the plan. >>> >>> >>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>> I probably missed it but where does it say the enterprise flag >>>>> goes away for archetypes? >>>> >>>> thats in the other thread(s) about changing the way things are >>>> released/versioned. >>>> >>>> Here it was suggested archetypes would be productized similar to >>>> quickstarts, thus >>>> there would be forks/duplicates instead of one version we could >>>> use and then toggle >>>> between one or the other target..thus no enterprise flag. >>>> >>>> At least thats how I understood the proposal and we should work >>>> with Rafael on >>>> that. >>>> >>>> >>>> /max >>>> >>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>> >>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I'm resurrecting this subject because Forge Team started to >>>>>>> brainstorm about the Stacks Add-on to Forge. >>>>>>> >>>>>>> Max, >>>>>>> >>>>>>> Do you have some thoughts/considerations on this: >>>>>>> >>>>>>> - Change format (getting the opportunity of repo location change) >>>>>>> vs >>>>>>> - Still using the same format with workarounds >>>>>> >>>>>> I would like that Fred B. takes a look at this and give his >>>>>> feedback since he been doing most of the license/repositoryurl >>>>>> workarounds we need. >>>>>> >>>>>> But from top of my head: >>>>>> >>>>>> I don't see how stacks 1.0 can change location (i.e. url) since >>>>>> that will break JBDS 7.0/JBT 4.1 users. Are you really talking >>>>>> about a physical move, or simply where you would out the "next" >>>>>> version ? The 1.0 url is stuck and should stay there for years >>>>>> from what I can see. >>>>>> >>>>>> About "rename licenses to metdata"...I never realized those >>>>>> names were tied to element defined as licenses. Shouldn't it be >>>>>> licenses AND releaseversions or something ? what other metadata >>>>>> is needed here ? ...and if it is just to avoid repeating it is >>>>>> this just like "entities" like in a DTD ? >>>>>> About "repositoryUrl and extrarepositories" to bomversion then >>>>>> this seem to be a variation on how we in eclipse decides wether >>>>>> we need to add something to the users settings.xml or not ? In >>>>>> that case then repositoryurl/extrarepositories are not the only >>>>>> information relevant. Its more relevant to know which key >>>>>> artifacts to look for. We added that to our own examples >>>>>> metadata - Fred knows more. >>>>>> >>>>>> Then based on the availability of these artifaacts we either >>>>>> warn or not. If a warning we then suggest to add >>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - that >>>>>> would be bad form IMO. In any case - I don't think repositoryurl >>>>>> and extrarepositories are good on its own - needs more info. >>>>>> >>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>> can/should cope with archetypes not having enterprise flag >>>>>> anymore. That at least from where I'm looking changes the >>>>>> workflow we need to provide to the user since we just starts >>>>>> with user requesting "Create a JavaEE Web app" ...and how do we >>>>>> ensure the archetypes stay consistent (before just a simple >>>>>> flag) now its spread between multiple repositories/archetype >>>>>> versions. >>>>>> >>>>>> >>>>>> /max >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> As part of the "new organization" plan, it's a good time to >>>>>>>> update stacks format since it will be hosted on the new github >>>>>>>> organization. >>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>> keep using 1.0 format >>>>>>>> >>>>>>>> Changes from 1.0 to 1.1 >>>>>>>> >>>>>>>> - Rename Licenses to Metadata >>>>>>>> >>>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>>> section to avoid repeating metadatas like version, >>>>>>>> repositories, licenses, etc: >>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Workaround: Leave it as it is >>>>>>>> >>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>> >>>>>>>> Justification: I've been using labels to to tag what >>>>>>>> repositories are Required: >>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>> >>>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>>> add every non maven central repository required. >>>>>>>> >>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>> possible impacts on this format change. >>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved to >>>>>>>> jboss-developer github organization. So it's a good change to >>>>>>>> update it. The 1.0 and 1.1 should coexist for a while and >>>>>>>> maybe stacks-client should have a "migration" feature to >>>>>>>> permit a smooth transition. >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jdf-dev mailing list >>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>> >>>>> >>> >

Ha! We just talked about that on today's meeting! One more reason to update stacks format ;)

Em 19/08/13 11:31, Fred Bricon escreveu: >We could treat enterprise versions the same way we currently treat >"blank" versions. >i.e. the default (community) archetype would have an enterprise >attribute pointing at the corresponding archetype. >See https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >for instance. > > >Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>> >>>Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>>>You're right Max. >>>>> >>>>>That was the proposal. And we should think a little bit more >>>>>about the workflow since the plan is to change Archetypes >>>>>GAV to: org.jboss.archetypes.eap: >>>>>jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>> >>>>>I believe that the "product focus" idea is to have this EAP >>>>>archetypes as the default of "Create a Java EE XXX app..." >>>>>(without enterprise flag) but my concern is about the setup >>>>>of EAP repository setup. >>>> >>>>That part is the smallest problem ;) We already support it. >>>> >>>>Try create an enterprise archetype in JBDS while running with >>>>~/.m2/settings.xml that does >>>>*not* have access to the enterprise artifacts. We'll warn and >>>>guide you to add maven.repository url) >>>> >>>>We do that based on a list of key artifacts we check - this is >>>>currently outside stacks.yml, >>>>but could probably make sense to add this bit of info so other >>>>than jbds can do similar things. >>>> >>>>My main concern is how to find out which archetypes that >>>>matches and how to toggle/manage them. >>> >>>Shouldn't this new GAV change help you to find out ? >> >>I would rather not rely on GAV to decide that if can be avoided. >> >>But your suggestion is that the group "org.jboss.archetypes.eap" >>decides it - >>which would be the "non-product" version ? there is no 1-to-1 mapping. >> >>Thing is that we loose the ability to toggle when the mvn wizard >>is running - the decision have to be made upfront. >> >>But I think we'll just have to drop that "feature" and force users >>to know more upfront - >>possibly in the case no runtime is known give them a choice of >>possible archetypes for JavaEE ? >> >>Fred - do you forsee issues/concerns ? >> >>/max >> >>>> >>>>/max >>>> >>>> >>>>>I could be wrong but that's is how I understand that part of >>>>>the plan. >>>>> >>>>> >>>>>Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>I probably missed it but where does it say the >>>>>>>enterprise flag goes away for archetypes? >>>>>> >>>>>>thats in the other thread(s) about changing the way things >>>>>>are released/versioned. >>>>>> >>>>>>Here it was suggested archetypes would be productized >>>>>>similar to quickstarts, thus >>>>>>there would be forks/duplicates instead of one version we >>>>>>could use and then toggle >>>>>>between one or the other target..thus no enterprise flag. >>>>>> >>>>>>At least thats how I understood the proposal and we should >>>>>>work with Rafael on >>>>>>that. >>>>>> >>>>>> >>>>>>/max >>>>>> >>>>>>>Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>> >>>>>>>>On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>>>>Hi all, >>>>>>>>> >>>>>>>>>I'm resurrecting this subject because Forge Team >>>>>>>>>started to brainstorm about the Stacks Add-on to >>>>>>>>>Forge. >>>>>>>>> >>>>>>>>>Max, >>>>>>>>> >>>>>>>>>Do you have some thoughts/considerations on this: >>>>>>>>> >>>>>>>>>- Change format (getting the opportunity of repo location change) >>>>>>>>>vs >>>>>>>>>- Still using the same format with workarounds >>>>>>>> >>>>>>>>I would like that Fred B. takes a look at this and >>>>>>>>give his feedback since he been doing most of the >>>>>>>>license/repositoryurl workarounds we need. >>>>>>>> >>>>>>>>But from top of my head: >>>>>>>> >>>>>>>>I don't see how stacks 1.0 can change location (i.e. >>>>>>>>url) since that will break JBDS 7.0/JBT 4.1 users. Are >>>>>>>>you really talking about a physical move, or simply >>>>>>>>where you would out the "next" version ? The 1.0 url >>>>>>>>is stuck and should stay there for years from what I >>>>>>>>can see. >>>>>>>> >>>>>>>>About "rename licenses to metdata"...I never realized >>>>>>>>those names were tied to element defined as licenses. >>>>>>>>Shouldn't it be licenses AND releaseversions or >>>>>>>>something ? what other metadata is needed here ? >>>>>>>>...and if it is just to avoid repeating it is this >>>>>>>>just like "entities" like in a DTD ? >>>>>>>>About "repositoryUrl and extrarepositories" to >>>>>>>>bomversion then this seem to be a variation on how we >>>>>>>>in eclipse decides wether we need to add something to >>>>>>>>the users settings.xml or not ? In that case then >>>>>>>>repositoryurl/extrarepositories are not the only >>>>>>>>information relevant. Its more relevant to know which >>>>>>>>key artifacts to look for. We added that to our own >>>>>>>>examples metadata - Fred knows more. >>>>>>>> >>>>>>>>Then based on the availability of these artifaacts we >>>>>>>>either warn or not. If a warning we then suggest to >>>>>>>>add maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>~/.m2/settings.xml. We do *not* add invidivual >>>>>>>>repositories (like EAP600 and EAP601) to users >>>>>>>>settings nor pom.xml - that would be bad form IMO. In >>>>>>>>any case - I don't think repositoryurl and >>>>>>>>extrarepositories are good on its own - needs more >>>>>>>>info. >>>>>>>> >>>>>>>>My biggest gotcha with upcoming changes is how the >>>>>>>>tools can/should cope with archetypes not having >>>>>>>>enterprise flag anymore. That at least from where I'm >>>>>>>>looking changes the workflow we need to provide to the >>>>>>>>user since we just starts with user requesting "Create >>>>>>>>a JavaEE Web app" ...and how do we ensure the >>>>>>>>archetypes stay consistent (before just a simple flag) >>>>>>>>now its spread between multiple repositories/archetype >>>>>>>>versions. >>>>>>>> >>>>>>>> >>>>>>>>/max >>>>>>>> >>>>>>>>> >>>>>>>>>Thanks >>>>>>>>> >>>>>>>>>Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>Hi all, >>>>>>>>>> >>>>>>>>>>As part of the "new organization" plan, it's a >>>>>>>>>>good time to update stacks format since it will be >>>>>>>>>>hosted on the new github organization. >>>>>>>>>>I've analyzed the changes need and attached a >>>>>>>>>>Stacks 1.1 proposal to see if everyone agrees on >>>>>>>>>>that or if should we keep using 1.0 format >>>>>>>>>> >>>>>>>>>>Changes from 1.0 to 1.1 >>>>>>>>>> >>>>>>>>>>- Rename Licenses to Metadata >>>>>>>>>> >>>>>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>> >>>>>>>>>>- add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>> >>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>> repositories are Required: >>>>>>>>>>https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Some BOMs needs more than one repo as JPP ( >>>>>>>>>>JPP is built on >>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>> >>>>>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>>>>> add every non maven central repository required. >>>>>>>>>> >>>>>>>>>>So I'd like to here your thoughts about it and >>>>>>>>>>analyze possible impacts on this format change. >>>>>>>>>>OBS.: Remember that stacks 1.0 repo is planned to >>>>>>>>>>be moved to jboss-developer github organization. >>>>>>>>>>So it's a good change to update it. The 1.0 and >>>>>>>>>>1.1 should coexist for a while and maybe >>>>>>>>>>stacks-client should have a "migration" feature to >>>>>>>>>>permit a smooth transition. >>>>>>>>>> >>>>>>>>>>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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>jdf-dev mailing list &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;jdf-dev(a)lists.jboss.org >>>>>>>>>>https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>>>> >>>>>>> >>>>> >>> >

From the Forge standpoint this feature request from pete, a long time ago, is what we have assumed the stacks project is designed to address: https://issues.jboss.org/browse/FORGE-378 - Is this language still correct, or has the intention of this JIRA issue changed? Basically what I understand this to mean is:

On Mon, Aug 19, 2013 at 11:55:17AM -0300, Rafael Benevides wrote: > Ha! > > We just talked about that on today's meeting! One more reason to > update stacks format ;) yes, I think this has merrit but if I grok the updated version model won't there be a 1-N mapping here ?

i.e. JavaEE project archetype will exist in multiple versions, community version for wildfly 7, then EAP 6 version, soon wildfly 8 ?

Also JavaEE project will need to target different runtimes x different specs (for now JavaEE 6 but JavaEE 7 will be there soon). > Em 19/08/13 11:31, Fred Bricon escreveu: >> We could treat enterprise versions the same way we currently treat >> "blank" versions. >> i.e. the default (community) archetype would have an enterprise >> attribute pointing at the corresponding archetype. >> See >> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >> for instance. >> >> >> Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>> On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>>> >>>> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>>>> You're right Max. >>>>>> >>>>>> That was the proposal. And we should think a little bit more >>>>>> about the workflow since the plan is to change Archetypes GAV >>>>>> to: org.jboss.archetypes.eap: >>>>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>>> >>>>>> I believe that the "product focus" idea is to have this EAP >>>>>> archetypes as the default of "Create a Java EE XXX app..." >>>>>> (without enterprise flag) but my concern is about the setup of >>>>>> EAP repository setup. >>>>> >>>>> That part is the smallest problem ;) We already support it. >>>>> >>>>> Try create an enterprise archetype in JBDS while running with >>>>> ~/.m2/settings.xml that does >>>>> *not* have access to the enterprise artifacts. We'll warn and >>>>> guide you to add maven.repository url) >>>>> >>>>> We do that based on a list of key artifacts we check - this is >>>>> currently outside stacks.yml, >>>>> but could probably make sense to add this bit of info so other >>>>> than jbds can do similar things. >>>>> >>>>> My main concern is how to find out which archetypes that matches >>>>> and how to toggle/manage them. >>>> >>>> Shouldn't this new GAV change help you to find out ? >>> >>> I would rather not rely on GAV to decide that if can be avoided. >>> >>> But your suggestion is that the group "org.jboss.archetypes.eap" >>> decides it - >>> which would be the "non-product" version ? there is no 1-to-1 mapping. >>> >>> Thing is that we loose the ability to toggle when the mvn wizard is >>> running - the decision have to be made upfront. >>> >>> But I think we'll just have to drop that "feature" and force users >>> to know more upfront - >>> possibly in the case no runtime is known give them a choice of >>> possible archetypes for JavaEE ? >>> >>> Fred - do you forsee issues/concerns ? >>> >>> /max >>> >>>>> >>>>> /max >>>>> >>>>> >>>>>> I could be wrong but that's is how I understand that part of the >>>>>> plan. >>>>>> >>>>>> >>>>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>> I probably missed it but where does it say the enterprise flag >>>>>>>> goes away for archetypes? >>>>>>> >>>>>>> thats in the other thread(s) about changing the way things are >>>>>>> released/versioned. >>>>>>> >>>>>>> Here it was suggested archetypes would be productized similar >>>>>>> to quickstarts, thus >>>>>>> there would be forks/duplicates instead of one version we could >>>>>>> use and then toggle >>>>>>> between one or the other target..thus no enterprise flag. >>>>>>> >>>>>>> At least thats how I understood the proposal and we should work >>>>>>> with Rafael on >>>>>>> that. >>>>>>> >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>>> >>>>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides >>>>>>>>> wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I'm resurrecting this subject because Forge Team started to >>>>>>>>>> brainstorm about the Stacks Add-on to Forge. >>>>>>>>>> >>>>>>>>>> Max, >>>>>>>>>> >>>>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>>>> >>>>>>>>>> - Change format (getting the opportunity of repo location >>>>>>>>>> change) >>>>>>>>>> vs >>>>>>>>>> - Still using the same format with workarounds >>>>>>>>> >>>>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>>>> feedback since he been doing most of the >>>>>>>>> license/repositoryurl workarounds we need. >>>>>>>>> >>>>>>>>> But from top of my head: >>>>>>>>> >>>>>>>>> I don't see how stacks 1.0 can change location (i.e. url) >>>>>>>>> since that will break JBDS 7.0/JBT 4.1 users. Are you really >>>>>>>>> talking about a physical move, or simply where you would out >>>>>>>>> the "next" version ? The 1.0 url is stuck and should stay >>>>>>>>> there for years from what I can see. >>>>>>>>> >>>>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>>>> names were tied to element defined as licenses. Shouldn't it >>>>>>>>> be licenses AND releaseversions or something ? what other >>>>>>>>> metadata is needed here ? ...and if it is just to avoid >>>>>>>>> repeating it is this just like "entities" like in a DTD ? >>>>>>>>> About "repositoryUrl and extrarepositories" to bomversion >>>>>>>>> then this seem to be a variation on how we in eclipse decides >>>>>>>>> wether we need to add something to the users settings.xml or >>>>>>>>> not ? In that case then repositoryurl/extrarepositories are >>>>>>>>> not the only information relevant. Its more relevant to know >>>>>>>>> which key artifacts to look for. We added that to our own >>>>>>>>> examples metadata - Fred knows more. >>>>>>>>> >>>>>>>>> Then based on the availability of these artifaacts we either >>>>>>>>> warn or not. If a warning we then suggest to add >>>>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - that >>>>>>>>> would be bad form IMO. In any case - I don't think >>>>>>>>> repositoryurl and extrarepositories are good on its own - >>>>>>>>> needs more info. >>>>>>>>> >>>>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>>>> anymore. That at least from where I'm looking changes the >>>>>>>>> workflow we need to provide to the user since we just starts >>>>>>>>> with user requesting "Create a JavaEE Web app" ...and how do >>>>>>>>> we ensure the archetypes stay consistent (before just a >>>>>>>>> simple flag) now its spread between multiple >>>>>>>>> repositories/archetype versions. >>>>>>>>> >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> As part of the "new organization" plan, it's a good time to >>>>>>>>>>> update stacks format since it will be hosted on the new >>>>>>>>>>> github organization. >>>>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>>>>> keep using 1.0 format >>>>>>>>>>> >>>>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>>>> >>>>>>>>>>> - Rename Licenses to Metadata >>>>>>>>>>> >>>>>>>>>>> Justification: I've been using Licenses today as an >>>>>>>>>>> metadata >>>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>>> >>>>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>>> >>>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>>> repositories are Required: >>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>>>> built on >>>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>>> >>>>>>>>>>> Workaround: Create an standard tag called *repositories* >>>>>>>>>>> and >>>>>>>>>>> add every non maven central repository required. >>>>>>>>>>> >>>>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>>>> possible impacts on this format change. >>>>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved >>>>>>>>>>> to jboss-developer github organization. So it's a good >>>>>>>>>>> change to update it. The 1.0 and 1.1 should coexist for a >>>>>>>>>>> while and maybe stacks-client should have a "migration" >>>>>>>>>>> feature to permit a smooth transition. >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jdf-dev mailing list >>>>>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >

Perhaps we should highlight or re-iterate the goals we want to achieve with the JDF Stacks? It sounds to me like we are talking about several different use-cases that are similar but not exactly the same. I will explain the Forge viewpoint / what I understand the requirements to be and hopefully we can clear things up a bit. From the Forge standpoint this feature request from pete, a long time ago, is what we have assumed the stacks project is designed to address: https://issues.jboss.org/browse/FORGE-378 - Is this language still correct, or has the intention of this JIRA issue changed? Basically what I understand this to mean is:

1. User selects runtime in Forge (EAP6) - What does this mean exactly? Does this require using a BOM in the project, or does it mean simply resolving the BOM dependencies and using that information to choose version information?

2. User is no longer prompted for Versions for supported Product/Technology stacks. If all we are doing is selecting a BOM to add to the project, then this is easy, but I was under the impression that there was something more to this, e.g: Archetype selection, Project BOM selection, Project Dependency Selection.. etc.. . If that is the case, what am I missing? What exactly do you want Forge (and JBDS) to do?

Thanks, Lincoln ----- Original Message ----- From: "Rafael Benevides" <benevides(a)redhat.com&gt; To: "Max Rydahl Andersen" <manderse(a)redhat.com&gt; Cc: "Fred Bricon" <fbricon(a)redhat.com&gt;, "jdf-dev" <jdf-dev(a)lists.jboss.org&gt;, "Max Rydahl Andersen" <max.andersen(a)redhat.com&gt;, "Peter Muir" <pmuir(a)redhat.com&gt;, "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "George Gastaldi" <ggastald(a)redhat.com&gt; Sent: Tuesday, August 20, 2013 9:31:32 AM Subject: Re: [jdf-dev] Stacks 1.1 format proposal Em 20/08/13 07:46, Max Rydahl Andersen escreveu: > On Mon, Aug 19, 2013 at 11:55:17AM -0300, Rafael Benevides wrote: >> Ha! >> >> We just talked about that on today's meeting! One more reason to >> update stacks format ;) > yes, I think this has merrit but if I grok the updated version model > won't there > be a 1-N mapping here ? Yes. There'll be 1 runtime to N archetypes as it is today: https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1547... and https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1448... > i.e. JavaEE project archetype will exist in multiple versions, > community version for wildfly 7, then EAP 6 version, soon wildfly 8 ? Yes. > Also JavaEE project will need to target different runtimes x different > specs (for now JavaEE 6 but JavaEE 7 will be there soon). > > >> Em 19/08/13 11:31, Fred Bricon escreveu: >>> We could treat enterprise versions the same way we currently treat >>> "blank" versions. >>> i.e. the default (community) archetype would have an enterprise >>> attribute pointing at the corresponding archetype. >>> See >>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >>> for instance. >>> >>> >>> Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>>> On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>>>> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>>>>> You're right Max. >>>>>>> >>>>>>> That was the proposal. And we should think a little bit more >>>>>>> about the workflow since the plan is to change Archetypes GAV >>>>>>> to: org.jboss.archetypes.eap: >>>>>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>>>> >>>>>>> I believe that the "product focus" idea is to have this EAP >>>>>>> archetypes as the default of "Create a Java EE XXX app..." >>>>>>> (without enterprise flag) but my concern is about the setup of >>>>>>> EAP repository setup. >>>>>> That part is the smallest problem ;) We already support it. >>>>>> >>>>>> Try create an enterprise archetype in JBDS while running with >>>>>> ~/.m2/settings.xml that does >>>>>> *not* have access to the enterprise artifacts. We'll warn and >>>>>> guide you to add maven.repository url) >>>>>> >>>>>> We do that based on a list of key artifacts we check - this is >>>>>> currently outside stacks.yml, >>>>>> but could probably make sense to add this bit of info so other >>>>>> than jbds can do similar things. >>>>>> >>>>>> My main concern is how to find out which archetypes that matches >>>>>> and how to toggle/manage them. >>>>> Shouldn't this new GAV change help you to find out ? >>>> I would rather not rely on GAV to decide that if can be avoided. >>>> >>>> But your suggestion is that the group "org.jboss.archetypes.eap" >>>> decides it - >>>> which would be the "non-product" version ? there is no 1-to-1 mapping. >>>> >>>> Thing is that we loose the ability to toggle when the mvn wizard is >>>> running - the decision have to be made upfront. >>>> >>>> But I think we'll just have to drop that "feature" and force users >>>> to know more upfront - >>>> possibly in the case no runtime is known give them a choice of >>>> possible archetypes for JavaEE ? >>>> >>>> Fred - do you forsee issues/concerns ? >>>> >>>> /max >>>> >>>>>> /max >>>>>> >>>>>> >>>>>>> I could be wrong but that's is how I understand that part of the >>>>>>> plan. >>>>>>> >>>>>>> >>>>>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>>> I probably missed it but where does it say the enterprise flag >>>>>>>>> goes away for archetypes? >>>>>>>> thats in the other thread(s) about changing the way things are >>>>>>>> released/versioned. >>>>>>>> >>>>>>>> Here it was suggested archetypes would be productized similar >>>>>>>> to quickstarts, thus >>>>>>>> there would be forks/duplicates instead of one version we could >>>>>>>> use and then toggle >>>>>>>> between one or the other target..thus no enterprise flag. >>>>>>>> >>>>>>>> At least thats how I understood the proposal and we should work >>>>>>>> with Rafael on >>>>>>>> that. >>>>>>>> >>>>>>>> >>>>>>>> /max >>>>>>>> >>>>>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides >>>>>>>>>> wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I'm resurrecting this subject because Forge Team started to >>>>>>>>>>> brainstorm about the Stacks Add-on to Forge. >>>>>>>>>>> >>>>>>>>>>> Max, >>>>>>>>>>> >>>>>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>>>>> >>>>>>>>>>> - Change format (getting the opportunity of repo location >>>>>>>>>>> change) >>>>>>>>>>> vs >>>>>>>>>>> - Still using the same format with workarounds >>>>>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>>>>> feedback since he been doing most of the >>>>>>>>>> license/repositoryurl workarounds we need. >>>>>>>>>> >>>>>>>>>> But from top of my head: >>>>>>>>>> >>>>>>>>>> I don't see how stacks 1.0 can change location (i.e. url) >>>>>>>>>> since that will break JBDS 7.0/JBT 4.1 users. Are you really >>>>>>>>>> talking about a physical move, or simply where you would out >>>>>>>>>> the "next" version ? The 1.0 url is stuck and should stay >>>>>>>>>> there for years from what I can see. >>>>>>>>>> >>>>>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>>>>> names were tied to element defined as licenses. Shouldn't it >>>>>>>>>> be licenses AND releaseversions or something ? what other >>>>>>>>>> metadata is needed here ? ...and if it is just to avoid >>>>>>>>>> repeating it is this just like "entities" like in a DTD ? >>>>>>>>>> About "repositoryUrl and extrarepositories" to bomversion >>>>>>>>>> then this seem to be a variation on how we in eclipse decides >>>>>>>>>> wether we need to add something to the users settings.xml or >>>>>>>>>> not ? In that case then repositoryurl/extrarepositories are >>>>>>>>>> not the only information relevant. Its more relevant to know >>>>>>>>>> which key artifacts to look for. We added that to our own >>>>>>>>>> examples metadata - Fred knows more. >>>>>>>>>> >>>>>>>>>> Then based on the availability of these artifaacts we either >>>>>>>>>> warn or not. If a warning we then suggest to add >>>>>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - that >>>>>>>>>> would be bad form IMO. In any case - I don't think >>>>>>>>>> repositoryurl and extrarepositories are good on its own - >>>>>>>>>> needs more info. >>>>>>>>>> >>>>>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>>>>> anymore. That at least from where I'm looking changes the >>>>>>>>>> workflow we need to provide to the user since we just starts >>>>>>>>>> with user requesting "Create a JavaEE Web app" ...and how do >>>>>>>>>> we ensure the archetypes stay consistent (before just a >>>>>>>>>> simple flag) now its spread between multiple >>>>>>>>>> repositories/archetype versions. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /max >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> As part of the "new organization" plan, it's a good time to >>>>>>>>>>>> update stacks format since it will be hosted on the new >>>>>>>>>>>> github organization. >>>>>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>>>>>> keep using 1.0 format >>>>>>>>>>>> >>>>>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>>>>> >>>>>>>>>>>> - Rename Licenses to Metadata >>>>>>>>>>>> >>>>>>>>>>>> Justification: I've been using Licenses today as an >>>>>>>>>>>> metadata >>>>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>>>> >>>>>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>>>> >>>>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>>>> repositories are Required: >>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>>>>> built on >>>>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>>>> >>>>>>>>>>>> Workaround: Create an standard tag called *repositories* >>>>>>>>>>>> and >>>>>>>>>>>> add every non maven central repository required. >>>>>>>>>>>> >>>>>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>>>>> possible impacts on this format change. >>>>>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved >>>>>>>>>>>> to jboss-developer github organization. So it's a good >>>>>>>>>>>> change to update it. The 1.0 and 1.1 should coexist for a >>>>>>>>>>>> while and maybe stacks-client should have a "migration" >>>>>>>>>>>> feature to permit a smooth transition. >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jdf-dev mailing list >>>>>>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev

We could treat enterprise versions the same way we currently treat "blank" versions. i.e. the default (community) archetype would have an enterprise attribute pointing at the corresponding archetype. See https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 for instance. Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : > On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >> >> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>> You're right Max. >>>> >>>> That was the proposal. And we should think a little bit more about >>>> the workflow since the plan is to change Archetypes GAV to: >>>> org.jboss.archetypes.eap: >>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>> >>>> I believe that the "product focus" idea is to have this EAP >>>> archetypes as the default of "Create a Java EE XXX app..." >>>> (without enterprise flag) but my concern is about the setup of EAP >>>> repository setup. >>> >>> That part is the smallest problem ;) We already support it. >>> >>> Try create an enterprise archetype in JBDS while running with >>> ~/.m2/settings.xml that does >>> *not* have access to the enterprise artifacts. We'll warn and guide >>> you to add maven.repository url) >>> >>> We do that based on a list of key artifacts we check - this is >>> currently outside stacks.yml, >>> but could probably make sense to add this bit of info so other than >>> jbds can do similar things. >>> >>> My main concern is how to find out which archetypes that matches >>> and how to toggle/manage them. >> >> Shouldn't this new GAV change help you to find out ? > > I would rather not rely on GAV to decide that if can be avoided. > > But your suggestion is that the group "org.jboss.archetypes.eap" > decides it - > which would be the "non-product" version ? there is no 1-to-1 mapping. > > Thing is that we loose the ability to toggle when the mvn wizard is > running - the decision have to be made upfront. > > But I think we'll just have to drop that "feature" and force users to > know more upfront - > possibly in the case no runtime is known give them a choice of > possible archetypes for JavaEE ? > > Fred - do you forsee issues/concerns ? > > /max > >>> >>> /max >>> >>> >>>> I could be wrong but that's is how I understand that part of the >>>> plan. >>>> >>>> >>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>> I probably missed it but where does it say the enterprise flag >>>>>> goes away for archetypes? >>>>> >>>>> thats in the other thread(s) about changing the way things are >>>>> released/versioned. >>>>> >>>>> Here it was suggested archetypes would be productized similar to >>>>> quickstarts, thus >>>>> there would be forks/duplicates instead of one version we could >>>>> use and then toggle >>>>> between one or the other target..thus no enterprise flag. >>>>> >>>>> At least thats how I understood the proposal and we should work >>>>> with Rafael on >>>>> that. >>>>> >>>>> >>>>> /max >>>>> >>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>> >>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm resurrecting this subject because Forge Team started to >>>>>>>> brainstorm about the Stacks Add-on to Forge. >>>>>>>> >>>>>>>> Max, >>>>>>>> >>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>> >>>>>>>> - Change format (getting the opportunity of repo location change) >>>>>>>> vs >>>>>>>> - Still using the same format with workarounds >>>>>>> >>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>> feedback since he been doing most of the license/repositoryurl >>>>>>> workarounds we need. >>>>>>> >>>>>>> But from top of my head: >>>>>>> >>>>>>> I don't see how stacks 1.0 can change location (i.e. url) since >>>>>>> that will break JBDS 7.0/JBT 4.1 users. Are you really talking >>>>>>> about a physical move, or simply where you would out the "next" >>>>>>> version ? The 1.0 url is stuck and should stay there for years >>>>>>> from what I can see. >>>>>>> >>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>> names were tied to element defined as licenses. Shouldn't it be >>>>>>> licenses AND releaseversions or something ? what other metadata >>>>>>> is needed here ? ...and if it is just to avoid repeating it is >>>>>>> this just like "entities" like in a DTD ? >>>>>>> About "repositoryUrl and extrarepositories" to bomversion then >>>>>>> this seem to be a variation on how we in eclipse decides wether >>>>>>> we need to add something to the users settings.xml or not ? In >>>>>>> that case then repositoryurl/extrarepositories are not the only >>>>>>> information relevant. Its more relevant to know which key >>>>>>> artifacts to look for. We added that to our own examples >>>>>>> metadata - Fred knows more. >>>>>>> >>>>>>> Then based on the availability of these artifaacts we either >>>>>>> warn or not. If a warning we then suggest to add >>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - that >>>>>>> would be bad form IMO. In any case - I don't think >>>>>>> repositoryurl and extrarepositories are good on its own - needs >>>>>>> more info. >>>>>>> >>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>> anymore. That at least from where I'm looking changes the >>>>>>> workflow we need to provide to the user since we just starts >>>>>>> with user requesting "Create a JavaEE Web app" ...and how do we >>>>>>> ensure the archetypes stay consistent (before just a simple >>>>>>> flag) now its spread between multiple repositories/archetype >>>>>>> versions. >>>>>>> >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> As part of the "new organization" plan, it's a good time to >>>>>>>>> update stacks format since it will be hosted on the new >>>>>>>>> github organization. >>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>>> keep using 1.0 format >>>>>>>>> >>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>> >>>>>>>>> - Rename Licenses to Metadata >>>>>>>>> >>>>>>>>> Justification: I've been using Licenses today as an metadata >>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>> repositories, licenses, etc: >>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Workaround: Leave it as it is >>>>>>>>> >>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>> >>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>> repositories are Required: >>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>> built on >>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>> >>>>>>>>> Workaround: Create an standard tag called *repositories* and >>>>>>>>> add every non maven central repository required. >>>>>>>>> >>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>> possible impacts on this format change. >>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved to >>>>>>>>> jboss-developer github organization. So it's a good change to >>>>>>>>> update it. The 1.0 and 1.1 should coexist for a while and >>>>>>>>> maybe stacks-client should have a "migration" feature to >>>>>>>>> permit a smooth transition. >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jdf-dev mailing list >>>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>>> >>>>>> >>>> >>

On Thu, Aug 22, 2013 at 11:50:46AM -0300, Rafael Benevides wrote: > Fred/Max > > I was thinking about this, and I have the following proposal. Please > feel free to comment: > > Today on 1.0 stacks there's the repositoryURL attribute on both > Archetype and ArchetypeVersion. Shouldn't we say that a non-empty > repositoryURL means that it needs to add that URL to the > ~/.m2/settings.xml ? It is not that simple. You need list of key artifacts to check for - if the user already have that available in their company repository then it is noise to add this url. That is why we check if we can resolve the key artifacts, and if they can't *then* we suggest adding that repository. /max > > Em 19/08/13 11:31, Fred Bricon escreveu: >> We could treat enterprise versions the same way we currently treat >> "blank" versions. >> i.e. the default (community) archetype would have an enterprise >> attribute pointing at the corresponding archetype. >> See >> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >> for instance. >> >> >> Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>> On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>>> >>>> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>>>> You're right Max. >>>>>> >>>>>> That was the proposal. And we should think a little bit more >>>>>> about the workflow since the plan is to change Archetypes GAV >>>>>> to: org.jboss.archetypes.eap: >>>>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>>> >>>>>> I believe that the "product focus" idea is to have this EAP >>>>>> archetypes as the default of "Create a Java EE XXX app..." >>>>>> (without enterprise flag) but my concern is about the setup of >>>>>> EAP repository setup. >>>>> >>>>> That part is the smallest problem ;) We already support it. >>>>> >>>>> Try create an enterprise archetype in JBDS while running with >>>>> ~/.m2/settings.xml that does >>>>> *not* have access to the enterprise artifacts. We'll warn and >>>>> guide you to add maven.repository url) >>>>> >>>>> We do that based on a list of key artifacts we check - this is >>>>> currently outside stacks.yml, >>>>> but could probably make sense to add this bit of info so other >>>>> than jbds can do similar things. >>>>> >>>>> My main concern is how to find out which archetypes that matches >>>>> and how to toggle/manage them. >>>> >>>> Shouldn't this new GAV change help you to find out ? >>> >>> I would rather not rely on GAV to decide that if can be avoided. >>> >>> But your suggestion is that the group "org.jboss.archetypes.eap" >>> decides it - >>> which would be the "non-product" version ? there is no 1-to-1 mapping. >>> >>> Thing is that we loose the ability to toggle when the mvn wizard is >>> running - the decision have to be made upfront. >>> >>> But I think we'll just have to drop that "feature" and force users >>> to know more upfront - >>> possibly in the case no runtime is known give them a choice of >>> possible archetypes for JavaEE ? >>> >>> Fred - do you forsee issues/concerns ? >>> >>> /max >>> >>>>> >>>>> /max >>>>> >>>>> >>>>>> I could be wrong but that's is how I understand that part of the >>>>>> plan. >>>>>> >>>>>> >>>>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>> I probably missed it but where does it say the enterprise flag >>>>>>>> goes away for archetypes? >>>>>>> >>>>>>> thats in the other thread(s) about changing the way things are >>>>>>> released/versioned. >>>>>>> >>>>>>> Here it was suggested archetypes would be productized similar >>>>>>> to quickstarts, thus >>>>>>> there would be forks/duplicates instead of one version we could >>>>>>> use and then toggle >>>>>>> between one or the other target..thus no enterprise flag. >>>>>>> >>>>>>> At least thats how I understood the proposal and we should work >>>>>>> with Rafael on >>>>>>> that. >>>>>>> >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>>> >>>>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides >>>>>>>>> wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I'm resurrecting this subject because Forge Team started to >>>>>>>>>> brainstorm about the Stacks Add-on to Forge. >>>>>>>>>> >>>>>>>>>> Max, >>>>>>>>>> >>>>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>>>> >>>>>>>>>> - Change format (getting the opportunity of repo location >>>>>>>>>> change) >>>>>>>>>> vs >>>>>>>>>> - Still using the same format with workarounds >>>>>>>>> >>>>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>>>> feedback since he been doing most of the >>>>>>>>> license/repositoryurl workarounds we need. >>>>>>>>> >>>>>>>>> But from top of my head: >>>>>>>>> >>>>>>>>> I don't see how stacks 1.0 can change location (i.e. url) >>>>>>>>> since that will break JBDS 7.0/JBT 4.1 users. Are you really >>>>>>>>> talking about a physical move, or simply where you would out >>>>>>>>> the "next" version ? The 1.0 url is stuck and should stay >>>>>>>>> there for years from what I can see. >>>>>>>>> >>>>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>>>> names were tied to element defined as licenses. Shouldn't it >>>>>>>>> be licenses AND releaseversions or something ? what other >>>>>>>>> metadata is needed here ? ...and if it is just to avoid >>>>>>>>> repeating it is this just like "entities" like in a DTD ? >>>>>>>>> About "repositoryUrl and extrarepositories" to bomversion >>>>>>>>> then this seem to be a variation on how we in eclipse decides >>>>>>>>> wether we need to add something to the users settings.xml or >>>>>>>>> not ? In that case then repositoryurl/extrarepositories are >>>>>>>>> not the only information relevant. Its more relevant to know >>>>>>>>> which key artifacts to look for. We added that to our own >>>>>>>>> examples metadata - Fred knows more. >>>>>>>>> >>>>>>>>> Then based on the availability of these artifaacts we either >>>>>>>>> warn or not. If a warning we then suggest to add >>>>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - that >>>>>>>>> would be bad form IMO. In any case - I don't think >>>>>>>>> repositoryurl and extrarepositories are good on its own - >>>>>>>>> needs more info. >>>>>>>>> >>>>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>>>> anymore. That at least from where I'm looking changes the >>>>>>>>> workflow we need to provide to the user since we just starts >>>>>>>>> with user requesting "Create a JavaEE Web app" ...and how do >>>>>>>>> we ensure the archetypes stay consistent (before just a >>>>>>>>> simple flag) now its spread between multiple >>>>>>>>> repositories/archetype versions. >>>>>>>>> >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> As part of the "new organization" plan, it's a good time to >>>>>>>>>>> update stacks format since it will be hosted on the new >>>>>>>>>>> github organization. >>>>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>>>>> keep using 1.0 format >>>>>>>>>>> >>>>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>>>> >>>>>>>>>>> - Rename Licenses to Metadata >>>>>>>>>>> >>>>>>>>>>> Justification: I've been using Licenses today as an >>>>>>>>>>> metadata >>>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>>> >>>>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>>> >>>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>>> repositories are Required: >>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>>>> built on >>>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>>> >>>>>>>>>>> Workaround: Create an standard tag called *repositories* >>>>>>>>>>> and >>>>>>>>>>> add every non maven central repository required. >>>>>>>>>>> >>>>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>>>> possible impacts on this format change. >>>>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved >>>>>>>>>>> to jboss-developer github organization. So it's a good >>>>>>>>>>> change to update it. The 1.0 and 1.1 should coexist for a >>>>>>>>>>> while and maybe stacks-client should have a "migration" >>>>>>>>>>> feature to permit a smooth transition. >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jdf-dev mailing list >>>>>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> >

Le mardi 27 août 2013 16:11:22, Rafael Benevides a écrit : > Hi everybody. > > After thinking about the effort, management cost, the pro and cons and > the benefits that we could get by updating the format I got the > following conclusion: > > IT DOESN'T WORTH TO UPDATE THE FORMAT NOW. > > We can survive with the workarounds proposed on the first email with > the justification of the changes. I'll update the new organization > plan to keep the 1.0 format but I'd like to check about moving stacks > repo from jdf repository to the new one. > > As on previous e-mail I saw that github redirects works pretty well > with http 301 - moved permanently. > > I want to get sure that JBDS/JBT can work with this redirection. I'll perform some tests tomorrow to check if it works

> > Em 26/08/13 06:14, Max Rydahl Andersen escreveu: >> On Thu, Aug 22, 2013 at 11:50:46AM -0300, Rafael Benevides wrote: >>> Fred/Max >>> >>> I was thinking about this, and I have the following proposal. Please >>> feel free to comment: >>> >>> Today on 1.0 stacks there's the repositoryURL attribute on both >>> Archetype and ArchetypeVersion. Shouldn't we say that a non-empty >>> repositoryURL means that it needs to add that URL to the >>> ~/.m2/settings.xml ? >> >> It is not that simple. >> >> You need list of key artifacts to check for - if the user already >> have that available in >> their company repository then it is noise to add this url. >> >> That is why we check if we can resolve the key artifacts, and if they >> can't *then* we >> suggest adding that repository. >> >> /max >> >>> >>> Em 19/08/13 11:31, Fred Bricon escreveu: >>>> We could treat enterprise versions the same way we currently treat >>>> "blank" versions. >>>> i.e. the default (community) archetype would have an enterprise >>>> attribute pointing at the corresponding archetype. >>>> See >>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >>>> for instance. >>>> >>>> >>>> Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>>>> On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>>>>> >>>>>> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>>>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides wrote: >>>>>>>> You're right Max. >>>>>>>> >>>>>>>> That was the proposal. And we should think a little bit more >>>>>>>> about the workflow since the plan is to change Archetypes GAV >>>>>>>> to: org.jboss.archetypes.eap: >>>>>>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>>>>> >>>>>>>> I believe that the "product focus" idea is to have this EAP >>>>>>>> archetypes as the default of "Create a Java EE XXX app..." >>>>>>>> (without enterprise flag) but my concern is about the setup of >>>>>>>> EAP repository setup. >>>>>>> >>>>>>> That part is the smallest problem ;) We already support it. >>>>>>> >>>>>>> Try create an enterprise archetype in JBDS while running with >>>>>>> ~/.m2/settings.xml that does >>>>>>> *not* have access to the enterprise artifacts. We'll warn and >>>>>>> guide you to add maven.repository url) >>>>>>> >>>>>>> We do that based on a list of key artifacts we check - this is >>>>>>> currently outside stacks.yml, >>>>>>> but could probably make sense to add this bit of info so other >>>>>>> than jbds can do similar things. >>>>>>> >>>>>>> My main concern is how to find out which archetypes that matches >>>>>>> and how to toggle/manage them. >>>>>> >>>>>> Shouldn't this new GAV change help you to find out ? >>>>> >>>>> I would rather not rely on GAV to decide that if can be avoided. >>>>> >>>>> But your suggestion is that the group "org.jboss.archetypes.eap" >>>>> decides it - >>>>> which would be the "non-product" version ? there is no 1-to-1 >>>>> mapping. >>>>> >>>>> Thing is that we loose the ability to toggle when the mvn wizard >>>>> is running - the decision have to be made upfront. >>>>> >>>>> But I think we'll just have to drop that "feature" and force users >>>>> to know more upfront - >>>>> possibly in the case no runtime is known give them a choice of >>>>> possible archetypes for JavaEE ? >>>>> >>>>> Fred - do you forsee issues/concerns ? >>>>> >>>>> /max >>>>> >>>>>>> >>>>>>> /max >>>>>>> >>>>>>> >>>>>>>> I could be wrong but that's is how I understand that part of >>>>>>>> the plan. >>>>>>>> >>>>>>>> >>>>>>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>>>> I probably missed it but where does it say the enterprise >>>>>>>>>> flag goes away for archetypes? >>>>>>>>> >>>>>>>>> thats in the other thread(s) about changing the way things are >>>>>>>>> released/versioned. >>>>>>>>> >>>>>>>>> Here it was suggested archetypes would be productized similar >>>>>>>>> to quickstarts, thus >>>>>>>>> there would be forks/duplicates instead of one version we >>>>>>>>> could use and then toggle >>>>>>>>> between one or the other target..thus no enterprise flag. >>>>>>>>> >>>>>>>>> At least thats how I understood the proposal and we should >>>>>>>>> work with Rafael on >>>>>>>>> that. >>>>>>>>> >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I'm resurrecting this subject because Forge Team started >>>>>>>>>>>> to brainstorm about the Stacks Add-on to Forge. >>>>>>>>>>>> >>>>>>>>>>>> Max, >>>>>>>>>>>> >>>>>>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>>>>>> >>>>>>>>>>>> - Change format (getting the opportunity of repo location >>>>>>>>>>>> change) >>>>>>>>>>>> vs >>>>>>>>>>>> - Still using the same format with workarounds >>>>>>>>>>> >>>>>>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>>>>>> feedback since he been doing most of the >>>>>>>>>>> license/repositoryurl workarounds we need. >>>>>>>>>>> >>>>>>>>>>> But from top of my head: >>>>>>>>>>> >>>>>>>>>>> I don't see how stacks 1.0 can change location (i.e. url) >>>>>>>>>>> since that will break JBDS 7.0/JBT 4.1 users. Are you really >>>>>>>>>>> talking about a physical move, or simply where you would out >>>>>>>>>>> the "next" version ? The 1.0 url is stuck and should stay >>>>>>>>>>> there for years from what I can see. >>>>>>>>>>> >>>>>>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>>>>>> names were tied to element defined as licenses. Shouldn't it >>>>>>>>>>> be licenses AND releaseversions or something ? what other >>>>>>>>>>> metadata is needed here ? ...and if it is just to avoid >>>>>>>>>>> repeating it is this just like "entities" like in a DTD ? >>>>>>>>>>> About "repositoryUrl and extrarepositories" to bomversion >>>>>>>>>>> then this seem to be a variation on how we in eclipse >>>>>>>>>>> decides wether we need to add something to the users >>>>>>>>>>> settings.xml or not ? In that case then >>>>>>>>>>> repositoryurl/extrarepositories are not the only information >>>>>>>>>>> relevant. Its more relevant to know which key artifacts to >>>>>>>>>>> look for. We added that to our own examples metadata - Fred >>>>>>>>>>> knows more. >>>>>>>>>>> >>>>>>>>>>> Then based on the availability of these artifaacts we either >>>>>>>>>>> warn or not. If a warning we then suggest to add >>>>>>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - >>>>>>>>>>> that would be bad form IMO. In any case - I don't think >>>>>>>>>>> repositoryurl and extrarepositories are good on its own - >>>>>>>>>>> needs more info. >>>>>>>>>>> >>>>>>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>>>>>> anymore. That at least from where I'm looking changes the >>>>>>>>>>> workflow we need to provide to the user since we just starts >>>>>>>>>>> with user requesting "Create a JavaEE Web app" ...and how do >>>>>>>>>>> we ensure the archetypes stay consistent (before just a >>>>>>>>>>> simple flag) now its spread between multiple >>>>>>>>>>> repositories/archetype versions. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /max >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> As part of the "new organization" plan, it's a good time >>>>>>>>>>>>> to update stacks format since it will be hosted on the new >>>>>>>>>>>>> github organization. >>>>>>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>>>>>>> keep using 1.0 format >>>>>>>>>>>>> >>>>>>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>>>>>> >>>>>>>>>>>>> - Rename Licenses to Metadata >>>>>>>>>>>>> >>>>>>>>>>>>> Justification: I've been using Licenses today as an >>>>>>>>>>>>> metadata >>>>>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>>>>> >>>>>>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>>>>> >>>>>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>>>>> repositories are Required: >>>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>>>>>> built on >>>>>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>>>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>>>>> >>>>>>>>>>>>> Workaround: Create an standard tag called >>>>>>>>>>>>> *repositories* and >>>>>>>>>>>>> add every non maven central repository required. >>>>>>>>>>>>> >>>>>>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>>>>>> possible impacts on this format change. >>>>>>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved >>>>>>>>>>>>> to jboss-developer github organization. So it's a good >>>>>>>>>>>>> change to update it. The 1.0 and 1.1 should coexist for a >>>>>>>>>>>>> while and maybe stacks-client should have a "migration" >>>>>>>>>>>>> feature to permit a smooth transition. >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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

Fred, Awesome!!!!! Thanks for testing! For the last, I think we should now check the details around the archetypes (cc Max): - We can just change the GAV and keep the enterprise flag, but it seems that this won't work. Can you confirm that?

- Or totally split the enterprise and "sandbox" archetypes. We can add a label on enterprise ArchetypeVersion on Stacks to identify them.

Thanks once more, Fred. Em 28/08/13 18:31, Fred Bricon escreveu: > Le mardi 27 août 2013 18:34:45, Fred Bricon a écrit : >> Le mardi 27 août 2013 16:11:22, Rafael Benevides a écrit : >>> Hi everybody. >>> >>> After thinking about the effort, management cost, the pro and cons and >>> the benefits that we could get by updating the format I got the >>> following conclusion: >>> >>> IT DOESN'T WORTH TO UPDATE THE FORMAT NOW. >>> >>> We can survive with the workarounds proposed on the first email with >>> the justification of the changes. I'll update the new organization >>> plan to keep the 1.0 format but I'd like to check about moving stacks >>> repo from jdf repository to the new one. >>> >>> As on previous e-mail I saw that github redirects works pretty well >>> with http 301 - moved permanently. >>> >>> I want to get sure that JBDS/JBT can work with this redirection. >> I'll perform some tests tomorrow to check if it works >> > After adding > -Dorg.jboss.tools.stacks.url_stacks=https://raw.github.com/fbricon/jdf-stack/1.0.0.Final/stacks.yaml > to jbdevstudio.ini in JBDS 7.0.0GA, > JBoss central shows the correct stacks (botched on purpose) from > https://raw.github.com/open-archetypes/jdf-stack/1.0.0.Final/stacks.yaml. > > So we're cool. > > >>> >>> Em 26/08/13 06:14, Max Rydahl Andersen escreveu: >>>> On Thu, Aug 22, 2013 at 11:50:46AM -0300, Rafael Benevides wrote: >>>>> Fred/Max >>>>> >>>>> I was thinking about this, and I have the following proposal. Please >>>>> feel free to comment: >>>>> >>>>> Today on 1.0 stacks there's the repositoryURL attribute on both >>>>> Archetype and ArchetypeVersion. Shouldn't we say that a non-empty >>>>> repositoryURL means that it needs to add that URL to the >>>>> ~/.m2/settings.xml ? >>>> >>>> It is not that simple. >>>> >>>> You need list of key artifacts to check for - if the user already >>>> have that available in >>>> their company repository then it is noise to add this url. >>>> >>>> That is why we check if we can resolve the key artifacts, and if they >>>> can't *then* we >>>> suggest adding that repository. >>>> >>>> /max >>>> >>>>> >>>>> Em 19/08/13 11:31, Fred Bricon escreveu: >>>>>> We could treat enterprise versions the same way we currently treat >>>>>> "blank" versions. >>>>>> i.e. the default (community) archetype would have an enterprise >>>>>> attribute pointing at the corresponding archetype. >>>>>> See >>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >>>>>> >>>>>> for instance. >>>>>> >>>>>> >>>>>> Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>>>>>> On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>>>>>>> >>>>>>>> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>>>>>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides >>>>>>>>> wrote: >>>>>>>>>> You're right Max. >>>>>>>>>> >>>>>>>>>> That was the proposal. And we should think a little bit more >>>>>>>>>> about the workflow since the plan is to change Archetypes GAV >>>>>>>>>> to: org.jboss.archetypes.eap: >>>>>>>>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>>>>>>> >>>>>>>>>> I believe that the "product focus" idea is to have this EAP >>>>>>>>>> archetypes as the default of "Create a Java EE XXX app..." >>>>>>>>>> (without enterprise flag) but my concern is about the setup of >>>>>>>>>> EAP repository setup. >>>>>>>>> >>>>>>>>> That part is the smallest problem ;) We already support it. >>>>>>>>> >>>>>>>>> Try create an enterprise archetype in JBDS while running with >>>>>>>>> ~/.m2/settings.xml that does >>>>>>>>> *not* have access to the enterprise artifacts. We'll warn and >>>>>>>>> guide you to add maven.repository url) >>>>>>>>> >>>>>>>>> We do that based on a list of key artifacts we check - this is >>>>>>>>> currently outside stacks.yml, >>>>>>>>> but could probably make sense to add this bit of info so other >>>>>>>>> than jbds can do similar things. >>>>>>>>> >>>>>>>>> My main concern is how to find out which archetypes that matches >>>>>>>>> and how to toggle/manage them. >>>>>>>> >>>>>>>> Shouldn't this new GAV change help you to find out ? >>>>>>> >>>>>>> I would rather not rely on GAV to decide that if can be avoided. >>>>>>> >>>>>>> But your suggestion is that the group "org.jboss.archetypes.eap" >>>>>>> decides it - >>>>>>> which would be the "non-product" version ? there is no 1-to-1 >>>>>>> mapping. >>>>>>> >>>>>>> Thing is that we loose the ability to toggle when the mvn wizard >>>>>>> is running - the decision have to be made upfront. >>>>>>> >>>>>>> But I think we'll just have to drop that "feature" and force users >>>>>>> to know more upfront - >>>>>>> possibly in the case no runtime is known give them a choice of >>>>>>> possible archetypes for JavaEE ? >>>>>>> >>>>>>> Fred - do you forsee issues/concerns ? >>>>>>> >>>>>>> /max >>>>>>> >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>> >>>>>>>>>> I could be wrong but that's is how I understand that part of >>>>>>>>>> the plan. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>>>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>>>>>> I probably missed it but where does it say the enterprise >>>>>>>>>>>> flag goes away for archetypes? >>>>>>>>>>> >>>>>>>>>>> thats in the other thread(s) about changing the way things are >>>>>>>>>>> released/versioned. >>>>>>>>>>> >>>>>>>>>>> Here it was suggested archetypes would be productized similar >>>>>>>>>>> to quickstarts, thus >>>>>>>>>>> there would be forks/duplicates instead of one version we >>>>>>>>>>> could use and then toggle >>>>>>>>>>> between one or the other target..thus no enterprise flag. >>>>>>>>>>> >>>>>>>>>>> At least thats how I understood the proposal and we should >>>>>>>>>>> work with Rafael on >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /max >>>>>>>>>>> >>>>>>>>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm resurrecting this subject because Forge Team started >>>>>>>>>>>>>> to brainstorm about the Stacks Add-on to Forge. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Max, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Change format (getting the opportunity of repo location >>>>>>>>>>>>>> change) >>>>>>>>>>>>>> vs >>>>>>>>>>>>>> - Still using the same format with workarounds >>>>>>>>>>>>> >>>>>>>>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>>>>>>>> feedback since he been doing most of the >>>>>>>>>>>>> license/repositoryurl workarounds we need. >>>>>>>>>>>>> >>>>>>>>>>>>> But from top of my head: >>>>>>>>>>>>> >>>>>>>>>>>>> I don't see how stacks 1.0 can change location (i.e. url) >>>>>>>>>>>>> since that will break JBDS 7.0/JBT 4.1 users. Are you really >>>>>>>>>>>>> talking about a physical move, or simply where you would out >>>>>>>>>>>>> the "next" version ? The 1.0 url is stuck and should stay >>>>>>>>>>>>> there for years from what I can see. >>>>>>>>>>>>> >>>>>>>>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>>>>>>>> names were tied to element defined as licenses. Shouldn't it >>>>>>>>>>>>> be licenses AND releaseversions or something ? what other >>>>>>>>>>>>> metadata is needed here ? ...and if it is just to avoid >>>>>>>>>>>>> repeating it is this just like "entities" like in a DTD ? >>>>>>>>>>>>> About "repositoryUrl and extrarepositories" to bomversion >>>>>>>>>>>>> then this seem to be a variation on how we in eclipse >>>>>>>>>>>>> decides wether we need to add something to the users >>>>>>>>>>>>> settings.xml or not ? In that case then >>>>>>>>>>>>> repositoryurl/extrarepositories are not the only information >>>>>>>>>>>>> relevant. Its more relevant to know which key artifacts to >>>>>>>>>>>>> look for. We added that to our own examples metadata - Fred >>>>>>>>>>>>> knows more. >>>>>>>>>>>>> >>>>>>>>>>>>> Then based on the availability of these artifaacts we either >>>>>>>>>>>>> warn or not. If a warning we then suggest to add >>>>>>>>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>>>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - >>>>>>>>>>>>> that would be bad form IMO. In any case - I don't think >>>>>>>>>>>>> repositoryurl and extrarepositories are good on its own - >>>>>>>>>>>>> needs more info. >>>>>>>>>>>>> >>>>>>>>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>>>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>>>>>>>> anymore. That at least from where I'm looking changes the >>>>>>>>>>>>> workflow we need to provide to the user since we just starts >>>>>>>>>>>>> with user requesting "Create a JavaEE Web app" ...and how do >>>>>>>>>>>>> we ensure the archetypes stay consistent (before just a >>>>>>>>>>>>> simple flag) now its spread between multiple >>>>>>>>>>>>> repositories/archetype versions. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /max >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As part of the "new organization" plan, it's a good time >>>>>>>>>>>>>>> to update stacks format since it will be hosted on the new >>>>>>>>>>>>>>> github organization. >>>>>>>>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>>>>>>>> proposal to see if everyone agrees on that or if should we >>>>>>>>>>>>>>> keep using 1.0 format >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Rename Licenses to Metadata >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Justification: I've been using Licenses today as an >>>>>>>>>>>>>>> metadata >>>>>>>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>>>>>>> repositories are Required: >>>>>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>>>>>>>> built on >>>>>>>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from >>>>>>>>>>>>>>> WFK 2.1.0 >>>>>>>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Workaround: Create an standard tag called >>>>>>>>>>>>>>> *repositories* and >>>>>>>>>>>>>>> add every non maven central repository required. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>>>>>>>> possible impacts on this format change. >>>>>>>>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be moved >>>>>>>>>>>>>>> to jboss-developer github organization. So it's a good >>>>>>>>>>>>>>> change to update it. The 1.0 and 1.1 should coexist for a >>>>>>>>>>>>>>> while and maybe stacks-client should have a "migration" >>>>>>>>>>>>>>> feature to permit a smooth transition. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 > >

I think it will require a PoC We will update the Archetypes after we finish the quickstarts migration (because the archetypes are synched with the quickstarts). When we're closer to this change, I'll ping JBDS team. Thanks for the support, guys! Em 29/08/13 10:23, Fred Bricon escreveu: > Le jeudi 29 août 2013 14:30:41, Rafael Benevides a écrit : >> Fred, >> >> Awesome!!!!! Thanks for testing! >> >> For the last, I think we should now check the details around the >> archetypes (cc Max): >> >> - We can just change the GAV and keep the enterprise flag, but it >> seems that this won't work. Can you confirm that? > Not sure what you mean here. If you just want to replace existing > (community) archetypes in stacks.yaml with new, identical in usage, > enterprisey-GAV ones, that won't impact JBDS, as long as the archetype > keys in stacks.yaml remains unchanged, otherwise older JBDS/JBT > versions would break. And that was a long phrase :-) > >> - Or totally split the enterprise and "sandbox" archetypes. We can add >> a label on enterprise ArchetypeVersion on Stacks to identify them. > if you add new, enterprisey archetypes, next to the community ones, > then : > - community archetypes will still need to keep the enterprise flag, > again, to keep backward compat with older JBDS/JBT versions. Unless we > decide to use a different stacks.yaml URL. > - we'll need to make some modifications in JBDS/JBT to be able to > switch between community/enterprise archetypes, similar to what's done > for blank archetypes. I guess we could switch on the archetype key > (suffixed with -entreprise) since archetype definitions don't have > labels (apparently). The -enterprise suffix is as good a convention as > any. > > >> >> Thanks once more, Fred. >> >> >> Em 28/08/13 18:31, Fred Bricon escreveu: >>> Le mardi 27 août 2013 18:34:45, Fred Bricon a écrit : >>>> Le mardi 27 août 2013 16:11:22, Rafael Benevides a écrit : >>>>> Hi everybody. >>>>> >>>>> After thinking about the effort, management cost, the pro and cons >>>>> and >>>>> the benefits that we could get by updating the format I got the >>>>> following conclusion: >>>>> >>>>> IT DOESN'T WORTH TO UPDATE THE FORMAT NOW. >>>>> >>>>> We can survive with the workarounds proposed on the first email with >>>>> the justification of the changes. I'll update the new organization >>>>> plan to keep the 1.0 format but I'd like to check about moving stacks >>>>> repo from jdf repository to the new one. >>>>> >>>>> As on previous e-mail I saw that github redirects works pretty well >>>>> with http 301 - moved permanently. >>>>> >>>>> I want to get sure that JBDS/JBT can work with this redirection. >>>> I'll perform some tests tomorrow to check if it works >>>> >>> After adding >>> -Dorg.jboss.tools.stacks.url_stacks=https://raw.github.com/fbricon/jdf-stack/1.0.0.Final/stacks.yaml >>> >>> to jbdevstudio.ini in JBDS 7.0.0GA, >>> JBoss central shows the correct stacks (botched on purpose) from >>> https://raw.github.com/open-archetypes/jdf-stack/1.0.0.Final/stacks.yaml. >>> >>> >>> So we're cool. >>> >>> >>>>> >>>>> Em 26/08/13 06:14, Max Rydahl Andersen escreveu: >>>>>> On Thu, Aug 22, 2013 at 11:50:46AM -0300, Rafael Benevides wrote: >>>>>>> Fred/Max >>>>>>> >>>>>>> I was thinking about this, and I have the following proposal. >>>>>>> Please >>>>>>> feel free to comment: >>>>>>> >>>>>>> Today on 1.0 stacks there's the repositoryURL attribute on both >>>>>>> Archetype and ArchetypeVersion. Shouldn't we say that a non-empty >>>>>>> repositoryURL means that it needs to add that URL to the >>>>>>> ~/.m2/settings.xml ? >>>>>> >>>>>> It is not that simple. >>>>>> >>>>>> You need list of key artifacts to check for - if the user already >>>>>> have that available in >>>>>> their company repository then it is noise to add this url. >>>>>> >>>>>> That is why we check if we can resolve the key artifacts, and if >>>>>> they >>>>>> can't *then* we >>>>>> suggest adding that repository. >>>>>> >>>>>> /max >>>>>> >>>>>>> >>>>>>> Em 19/08/13 11:31, Fred Bricon escreveu: >>>>>>>> We could treat enterprise versions the same way we currently treat >>>>>>>> "blank" versions. >>>>>>>> i.e. the default (community) archetype would have an enterprise >>>>>>>> attribute pointing at the corresponding archetype. >>>>>>>> See >>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L1131 >>>>>>>> >>>>>>>> >>>>>>>> for instance. >>>>>>>> >>>>>>>> >>>>>>>> Le 16/08/2013 10:17, Max Rydahl Andersen a écrit : >>>>>>>>> On Wed, Aug 14, 2013 at 09:42:32AM -0300, Rafael Benevides wrote: >>>>>>>>>> >>>>>>>>>> Em 14/08/13 06:10, Max Rydahl Andersen escreveu: >>>>>>>>>>> On Tue, Aug 13, 2013 at 11:06:43AM -0300, Rafael Benevides >>>>>>>>>>> wrote: >>>>>>>>>>>> You're right Max. >>>>>>>>>>>> >>>>>>>>>>>> That was the proposal. And we should think a little bit more >>>>>>>>>>>> about the workflow since the plan is to change Archetypes GAV >>>>>>>>>>>> to: org.jboss.archetypes.eap: >>>>>>>>>>>> jboss-javaee6-webapp-ear-archetype:6.1.0-redhat-X >>>>>>>>>>>> >>>>>>>>>>>> I believe that the "product focus" idea is to have this EAP >>>>>>>>>>>> archetypes as the default of "Create a Java EE XXX app..." >>>>>>>>>>>> (without enterprise flag) but my concern is about the setup of >>>>>>>>>>>> EAP repository setup. >>>>>>>>>>> >>>>>>>>>>> That part is the smallest problem ;) We already support it. >>>>>>>>>>> >>>>>>>>>>> Try create an enterprise archetype in JBDS while running with >>>>>>>>>>> ~/.m2/settings.xml that does >>>>>>>>>>> *not* have access to the enterprise artifacts. We'll warn and >>>>>>>>>>> guide you to add maven.repository url) >>>>>>>>>>> >>>>>>>>>>> We do that based on a list of key artifacts we check - this is >>>>>>>>>>> currently outside stacks.yml, >>>>>>>>>>> but could probably make sense to add this bit of info so other >>>>>>>>>>> than jbds can do similar things. >>>>>>>>>>> >>>>>>>>>>> My main concern is how to find out which archetypes that >>>>>>>>>>> matches >>>>>>>>>>> and how to toggle/manage them. >>>>>>>>>> >>>>>>>>>> Shouldn't this new GAV change help you to find out ? >>>>>>>>> >>>>>>>>> I would rather not rely on GAV to decide that if can be avoided. >>>>>>>>> >>>>>>>>> But your suggestion is that the group "org.jboss.archetypes.eap" >>>>>>>>> decides it - >>>>>>>>> which would be the "non-product" version ? there is no 1-to-1 >>>>>>>>> mapping. >>>>>>>>> >>>>>>>>> Thing is that we loose the ability to toggle when the mvn wizard >>>>>>>>> is running - the decision have to be made upfront. >>>>>>>>> >>>>>>>>> But I think we'll just have to drop that "feature" and force >>>>>>>>> users >>>>>>>>> to know more upfront - >>>>>>>>> possibly in the case no runtime is known give them a choice of >>>>>>>>> possible archetypes for JavaEE ? >>>>>>>>> >>>>>>>>> Fred - do you forsee issues/concerns ? >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /max >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I could be wrong but that's is how I understand that part of >>>>>>>>>>>> the plan. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Em 13/08/13 10:23, Max Rydahl Andersen escreveu: >>>>>>>>>>>>> On Tue, Aug 13, 2013 at 11:00:05AM +0200, Fred Bricon wrote: >>>>>>>>>>>>>> I probably missed it but where does it say the enterprise >>>>>>>>>>>>>> flag goes away for archetypes? >>>>>>>>>>>>> >>>>>>>>>>>>> thats in the other thread(s) about changing the way things >>>>>>>>>>>>> are >>>>>>>>>>>>> released/versioned. >>>>>>>>>>>>> >>>>>>>>>>>>> Here it was suggested archetypes would be productized similar >>>>>>>>>>>>> to quickstarts, thus >>>>>>>>>>>>> there would be forks/duplicates instead of one version we >>>>>>>>>>>>> could use and then toggle >>>>>>>>>>>>> between one or the other target..thus no enterprise flag. >>>>>>>>>>>>> >>>>>>>>>>>>> At least thats how I understood the proposal and we should >>>>>>>>>>>>> work with Rafael on >>>>>>>>>>>>> that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /max >>>>>>>>>>>>> >>>>>>>>>>>>>> Le 12/08/2013 16:52, Max Rydahl Andersen a écrit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm resurrecting this subject because Forge Team started >>>>>>>>>>>>>>>> to brainstorm about the Stacks Add-on to Forge. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Max, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do you have some thoughts/considerations on this: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Change format (getting the opportunity of repo location >>>>>>>>>>>>>>>> change) >>>>>>>>>>>>>>>> vs >>>>>>>>>>>>>>>> - Still using the same format with workarounds >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would like that Fred B. takes a look at this and give his >>>>>>>>>>>>>>> feedback since he been doing most of the >>>>>>>>>>>>>>> license/repositoryurl workarounds we need. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But from top of my head: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't see how stacks 1.0 can change location (i.e. url) >>>>>>>>>>>>>>> since that will break JBDS 7.0/JBT 4.1 users. Are you >>>>>>>>>>>>>>> really >>>>>>>>>>>>>>> talking about a physical move, or simply where you would >>>>>>>>>>>>>>> out >>>>>>>>>>>>>>> the "next" version ? The 1.0 url is stuck and should stay >>>>>>>>>>>>>>> there for years from what I can see. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> About "rename licenses to metdata"...I never realized those >>>>>>>>>>>>>>> names were tied to element defined as licenses. >>>>>>>>>>>>>>> Shouldn't it >>>>>>>>>>>>>>> be licenses AND releaseversions or something ? what other >>>>>>>>>>>>>>> metadata is needed here ? ...and if it is just to avoid >>>>>>>>>>>>>>> repeating it is this just like "entities" like in a DTD ? >>>>>>>>>>>>>>> About "repositoryUrl and extrarepositories" to bomversion >>>>>>>>>>>>>>> then this seem to be a variation on how we in eclipse >>>>>>>>>>>>>>> decides wether we need to add something to the users >>>>>>>>>>>>>>> settings.xml or not ? In that case then >>>>>>>>>>>>>>> repositoryurl/extrarepositories are not the only >>>>>>>>>>>>>>> information >>>>>>>>>>>>>>> relevant. Its more relevant to know which key artifacts to >>>>>>>>>>>>>>> look for. We added that to our own examples metadata - Fred >>>>>>>>>>>>>>> knows more. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Then based on the availability of these artifaacts we >>>>>>>>>>>>>>> either >>>>>>>>>>>>>>> warn or not. If a warning we then suggest to add >>>>>>>>>>>>>>> maven.enterprise.redhat.com/techpreview/all to the >>>>>>>>>>>>>>> ~/.m2/settings.xml. We do *not* add invidivual repositories >>>>>>>>>>>>>>> (like EAP600 and EAP601) to users settings nor pom.xml - >>>>>>>>>>>>>>> that would be bad form IMO. In any case - I don't think >>>>>>>>>>>>>>> repositoryurl and extrarepositories are good on its own - >>>>>>>>>>>>>>> needs more info. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My biggest gotcha with upcoming changes is how the tools >>>>>>>>>>>>>>> can/should cope with archetypes not having enterprise flag >>>>>>>>>>>>>>> anymore. That at least from where I'm looking changes the >>>>>>>>>>>>>>> workflow we need to provide to the user since we just >>>>>>>>>>>>>>> starts >>>>>>>>>>>>>>> with user requesting "Create a JavaEE Web app" ...and >>>>>>>>>>>>>>> how do >>>>>>>>>>>>>>> we ensure the archetypes stay consistent (before just a >>>>>>>>>>>>>>> simple flag) now its spread between multiple >>>>>>>>>>>>>>> repositories/archetype versions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /max >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As part of the "new organization" plan, it's a good time >>>>>>>>>>>>>>>>> to update stacks format since it will be hosted on the >>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>> github organization. >>>>>>>>>>>>>>>>> I've analyzed the changes need and attached a Stacks 1.1 >>>>>>>>>>>>>>>>> proposal to see if everyone agrees on that or if >>>>>>>>>>>>>>>>> should we >>>>>>>>>>>>>>>>> keep using 1.0 format >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Changes from 1.0 to 1.1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Rename Licenses to Metadata >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Justification: I've been using Licenses today as an >>>>>>>>>>>>>>>>> metadata >>>>>>>>>>>>>>>>> section to avoid repeating metadatas like version, >>>>>>>>>>>>>>>>> repositories, licenses, etc: >>>>>>>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Workaround: Leave it as it is >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - add repositoryURL and extraRepositories to BomVersion. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Justification: I've been using labels to to tag what >>>>>>>>>>>>>>>>> repositories are Required: >>>>>>>>>>>>>>>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Some BOMs needs more than one repo as JPP ( JPP is >>>>>>>>>>>>>>>>> built on >>>>>>>>>>>>>>>>> top of EAP 6.0.1, but it is using RichFaces from >>>>>>>>>>>>>>>>> WFK 2.1.0 >>>>>>>>>>>>>>>>> that is built on top of EAP 6.0.0) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Workaround: Create an standard tag called >>>>>>>>>>>>>>>>> *repositories* and >>>>>>>>>>>>>>>>> add every non maven central repository required. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So I'd like to here your thoughts about it and analyze >>>>>>>>>>>>>>>>> possible impacts on this format change. >>>>>>>>>>>>>>>>> OBS.: Remember that stacks 1.0 repo is planned to be >>>>>>>>>>>>>>>>> moved >>>>>>>>>>>>>>>>> to jboss-developer github organization. So it's a good >>>>>>>>>>>>>>>>> change to update it. The 1.0 and 1.1 should coexist for a >>>>>>>>>>>>>>>>> while and maybe stacks-client should have a "migration" >>>>>>>>>>>>>>>>> feature to permit a smooth transition. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> 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 >>> >>> >> > > _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

MAx, About the metadata: I don't know yet what other metadata is need here and yes it is just to avoid repeating. That's why I thought to use a general name "metadata" to give us more flexibility if something new appears. But that's the minor issue. I'm really concerned about the need to have the repository URL information for BOMs and I didn't want to have this as a Label unless that we judge that we can't change the stacks format. Btw, For how long time we should maintain the stacks format 1.0 ?

Em 12/08/13 11:52, Max Rydahl Andersen escreveu: > > On Tue, Aug 06, 2013 at 02:16:10PM -0300, Rafael Benevides wrote: >> Hi all, >> >> I'm resurrecting this subject because Forge Team started to >> brainstorm about the Stacks Add-on to Forge. >> >> Max, >> >> Do you have some thoughts/considerations on this: >> >> - Change format (getting the opportunity of repo location change) >> vs >> - Still using the same format with workarounds > > I would like that Fred B. takes a look at this and give his feedback > since he been doing most of the license/repositoryurl workarounds we > need. > > But from top of my head: > > I don't see how stacks 1.0 can change location (i.e. url) since that > will break JBDS 7.0/JBT 4.1 users. Are you really talking about a > physical move, or simply where you would out the "next" version ? The > 1.0 url is stuck and should stay there for years from what I can see. > > About "rename licenses to metdata"...I never realized those names > were tied to element defined as licenses. Shouldn't it be licenses > AND releaseversions or something ? what other metadata is needed here > ? ...and if it is just to avoid repeating it is this just like > "entities" like in a DTD ? About "repositoryUrl and > extrarepositories" to bomversion then this seem to be a variation on > how we in eclipse decides wether we need to add something to the > users settings.xml or not ? In that case then > repositoryurl/extrarepositories are not the only information > relevant. Its more relevant to know which key artifacts to look for. > We added that to our own examples metadata - Fred knows more. > > Then based on the availability of these artifaacts we either warn or > not. If a warning we then suggest to add > maven.enterprise.redhat.com/techpreview/all to the > ~/.m2/settings.xml. We do *not* add invidivual repositories (like > EAP600 and EAP601) to users settings nor pom.xml - that would be bad > form IMO. In any case - I don't think repositoryurl and > extrarepositories are good on its own - needs more info. > > My biggest gotcha with upcoming changes is how the tools can/should > cope with archetypes not having enterprise flag anymore. That at > least from where I'm looking changes the workflow we need to provide > to the user since we just starts with user requesting "Create a > JavaEE Web app" ...and how do we ensure the archetypes stay > consistent (before just a simple flag) now its spread between > multiple repositories/archetype versions. > > > /max > >> >> Thanks >> >> Em 12/07/13 10:47, Rafael Benevides escreveu: >>> Hi all, >>> >>> As part of the "new organization" plan, it's a good time to update >>> stacks format since it will be hosted on the new github organization. >>> I've analyzed the changes need and attached a Stacks 1.1 proposal >>> to see if everyone agrees on that or if should we keep using 1.0 >>> format >>> >>> Changes from 1.0 to 1.1 >>> >>> - Rename Licenses to Metadata >>> >>> Justification: I've been using Licenses today as an metadata >>> section to avoid repeating metadatas like version, >>> repositories, licenses, etc: >>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>> >>> >>> Workaround: Leave it as it is >>> >>> - add repositoryURL and extraRepositories to BomVersion. >>> >>> Justification: I've been using labels to to tag what >>> repositories are Required: >>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>> >>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>> that is built on top of EAP 6.0.0) >>> >>> Workaround: Create an standard tag called *repositories* and >>> add every non maven central repository required. >>> >>> So I'd like to here your thoughts about it and analyze possible >>> impacts on this format change. >>> OBS.: Remember that stacks 1.0 repo is planned to be moved to >>> jboss-developer github organization. So it's a good change to >>> update it. The 1.0 and 1.1 should coexist for a while and maybe >>> stacks-client should have a "migration" feature to permit a smooth >>> transition. >>> >>> 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 >>> >>> >>> _______________________________________________ >>> jdf-dev mailing list >>> jdf-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>

Hi all, I'm resurrecting this subject because Forge Team started to brainstorm about the Stacks Add-on to Forge. Max, Do you have some thoughts/considerations on this: - Change format (getting the opportunity of repo location change) vs - Still using the same format with workarounds Thanks Em 12/07/13 10:47, Rafael Benevides escreveu: > Hi all, > > As part of the "new organization" plan, it's a good time to update > stacks format since it will be hosted on the new github organization. > I've analyzed the changes need and attached a Stacks 1.1 proposal to > see if everyone agrees on that or if should we keep using 1.0 format > > Changes from 1.0 to 1.1 > > - Rename Licenses to Metadata > > Justification: I've been using Licenses today as an metadata > section to avoid repeating metadatas like version, > repositories, licenses, etc: > https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 > > Workaround: Leave it as it is > > - add repositoryURL and extraRepositories to BomVersion. > > Justification: I've been using labels to to tag what > repositories are Required: > https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 > - Some BOMs needs more than one repo as JPP ( JPP is built on > top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 > that is built on top of EAP 6.0.0) > > Workaround: Create an standard tag called *repositories* and > add every non maven central repository required. > > So I'd like to here your thoughts about it and analyze possible > impacts on this format change. > OBS.: Remember that stacks 1.0 repo is planned to be moved to > jboss-developer github organization. So it's a good change to update > it. The 1.0 and 1.1 should coexist for a while and maybe > stacks-client should have a "migration" feature to permit a smooth > transition. > > 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 > > > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev

Hi, I haven't read the whole proposition yet, but just so we're clear : the current stacks 1.0 yaml file must stay available ad vitam aeternam (almost) for existing clients. We need to triple check moving the repo to a new organization will properly redirect stacks queries. I know redirects generally work on github now, but I don't know about potential caveats/limitations . Le mardi 6 août 2013 19:16:10, Rafael Benevides a écrit : > Hi all, > > I'm resurrecting this subject because Forge Team started to > brainstorm about the Stacks Add-on to Forge. > > Max, > > Do you have some thoughts/considerations on this: > > - Change format (getting the opportunity of repo location change) > vs > - Still using the same format with workarounds > > > Thanks > > Em 12/07/13 10:47, Rafael Benevides escreveu: >> Hi all, >> >> As part of the "new organization" plan, it's a good time to update >> stacks format since it will be hosted on the new github organization. >> I've analyzed the changes need and attached a Stacks 1.1 proposal to >> see if everyone agrees on that or if should we keep using 1.0 format >> >> Changes from 1.0 to 1.1 >> >> - Rename Licenses to Metadata >> >> Justification: I've been using Licenses today as an metadata >> section to avoid repeating metadatas like version, >> repositories, licenses, etc: >> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >> >> Workaround: Leave it as it is >> >> - add repositoryURL and extraRepositories to BomVersion. >> >> Justification: I've been using labels to to tag what >> repositories are Required: >> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >> >> - Some BOMs needs more than one repo as JPP ( JPP is built on >> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >> that is built on top of EAP 6.0.0) >> >> Workaround: Create an standard tag called *repositories* and >> add every non maven central repository required. >> >> So I'd like to here your thoughts about it and analyze possible >> impacts on this format change. >> OBS.: Remember that stacks 1.0 repo is planned to be moved to >> jboss-developer github organization. So it's a good change to update >> it. The 1.0 and 1.1 should coexist for a while and maybe >> stacks-client should have a "migration" feature to permit a smooth >> transition. >> >> 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 >> >> >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev >

On Thu, Aug 22, 2013 at 11:57:46AM -0300, Rafael Benevides wrote: > Just a minor comment about the stacks repository move: > > Recently we moved QSTools config file ( old url: > https://raw.github.com/jboss-jdf/qstools/master/config/qstools_config.yaml > ) that uses the same download and cache engine copied from > stacks-client (copied from forge - Thanks Lincoln) and it worked > pretty well (even changing also the repo name besides the > organization change) so github will keep redirecting the old url or how ? For me "move" means the old goes away. /max > > Em 12/08/13 12:06, Fred Bricon escreveu: >> Hi, I haven't read the whole proposition yet, but just so we're >> clear : the current stacks 1.0 yaml file must stay available ad >> vitam aeternam (almost) for existing clients. >> We need to triple check moving the repo to a new organization will >> properly redirect stacks queries. I know redirects generally work on >> github now, but I don't know about potential caveats/limitations . >> Le mardi 6 août 2013 19:16:10, Rafael Benevides a écrit : >> >>> Hi all, >>> >>> I'm resurrecting this subject because Forge Team started to >>> brainstorm about the Stacks Add-on to Forge. >>> >>> Max, >>> >>> Do you have some thoughts/considerations on this: >>> >>> - Change format (getting the opportunity of repo location change) >>> vs >>> - Still using the same format with workarounds >>> >>> >>> Thanks >>> >>> Em 12/07/13 10:47, Rafael Benevides escreveu: >>>> Hi all, >>>> >>>> As part of the "new organization" plan, it's a good time to update >>>> stacks format since it will be hosted on the new github organization. >>>> I've analyzed the changes need and attached a Stacks 1.1 proposal to >>>> see if everyone agrees on that or if should we keep using 1.0 format >>>> >>>> Changes from 1.0 to 1.1 >>>> >>>> - Rename Licenses to Metadata >>>> >>>> Justification: I've been using Licenses today as an metadata >>>> section to avoid repeating metadatas like version, >>>> repositories, licenses, etc: >>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L21-L34 >>>> >>>> >>>> Workaround: Leave it as it is >>>> >>>> - add repositoryURL and extraRepositories to BomVersion. >>>> >>>> Justification: I've been using labels to to tag what >>>> repositories are Required: >>>> https://github.com/jboss-jdf/jdf-stack/blob/1.0.0.Final/stacks.yaml#L441 >>>> >>>> >>>> - Some BOMs needs more than one repo as JPP ( JPP is built on >>>> top of EAP 6.0.1, but it is using RichFaces from WFK 2.1.0 >>>> that is built on top of EAP 6.0.0) >>>> >>>> Workaround: Create an standard tag called *repositories* and >>>> add every non maven central repository required. >>>> >>>> So I'd like to here your thoughts about it and analyze possible >>>> impacts on this format change. >>>> OBS.: Remember that stacks 1.0 repo is planned to be moved to >>>> jboss-developer github organization. So it's a good change to update >>>> it. The 1.0 and 1.1 should coexist for a while and maybe >>>> stacks-client should have a "migration" feature to permit a smooth >>>> transition. >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> jdf-dev mailing list >>>> jdf-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>> >> >> >