Hi all, Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only * quickstarts - change group id to follow products: - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. - add a sandbox group id which covers quickstarts not in products - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc * archetypes - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. - follow same version scheme as quickstarts, but use -atype-1 etc. * BOMs - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. - follow same version scheme as quickstarts, but use -bom-1 - projects will be encouraged to create BOMs as well Let me know what you think, Pete _______________________________________________ jdf-dev mailing list jdf-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jdf-dev

On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > Trying to grok consequences. > > On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. > > But will the archetypes still support enterprise=true|false flag ? No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. > Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? No, these are the product BOMs. We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com

> > /max > > On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >> Hi all, >> >> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >> >> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >> * quickstarts >> - change group id to follow products: >> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >> - add a sandbox group id which covers quickstarts not in products >> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >> * archetypes >> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >> - follow same version scheme as quickstarts, but use -atype-1 etc. >> * BOMs >> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >> - follow same version scheme as quickstarts, but use -bom-1 >> - projects will be encouraged to create BOMs as well >> >> Let me know what you think, >> >> Pete >> _______________________________________________ >> 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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlF5O8sACgkQU4HO8G8hNxXwkACdHa/hQ2cX1lF7FfjB7KblcaWF HZIAoLpXaKeyW4aEu9eWk/m+Pu75PvcY =68YA -----END PGP SIGNATURE-----

One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. Do we still follow this schema ? BOM: Only -bom-X release ? Archetypes: Every -atype-X release ? Runtime: Every "Early Access" and Product release ? By the way? How will we differ the "Candidate Release" from ".Final" Release ? Em 25/04/13 11:20, Marek Novotny escreveu: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/25/2013 04:13 PM, Pete Muir wrote: >> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; >> wrote: >> >>> Trying to grok consequences. >>> >>> On first read it seems it does not change anything - stacks.yml >>> will just refer to these and we can use them. >>> >>> But will the archetypes still support enterprise=true|false flag ? >> No. They will be product only. There may be other upstream community >> archetypes, but they will be project specifically. >> >>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into >>> products or does that go away for these cases? >> No, these are the product BOMs. >> >> We would no longer bundle them in the product zip repos, instead >> just deliver them online via maven.repository.redhat.com > that supposes to finish/change the uploading process as > maven.repository.redhat.com's content is currently only extracted > product zips. >>> /max >>> >>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>> Hi all, >>>> >>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, >>>> and came up with the following proposal: >>>> >>>> * jdf plugin for forge - longer term needs rolling into Forge >>>> core. This is issue https://issues.jboss.org/browse/FORGE-378. As >>>> this is proposed for Forge 2, we suggest not altering the version >>>> or group id of this plugin >>>> * qstools - version scheme (starting 1.x) is good. Alter group id >>>> when we do the next major release only >>>> * quickstarts >>>> - change group id to follow products: >>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>> - add a sandbox group id which covers quickstarts not in >>>> products >>>> - change versions to follow products major.minor.micro version, >>>> with a qualifier to allow bug fixes: >>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>> * archetypes >>>> - use group id scheme same as quickstarts but use >>>> org.jboss.archetype.eap etc. >>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>> * BOMs >>>> - use group id scheme same as quickstarts but use >>>> org.jboss.bom.eap etc. >>>> - follow same version scheme as quickstarts, but use -bom-1 >>>> - projects will be encouraged to create BOMs as well >>>> >>>> Let me know what you think, >>>> >>>> Pete >>>> _______________________________________________ >>>> 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 >> > > - -- Marek Novotny > - -- > WFK and Seam Product Lead > > Red Hat Czech s.r.o. > Purkynova 99 > 612 45 Brno > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev

We'll keep updating the stacks 1.0.0 format I hope since that is what JBDS 7.0 is going out with :) In any case I'm leaving on PTO in ~3hrs for 3weeks so I can't personally give feedback before after that - I've cc'ed Fred and Rob which should be able to give some feedback too. /max On Thu, Jul 04, 2013 at 11:22:29AM -0300, Rafael Benevides wrote: > After considering the feedback and after more brainstorming over the migration plan, we have a now a more detailed and tunned proposal on the new versioning and organization strategy. In the attached PDF you will find this detailed plan with all artifacts changes needed. > > It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0 > > Please, take a look on the attached plan and let us know what you think about it. The migration work should start by now on developer branches. > > Thank you > > Em 25/04/13 14:18, Rafael Benevides escreveu: >> One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? >> >> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. >> >> In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). >> >> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. >> >> Do we still follow this schema ? >> >> BOM: Only -bom-X release ? >> Archetypes: Every -atype-X release ? >> Runtime: Every "Early Access" and Product release ? >> >> By the way? How will we differ the "Candidate Release" from ".Final" Release ? >> >> Em 25/04/13 11:20, Marek Novotny escreveu: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: >>>> >>>>> Trying to grok consequences. >>>>> >>>>> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >>>>> >>>>> But will the archetypes still support enterprise=true|false flag ? >>>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. >>>> >>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? >>>> No, these are the product BOMs. >>>> >>>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com >>> that supposes to finish/change the uploading process as >>> maven.repository.redhat.com's content is currently only extracted >>> product zips. >>>>> /max >>>>> >>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>> Hi all, >>>>>> >>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>>>>> >>>>>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>>>>> * quickstarts >>>>>> - change group id to follow products: >>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>> - add a sandbox group id which covers quickstarts not in products >>>>>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>> * archetypes >>>>>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>> * BOMs >>>>>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>> - projects will be encouraged to create BOMs as well >>>>>> >>>>>> Let me know what you think, >>>>>> >>>>>> Pete >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> - -- Marek Novotny >>> - -- WFK and Seam Product Lead >>> >>> Red Hat Czech s.r.o. >>> Purkynova 99 >>> 612 45 Brno >>> _______________________________________________ >>> 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

Will this incorporate the versioning changes we discussed at JUDCon:Brazil? ----- Original Message ----- > From: "Rafael Benevides" <benevides(a)redhat.com&gt; > To: jdf-dev(a)lists.jboss.org, "Peter Muir" <pmuir(a)redhat.com&gt; > Sent: Thursday, July 4, 2013 8:22:29 AM > Subject: Re: [jdf-dev] New versioning and organisation strategy > > After considering the feedback and after more brainstorming over the > migration plan, we have a now a more detailed and tunned proposal on the > new versioning and organization strategy. In the attached PDF you will > find this detailed plan with all artifacts changes needed. > > It's also a good opportunity to update stacks.yaml format (and client) > to 1.1.0 > > Please, take a look on the attached plan and let us know what you think > about it. The migration work should start by now on developer branches. > > Thank you > > Em 25/04/13 14:18, Rafael Benevides escreveu: >> One thing that came in my mind is when to move the versions of >> Archetypes, Runtimes and BOMs to Stacks.yaml? >> >> I used to add only .Final (will be -bom-x) version of BOMs to >> Stacks.yaml. >> >> In the Case of Archetypes, I'm continuously updating it to the latest >> version (even being a CR - Candidate Release). >> >> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it >> with the "Early Access" label. >> >> Do we still follow this schema ? >> >> BOM: Only -bom-X release ? >> Archetypes: Every -atype-X release ? >> Runtime: Every "Early Access" and Product release ? >> >> By the way? How will we differ the "Candidate Release" from ".Final" >> Release ? >> >> Em 25/04/13 11:20, Marek Novotny escreveu: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Trying to grok consequences. >>>>> >>>>> On first read it seems it does not change anything - stacks.yml >>>>> will just refer to these and we can use them. >>>>> >>>>> But will the archetypes still support enterprise=true|false flag ? >>>> No. They will be product only. There may be other upstream community >>>> archetypes, but they will be project specifically. >>>> >>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into >>>>> products or does that go away for these cases? >>>> No, these are the product BOMs. >>>> >>>> We would no longer bundle them in the product zip repos, instead >>>> just deliver them online via maven.repository.redhat.com >>> that supposes to finish/change the uploading process as >>> maven.repository.redhat.com's content is currently only extracted >>> product zips. >>>>> /max >>>>> >>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>> Hi all, >>>>>> >>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, >>>>>> and came up with the following proposal: >>>>>> >>>>>> * jdf plugin for forge - longer term needs rolling into Forge >>>>>> core. This is issue https://issues.jboss.org/browse/FORGE-378. As >>>>>> this is proposed for Forge 2, we suggest not altering the version >>>>>> or group id of this plugin >>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id >>>>>> when we do the next major release only >>>>>> * quickstarts >>>>>> - change group id to follow products: >>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>> - add a sandbox group id which covers quickstarts not in >>>>>> products >>>>>> - change versions to follow products major.minor.micro version, >>>>>> with a qualifier to allow bug fixes: >>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>> * archetypes >>>>>> - use group id scheme same as quickstarts but use >>>>>> org.jboss.archetype.eap etc. >>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>> * BOMs >>>>>> - use group id scheme same as quickstarts but use >>>>>> org.jboss.bom.eap etc. >>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>> - projects will be encouraged to create BOMs as well >>>>>> >>>>>> Let me know what you think, >>>>>> >>>>>> Pete >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> - -- Marek Novotny >>> - -- >>> WFK and Seam Product Lead >>> >>> Red Hat Czech s.r.o. >>> Purkynova 99 >>> 612 45 Brno >>> _______________________________________________ >>> 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

From: "Pete Muir" <pmuir(a)redhat.com&gt; To: "Rafael Benevides" <benevides(a)redhat.com&gt; Cc: "Jason Porter" <jporter(a)redhat.com&gt;, jdf-dev(a)lists.jboss.org Sent: Friday, July 5, 2013 8:42:06 AM Subject: Re: [jdf-dev] New versioning and organisation strategy It does, I think, do you see any concerns Jason? On 5 Jul 2013, at 15:25, Rafael Benevides <benevides(a)redhat.com&gt; wrote: > Yes > > Em 05/07/13 11:20, Jason Porter escreveu: >> Will this incorporate the versioning changes we discussed at >> JUDCon:Brazil? >> >> ----- Original Message ----- >>> From: "Rafael Benevides" <benevides(a)redhat.com&gt; >>> To: jdf-dev(a)lists.jboss.org, "Peter Muir" <pmuir(a)redhat.com&gt; >>> Sent: Thursday, July 4, 2013 8:22:29 AM >>> Subject: Re: [jdf-dev] New versioning and organisation strategy >>> >>> After considering the feedback and after more brainstorming over the >>> migration plan, we have a now a more detailed and tunned proposal on the >>> new versioning and organization strategy. In the attached PDF you will >>> find this detailed plan with all artifacts changes needed. >>> >>> It's also a good opportunity to update stacks.yaml format (and client) >>> to 1.1.0 >>> >>> Please, take a look on the attached plan and let us know what you think >>> about it. The migration work should start by now on developer branches. >>> >>> Thank you >>> >>> Em 25/04/13 14:18, Rafael Benevides escreveu: >>>> One thing that came in my mind is when to move the versions of >>>> Archetypes, Runtimes and BOMs to Stacks.yaml? >>>> >>>> I used to add only .Final (will be -bom-x) version of BOMs to >>>> Stacks.yaml. >>>> >>>> In the Case of Archetypes, I'm continuously updating it to the latest >>>> version (even being a CR - Candidate Release). >>>> >>>> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it >>>> with the "Early Access" label. >>>> >>>> Do we still follow this schema ? >>>> >>>> BOM: Only -bom-X release ? >>>> Archetypes: Every -atype-X release ? >>>> Runtime: Every "Early Access" and Product release ? >>>> >>>> By the way? How will we differ the "Candidate Release" from ".Final" >>>> Release ? >>>> >>>> Em 25/04/13 11:20, Marek Novotny escreveu: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> Trying to grok consequences. >>>>>>> >>>>>>> On first read it seems it does not change anything - stacks.yml >>>>>>> will just refer to these and we can use them. >>>>>>> >>>>>>> But will the archetypes still support enterprise=true|false flag ? >>>>>> No. They will be product only. There may be other upstream community >>>>>> archetypes, but they will be project specifically. >>>>>> >>>>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into >>>>>>> products or does that go away for these cases? >>>>>> No, these are the product BOMs. >>>>>> >>>>>> We would no longer bundle them in the product zip repos, instead >>>>>> just deliver them online via maven.repository.redhat.com >>>>> that supposes to finish/change the uploading process as >>>>> maven.repository.redhat.com's content is currently only extracted >>>>> product zips. >>>>>>> /max >>>>>>> >>>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, >>>>>>>> and came up with the following proposal: >>>>>>>> >>>>>>>> * jdf plugin for forge - longer term needs rolling into Forge >>>>>>>> core. This is issue https://issues.jboss.org/browse/FORGE-378. As >>>>>>>> this is proposed for Forge 2, we suggest not altering the version >>>>>>>> or group id of this plugin >>>>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id >>>>>>>> when we do the next major release only >>>>>>>> * quickstarts >>>>>>>> - change group id to follow products: >>>>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>>>> - add a sandbox group id which covers quickstarts not in >>>>>>>> products >>>>>>>> - change versions to follow products major.minor.micro version, >>>>>>>> with a qualifier to allow bug fixes: >>>>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>>>> * archetypes >>>>>>>> - use group id scheme same as quickstarts but use >>>>>>>> org.jboss.archetype.eap etc. >>>>>>>> - follow same version scheme as quickstarts, but use -atype-1 >>>>>>>> etc. >>>>>>>> * BOMs >>>>>>>> - use group id scheme same as quickstarts but use >>>>>>>> org.jboss.bom.eap etc. >>>>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>>>> - projects will be encouraged to create BOMs as well >>>>>>>> >>>>>>>> Let me know what you think, >>>>>>>> >>>>>>>> Pete >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> - -- Marek Novotny >>>>> - -- >>>>> WFK and Seam Product Lead >>>>> >>>>> Red Hat Czech s.r.o. >>>>> Purkynova 99 >>>>> 612 45 Brno >>>>> _______________________________________________ >>>>> 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 >

Just had a look and if this Still means the archetypes now wont be shared ( there will be different GAV's for community and product) I'm missing how we'll know which to show/use in jboss central - and if it's all enterprise then it becomes impossible to use/try these without adding maven.enterprise.redhat.com to settings.xml. The latter is probably just what me must live with but the "multiple archetypes" for javaee web app and no easy way to have these for I.e. wildfly 8 Before Productization has content ready worries me. Now I'm on pto - see you 3 weeks. /max (sent from my phone) > On 04/07/2013, at 16.23, Rafael Benevides <benevides(a)redhat.com&gt; wrote: > > After considering the feedback and after more brainstorming over the migration plan, we have a now a more detailed and tunned proposal on the new versioning and organization strategy. In the attached PDF you will find this detailed plan with all artifacts changes needed. > > It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0 > > Please, take a look on the attached plan and let us know what you think about it. The migration work should start by now on developer branches. > > Thank you > > Em 25/04/13 14:18, Rafael Benevides escreveu: >> One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? >> >> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. >> >> In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). >> >> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. >> >> Do we still follow this schema ? >> >> BOM: Only -bom-X release ? >> Archetypes: Every -atype-X release ? >> Runtime: Every "Early Access" and Product release ? >> >> By the way? How will we differ the "Candidate Release" from ".Final" Release ? >> >> Em 25/04/13 11:20, Marek Novotny escreveu: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: >>>>> >>>>> Trying to grok consequences. >>>>> >>>>> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >>>>> >>>>> But will the archetypes still support enterprise=true|false flag ? >>>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. >>>> >>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? >>>> No, these are the product BOMs. >>>> >>>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com >>> that supposes to finish/change the uploading process as >>> maven.repository.redhat.com's content is currently only extracted >>> product zips. >>>>> /max >>>>> >>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>> Hi all, >>>>>> >>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>>>>> >>>>>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>>>>> * quickstarts >>>>>> - change group id to follow products: >>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>> - add a sandbox group id which covers quickstarts not in products >>>>>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>> * archetypes >>>>>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>> * BOMs >>>>>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>> - projects will be encouraged to create BOMs as well >>>>>> >>>>>> Let me know what you think, >>>>>> >>>>>> Pete >>>>>> _______________________________________________ >>>>>> 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 >>> - -- Marek Novotny >>> - -- WFK and Seam Product Lead >>> >>> Red Hat Czech s.r.o. >>> Purkynova 99 >>> 612 45 Brno >>> _______________________________________________ >>> jdf-dev mailing list >>> jdf-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jdf-dev > <Newversionandorganizationstrategy.pdf> > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev

On 6 Jul 2013, at 08:22, Max Andersen <manderse(a)redhat.com&gt; wrote: > Just had a look and if this Still means the archetypes now wont be shared ( there will be different GAV's for community and product) I'm missing how we'll know which to show/use in jboss central - and if it's all enterprise then it becomes impossible to use/try these without adding maven.enterprise.redhat.com to settings.xml. > > The latter is probably just what me must live with but the "multiple archetypes" for javaee web app and no easy way to have these for I.e. wildfly 8 > Before Productization has content ready worries me. We definitely plan to have archetypes for WF8, just in the sandbox, not in the main repo.

> > Now I'm on pto - see you 3 weeks. > > /max (sent from my phone) > > >> On 04/07/2013, at 16.23, Rafael Benevides <benevides(a)redhat.com&gt; wrote: >> >> After considering the feedback and after more brainstorming over the migration plan, we have a now a more detailed and tunned proposal on the new versioning and organization strategy. In the attached PDF you will find this detailed plan with all artifacts changes needed. >> >> It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0 >> >> Please, take a look on the attached plan and let us know what you think about it. The migration work should start by now on developer branches. >> >> Thank you >> >> Em 25/04/13 14:18, Rafael Benevides escreveu: >>> One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? >>> >>> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. >>> >>> In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). >>> >>> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. >>> >>> Do we still follow this schema ? >>> >>> BOM: Only -bom-X release ? >>> Archetypes: Every -atype-X release ? >>> Runtime: Every "Early Access" and Product release ? >>> >>> By the way? How will we differ the "Candidate Release" from ".Final" Release ? >>> >>> Em 25/04/13 11:20, Marek Novotny escreveu: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: >>>>>> >>>>>> Trying to grok consequences. >>>>>> >>>>>> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >>>>>> >>>>>> But will the archetypes still support enterprise=true|false flag ? >>>>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. >>>>> >>>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? >>>>> No, these are the product BOMs. >>>>> >>>>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com >>>> that supposes to finish/change the uploading process as >>>> maven.repository.redhat.com's content is currently only extracted >>>> product zips. >>>>>> /max >>>>>> >>>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>>>>>> >>>>>>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>>>>>> * quickstarts >>>>>>> - change group id to follow products: >>>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>>> - add a sandbox group id which covers quickstarts not in products >>>>>>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>>> * archetypes >>>>>>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>>> * BOMs >>>>>>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>>> - projects will be encouraged to create BOMs as well >>>>>>> >>>>>>> Let me know what you think, >>>>>>> >>>>>>> Pete >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> - -- Marek Novotny >>>> - -- WFK and Seam Product Lead >>>> >>>> Red Hat Czech s.r.o. >>>> Purkynova 99 >>>> 612 45 Brno >>>> _______________________________________________ >>>> jdf-dev mailing list >>>> jdf-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >> >> <Newversionandorganizationstrategy.pdf> >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev

>> We definitely plan to have archetypes for WF8, just in the sandbox, not in the main repo. > > coming back from pto and its great there will be archetypes for WF8 but that doesn't solve the problem of knowing which of now potentially many archetypes for a javaee web app should be used front and center in JBDS Central and we'll need to have maven.enterprise.redhat.com added to users settings.xml for them to work. > Before we had a default one which could switch between community and product - what do we use in replacement for that 'ease-of-use' feature ? Haven't we previously agreed to do this using stacks?

> /max > >>> >>> Now I'm on pto - see you 3 weeks. >>> >>> /max (sent from my phone) >>> >>> >>>> On 04/07/2013, at 16.23, Rafael Benevides <benevides(a)redhat.com&gt; wrote: >>>> >>>> After considering the feedback and after more brainstorming over the migration plan, we have a now a more detailed and tunned proposal on the new versioning and organization strategy. In the attached PDF you will find this detailed plan with all artifacts changes needed. >>>> >>>> It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0 >>>> >>>> Please, take a look on the attached plan and let us know what you think about it. The migration work should start by now on developer branches. >>>> >>>> Thank you >>>> >>>> Em 25/04/13 14:18, Rafael Benevides escreveu: >>>>> One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? >>>>> >>>>> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. >>>>> >>>>> In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). >>>>> >>>>> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. >>>>> >>>>> Do we still follow this schema ? >>>>> >>>>> BOM: Only -bom-X release ? >>>>> Archetypes: Every -atype-X release ? >>>>> Runtime: Every "Early Access" and Product release ? >>>>> >>>>> By the way? How will we differ the "Candidate Release" from ".Final" Release ? >>>>> >>>>> Em 25/04/13 11:20, Marek Novotny escreveu: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>>>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>> Trying to grok consequences. >>>>>>>> >>>>>>>> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >>>>>>>> >>>>>>>> But will the archetypes still support enterprise=true|false flag ? >>>>>>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. >>>>>>> >>>>>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? >>>>>>> No, these are the product BOMs. >>>>>>> >>>>>>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com >>>>>> that supposes to finish/change the uploading process as >>>>>> maven.repository.redhat.com's content is currently only extracted >>>>>> product zips. >>>>>>>> /max >>>>>>>> >>>>>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>>>>>>>> >>>>>>>>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>>>>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>>>>>>>> * quickstarts >>>>>>>>> - change group id to follow products: >>>>>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>>>>> - add a sandbox group id which covers quickstarts not in products >>>>>>>>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>>>>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>>>>> * archetypes >>>>>>>>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>>>>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>>>>> * BOMs >>>>>>>>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>>>>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>>>>> - projects will be encouraged to create BOMs as well >>>>>>>>> >>>>>>>>> Let me know what you think, >>>>>>>>> >>>>>>>>> Pete >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> - -- Marek Novotny >>>>>> - -- WFK and Seam Product Lead >>>>>> >>>>>> Red Hat Czech s.r.o. >>>>>> Purkynova 99 >>>>>> 612 45 Brno >>>>>> _______________________________________________ >>>>>> jdf-dev mailing list >>>>>> jdf-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>> >>>> <Newversionandorganizationstrategy.pdf> >>>> _______________________________________________ >>>> 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

Perhaps just different understanding of where we are at. On 6 Aug 2013, at 15:17, Max Andersen <manderse(a)redhat.com&gt; wrote: > On Tue, Aug 06, 2013 at 02:03:18PM +0100, Pete Muir wrote: > >>>> We definitely plan to have archetypes for WF8, just in the sandbox, not in the main repo. >>> >>> coming back from pto and its great there will be archetypes for WF8 but that doesn't solve the problem of knowing which of now potentially many archetypes for a javaee web app should be used front and center in JBDS Central and we'll need to have maven.enterprise.redhat.com added to users settings.xml for them to work. >>> Before we had a default one which could switch between community and product - what do we use in replacement for that 'ease-of-use' feature ? >> >> Haven't we previously agreed to do this using stacks? > > Yes, we agreed that would be an option but not made it concrete. > > Maybe I missed something ? > /max > >>> /max >>> >>>>> >>>>> Now I'm on pto - see you 3 weeks. >>>>> >>>>> /max (sent from my phone) >>>>> >>>>> >>>>>> On 04/07/2013, at 16.23, Rafael Benevides <benevides(a)redhat.com&gt; wrote: >>>>>> >>>>>> After considering the feedback and after more brainstorming over the migration plan, we have a now a more detailed and tunned proposal on the new versioning and organization strategy. In the attached PDF you will find this detailed plan with all artifacts changes needed. >>>>>> >>>>>> It's also a good opportunity to update stacks.yaml format (and client) to 1.1.0 >>>>>> >>>>>> Please, take a look on the attached plan and let us know what you think about it. The migration work should start by now on developer branches. >>>>>> >>>>>> Thank you >>>>>> >>>>>> Em 25/04/13 14:18, Rafael Benevides escreveu: >>>>>>> One thing that came in my mind is when to move the versions of Archetypes, Runtimes and BOMs to Stacks.yaml? >>>>>>> >>>>>>> I used to add only .Final (will be -bom-x) version of BOMs to Stacks.yaml. >>>>>>> >>>>>>> In the Case of Archetypes, I'm continuously updating it to the latest version (even being a CR - Candidate Release). >>>>>>> >>>>>>> For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it with the "Early Access" label. >>>>>>> >>>>>>> Do we still follow this schema ? >>>>>>> >>>>>>> BOM: Only -bom-X release ? >>>>>>> Archetypes: Every -atype-X release ? >>>>>>> Runtime: Every "Early Access" and Product release ? >>>>>>> >>>>>>> By the way? How will we differ the "Candidate Release" from ".Final" Release ? >>>>>>> >>>>>>> Em 25/04/13 11:20, Marek Novotny escreveu: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>>> On 04/25/2013 04:13 PM, Pete Muir wrote: >>>>>>>>>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> Trying to grok consequences. >>>>>>>>>> >>>>>>>>>> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >>>>>>>>>> >>>>>>>>>> But will the archetypes still support enterprise=true|false flag ? >>>>>>>>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. >>>>>>>>> >>>>>>>>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? >>>>>>>>> No, these are the product BOMs. >>>>>>>>> >>>>>>>>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com >>>>>>>> that supposes to finish/change the uploading process as >>>>>>>> maven.repository.redhat.com's content is currently only extracted >>>>>>>> product zips. >>>>>>>>>> /max >>>>>>>>>> >>>>>>>>>>> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>>>>>>>>>> >>>>>>>>>>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>>>>>>>>>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>>>>>>>>>> * quickstarts >>>>>>>>>>> - change group id to follow products: >>>>>>>>>>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>>>>>>>>>> - add a sandbox group id which covers quickstarts not in products >>>>>>>>>>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>>>>>>>>>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>>>>>>>>>> * archetypes >>>>>>>>>>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>>>>>>>>>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>>>>>>>>>> * BOMs >>>>>>>>>>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>>>>>>>>>> - follow same version scheme as quickstarts, but use -bom-1 >>>>>>>>>>> - projects will be encouraged to create BOMs as well >>>>>>>>>>> >>>>>>>>>>> Let me know what you think, >>>>>>>>>>> >>>>>>>>>>> Pete >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> - -- Marek Novotny >>>>>>>> - -- WFK and Seam Product Lead >>>>>>>> >>>>>>>> Red Hat Czech s.r.o. >>>>>>>> Purkynova 99 >>>>>>>> 612 45 Brno >>>>>>>> _______________________________________________ >>>>>>>> jdf-dev mailing list >>>>>>>> jdf-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jdf-dev >>>>>> >>>>>> <Newversionandorganizationstrategy.pdf> >>>>>> _______________________________________________ >>>>>> 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 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > >> Trying to grok consequences. >> >> On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. >> >> But will the archetypes still support enterprise=true|false flag ? > > No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. Okey - so either we need some extra metadata somewhere to know which archetype of now many to choose the right archetype for javaee project. Or we now require users to select specific runtime before starting to create a project (I would really not like that since its technically not needed). Also need to get something in to know which of the two repositories we need to add/suggest. Earlyaccess or the supported one. Note - I assume we'll Still introduce wildfly 8 etc into stacks.yml to get feedback/testing done early here, correct or?

> >> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? > > No, these are the product BOMs. Ok. Any reason to not use -redhat then ? Is that because they will now be considered a separate deliverable ?

> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com Okey so we can't count on them when users have just the zips for the offline mode. Just something to remember to copy when we go offline.

> >> >> /max >> >> On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >>> Hi all, >>> >>> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >>> >>> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >>> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >>> * quickstarts >>> - change group id to follow products: >>> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >>> - add a sandbox group id which covers quickstarts not in products >>> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >>> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >>> * archetypes >>> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >>> - follow same version scheme as quickstarts, but use -atype-1 etc. >>> * BOMs >>> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >>> - follow same version scheme as quickstarts, but use -bom-1 >>> - projects will be encouraged to create BOMs as well >>> >>> Let me know what you think, >>> >>> Pete >>> _______________________________________________ >>> jdf-dev mailing list >>> jdf-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jdf-dev >

On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse(a)redhat.com&gt; wrote: > Trying to grok consequences. > > On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. > > But will the archetypes still support enterprise=true|false flag ? No. They will be product only. There may be other upstream community archetypes, but they will be project specifically. > Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases? No, these are the product BOMs. We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com > > /max > > On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: >> Hi all, >> >> Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: >> >> * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin >> * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only >> * quickstarts >> - change group id to follow products: >> - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. >> - add a sandbox group id which covers quickstarts not in products >> - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: >> - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc >> * archetypes >> - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. >> - follow same version scheme as quickstarts, but use -atype-1 etc. >> * BOMs >> - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. >> - follow same version scheme as quickstarts, but use -bom-1 >> - projects will be encouraged to create BOMs as well >> >> Let me know what you think, >> >> Pete >> _______________________________________________ >> jdf-dev mailing list >> jdf-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jdf-dev