Hey all, I've finally gotten around to publishing the release process for integration stack tooling on jboss.org. Please give it a read and let me know if you have any questions regarding the process. The process is designed to help us produce and aggregate update site for all integration tools. You may want to review the contents of the initial build to ensure the correct version (and features) for your component is correct. Here are the links: process - https://community.jboss.org/wiki/IntegrationToolingReleaseProcess build - http://download.jboss.org/jbosstools/updates/integration/juno/integration... source - https://github.com/jbosstools/jbosstools-integration-stack Please provide any comments, questions, concerns, critiques, etc. based on what you see. Special thanks to Paul for working hard to get all this setup. Best, Rob _______________________________________________ Soa-tools-list mailing list Soa-tools-list(a)redhat.com https://www.redhat.com/mailman/listinfo/soa-tools-list

Wouldn't that have to be another site since this site is what JBoss central would point to. /max (sent from my phone) On 07/02/2013, at 17.44, Rob Cernich <rcernich(a)redhat.com&gt; wrote: > It looks like the content.xml does not contain a reference to the > JBT core update site. My understanding is that core is a > prerequisite for IS (i.e. how could a user point a fresh Juno > install at the update site if it doesn't also provide core JBT > plugins). > > ----- Original Message ----- >> Hey all, >> >> I've finally gotten around to publishing the release process for >> integration stack tooling on jboss.org. Please give it a read and >> let me know if you have any questions regarding the process. >> >> The process is designed to help us produce and aggregate update >> site >> for all integration tools. You may want to review the contents of >> the initial build to ensure the correct version (and features) for >> your component is correct. >> >> Here are the links: >> process - >> https://community.jboss.org/wiki/IntegrationToolingReleaseProcess >> build - >> http://download.jboss.org/jbosstools/updates/integration/juno/integration... >> source - >> https://github.com/jbosstools/jbosstools-integration-stack >> >> Please provide any comments, questions, concerns, critiques, etc. >> based on what you see. >> >> Special thanks to Paul for working hard to get all this setup. >> >> Best, >> Rob >> >> _______________________________________________ >> Soa-tools-list mailing list >> Soa-tools-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/soa-tools-list > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> Are you saying that because of the way JBoss Central and the > discovery mechanism works that this site needs to be free of any > other JBT artifacts, including repository references to those > sites? It's two parts: 1) yes, jboss central/discovery mechanism to avoid some mismatch in jboss tools versions. 2) even without #1 if JBITS main release site points to specific JBT version (i.e. juno/4.0.0.Final instead of juno/) p2 will keep getting these sites added and p2 will get slower and harder to keep stable for users (and us). If JBTIS main site would just point to the main JBT release site it would *probably* be fine but not sure how it affects builds. (I hate p2's slowness ;)

> My understand, from the wording on the update site, is that I can > take a plain old Eclipse Juno install, point it at this site and > install. However, looking at the contents, it does not have any > way of resolving core JBT artifacts that might be required by any > of the integration features. > > We either need to change the text of the site to say start with a > JBT x.y install or include a repository reference to the JBT > update site. I'm OK with either. Simplest for now would be to update the text. /max > > Best, > Rob > > ----- Original Message ----- >> Wouldn't that have to be another site since this site is what >> JBoss >> central would point to. >> >> /max (sent from my phone) >> >> >> On 07/02/2013, at 17.44, Rob Cernich <rcernich(a)redhat.com&gt; wrote: >> >>> It looks like the content.xml does not contain a reference to the >>> JBT core update site. My understanding is that core is a >>> prerequisite for IS (i.e. how could a user point a fresh Juno >>> install at the update site if it doesn't also provide core JBT >>> plugins). >>> >>> ----- Original Message ----- >>>> Hey all, >>>> >>>> I've finally gotten around to publishing the release process for >>>> integration stack tooling on jboss.org. Please give it a read >>>> and >>>> let me know if you have any questions regarding the process. >>>> >>>> The process is designed to help us produce and aggregate update >>>> site >>>> for all integration tools. You may want to review the contents >>>> of >>>> the initial build to ensure the correct version (and features) >>>> for >>>> your component is correct. >>>> >>>> Here are the links: >>>> process - >>>> https://community.jboss.org/wiki/IntegrationToolingReleaseProcess >>>> build - >>>> http://download.jboss.org/jbosstools/updates/integration/juno/integration... >>>> source - >>>> https://github.com/jbosstools/jbosstools-integration-stack >>>> >>>> Please provide any comments, questions, concerns, critiques, >>>> etc. >>>> based on what you see. >>>> >>>> Special thanks to Paul for working hard to get all this setup. >>>> >>>> Best, >>>> Rob >>>> >>>> _______________________________________________ >>>> Soa-tools-list mailing list >>>> Soa-tools-list(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>

Bottom line, I'd recommend having your TP .target file [1], and your JBTIS aggregate pom.xml [2] point to a *specific JBT release* [3], rather than the "latest Juno compatible release" [4].

[1] https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... [2]https://github.com/jbosstools/jbosstools-integration-stack/blob/master/... [3] http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ [4] http://download.jboss.org/jbosstools/updates/stable/juno/ On 02/08/2013 06:31 PM, Rob Cernich wrote: > > > ----- Original Message ----- >>> Are you saying that because of the way JBoss Central and the >>> discovery mechanism works that this site needs to be free of any >>> other JBT artifacts, including repository references to those >>> sites? >> >> It's two parts: >> >> 1) yes, jboss central/discovery mechanism to avoid some mismatch in >> jboss tools versions. >> >> 2) even without #1 if JBITS main release site points to specific JBT >> version (i.e. juno/4.0.0.Final instead of juno/) p2 will keep >> getting these sites added and p2 will get slower and harder to keep >> stable for users (and us). >> >> If JBTIS main site would just point to the main JBT release site it >> would *probably* be fine but not sure how it affects builds. (I hate >> p2's slowness ;) > > I was thinking it would just point to ...updates/stable/juno, that way it would pick up whatever the latest was. Not sure about builds; I don't know the implications. > >> >>> My understand, from the wording on the update site, is that I can >>> take a plain old Eclipse Juno install, point it at this site and >>> install. However, looking at the contents, it does not have any >>> way of resolving core JBT artifacts that might be required by any >>> of the integration features. >>> >>> We either need to change the text of the site to say start with a >>> JBT x.y install or include a repository reference to the JBT >>> update site. I'm OK with either. >> >> Simplest for now would be to update the text. >> >> /max >> >>> >>> Best, >>> Rob >>> >>> ----- Original Message ----- >>>> Wouldn't that have to be another site since this site is what >>>> JBoss >>>> central would point to. >>>> >>>> /max (sent from my phone) >>>> >>>> >>>> On 07/02/2013, at 17.44, Rob Cernich <rcernich(a)redhat.com&gt; wrote: >>>> >>>>> It looks like the content.xml does not contain a reference to the >>>>> JBT core update site. My understanding is that core is a >>>>> prerequisite for IS (i.e. how could a user point a fresh Juno >>>>> install at the update site if it doesn't also provide core JBT >>>>> plugins). >>>>> >>>>> ----- Original Message ----- >>>>>> Hey all, >>>>>> >>>>>> I've finally gotten around to publishing the release process for >>>>>> integration stack tooling on jboss.org. Please give it a read >>>>>> and >>>>>> let me know if you have any questions regarding the process. >>>>>> >>>>>> The process is designed to help us produce and aggregate update >>>>>> site >>>>>> for all integration tools. You may want to review the contents >>>>>> of >>>>>> the initial build to ensure the correct version (and features) >>>>>> for >>>>>> your component is correct. >>>>>> >>>>>> Here are the links: >>>>>> process - >>>>>> https://community.jboss.org/wiki/IntegrationToolingReleaseProcess >>>>>> build - >>>>>> http://download.jboss.org/jbosstools/updates/integration/juno/integration... >>>>>> source - >>>>>> https://github.com/jbosstools/jbosstools-integration-stack >>>>>> >>>>>> Please provide any comments, questions, concerns, critiques, >>>>>> etc. >>>>>> based on what you see. >>>>>> >>>>>> Special thanks to Paul for working hard to get all this setup. >>>>>> >>>>>> Best, >>>>>> Rob >>>>>> >>>>>> _______________________________________________ >>>>>> Soa-tools-list mailing list >>>>>> Soa-tools-list(a)redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >> >> > > _______________________________________________ > Soa-tools-list mailing list > Soa-tools-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/soa-tools-list > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

Upon further reflection, a better approach might be, for the four usecases: 1. Target Platform [1]: use specific release [3] so that if regenerated it won't change or break as IUs on the composite site [4] change. Means every time you rebuild it, the contents will be the same. To update it to a new version you have to explicitly bump the included URLs to new a new value. 2. Building JBTIS aggregate (and JBTIS component projects): use minimum target platform built based on [3] (which will stay locked to JBT 4.0.0) 3. Testing JBTIS aggregate (and JBTIS component projects): use *maximum* target platform built based on [4] (which will soon include JBT 4.0.1, then 4.0.2, etc.) 4. Installing JBTIS: aggregate site's <references> [2] point to latest release (composite site) [4]. User only ever sees [4] in his Eclipse, (although there's a good chance even that will be hidden). --- [1] https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... [2] https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... [3] http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ [4] http://download.jboss.org/jbosstools/updates/stable/juno/ --- Max, does that make more sense? N On 02/09/2013 01:01 AM, Max Rydahl Andersen wrote: > >> Bottom line, I'd recommend having your TP .target file [1], and >> your JBTIS aggregate pom.xml [2] point to a *specific JBT >> release* [3], rather than the "latest Juno compatible release" >> [4]. > > Why ? > > Won't this make the p2 list grow of internal list of p2 sites for > every update ? > > We' ve done so much in the past to avoid this for having > overlapping p2 site content or am I missing something here that > prevent this from happening in this case ? > > /max > >> >> [1] >> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... >> >> [2]https://github.com/jbosstools/jbosstools-integration-stack/blob/master/... >> >> [3] >> http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ >> >> [4] http://download.jboss.org/jbosstools/updates/stable/juno/ >> >> On 02/08/2013 06:31 PM, Rob Cernich wrote: >>> >>> >>> ----- Original Message ----- >>>>> Are you saying that because of the way JBoss Central and the >>>>> discovery mechanism works that this site needs to be free of >>>>> any >>>>> other JBT artifacts, including repository references to those >>>>> sites? >>>> >>>> It's two parts: >>>> >>>> 1) yes, jboss central/discovery mechanism to avoid some mismatch >>>> in >>>> jboss tools versions. >>>> >>>> 2) even without #1 if JBITS main release site points to specific >>>> JBT >>>> version (i.e. juno/4.0.0.Final instead of juno/) p2 will keep >>>> getting these sites added and p2 will get slower and harder to >>>> keep >>>> stable for users (and us). >>>> >>>> If JBTIS main site would just point to the main JBT release site >>>> it >>>> would *probably* be fine but not sure how it affects builds. (I >>>> hate >>>> p2's slowness ;) >>> >>> I was thinking it would just point to ...updates/stable/juno, >>> that way it would pick up whatever the latest was. Not sure >>> about builds; I don't know the implications. >>> >>>> >>>>> My understand, from the wording on the update site, is that I >>>>> can >>>>> take a plain old Eclipse Juno install, point it at this site >>>>> and >>>>> install. However, looking at the contents, it does not have >>>>> any >>>>> way of resolving core JBT artifacts that might be required by >>>>> any >>>>> of the integration features. >>>>> >>>>> We either need to change the text of the site to say start with >>>>> a >>>>> JBT x.y install or include a repository reference to the JBT >>>>> update site. I'm OK with either. >>>> >>>> Simplest for now would be to update the text. >>>> >>>> /max >>>> >>>>> >>>>> Best, >>>>> Rob >>>>> >>>>> ----- Original Message ----- >>>>>> Wouldn't that have to be another site since this site is what >>>>>> JBoss >>>>>> central would point to. >>>>>> >>>>>> /max (sent from my phone) >>>>>> >>>>>> >>>>>> On 07/02/2013, at 17.44, Rob Cernich <rcernich(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> It looks like the content.xml does not contain a reference to >>>>>>> the >>>>>>> JBT core update site. My understanding is that core is a >>>>>>> prerequisite for IS (i.e. how could a user point a fresh Juno >>>>>>> install at the update site if it doesn't also provide core >>>>>>> JBT >>>>>>> plugins). >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Hey all, >>>>>>>> >>>>>>>> I've finally gotten around to publishing the release process >>>>>>>> for >>>>>>>> integration stack tooling on jboss.org. Please give it a >>>>>>>> read >>>>>>>> and >>>>>>>> let me know if you have any questions regarding the process. >>>>>>>> >>>>>>>> The process is designed to help us produce and aggregate >>>>>>>> update >>>>>>>> site >>>>>>>> for all integration tools. You may want to review the >>>>>>>> contents >>>>>>>> of >>>>>>>> the initial build to ensure the correct version (and >>>>>>>> features) >>>>>>>> for >>>>>>>> your component is correct. >>>>>>>> >>>>>>>> Here are the links: >>>>>>>> process - >>>>>>>> https://community.jboss.org/wiki/IntegrationToolingReleaseProcess >>>>>>>> build - >>>>>>>> http://download.jboss.org/jbosstools/updates/integration/juno/integration... >>>>>>>> source - >>>>>>>> https://github.com/jbosstools/jbosstools-integration-stack >>>>>>>> >>>>>>>> Please provide any comments, questions, concerns, critiques, >>>>>>>> etc. >>>>>>>> based on what you see. >>>>>>>> >>>>>>>> Special thanks to Paul for working hard to get all this >>>>>>>> setup. >>>>>>>> >>>>>>>> Best, >>>>>>>> Rob >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Soa-tools-list mailing list >>>>>>>> Soa-tools-list(a)redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>>>> _______________________________________________ >>>>>>> jbosstools-dev mailing list >>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Soa-tools-list mailing list >>> Soa-tools-list(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>> >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> >> > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

Agreed - this also separates nicely the "build time" and "user-install time" concern. At build time we wan't specific versions, and at user time we keep using stable url [4] Only downside I can think of and i'm not sure if that is just an imaginary issue is that by having aggregate site reference [4] it is not possible to test the aggregate together with some other JBoss Tools site since it will just go resolve against [4]. If that is needed would need to use the composite for such testing. /max > I like it. We'll include [4] as a repository reference in the JBTIS aggregate and the TP will continue to include a specific JBT version, e.g. [3]. Once we get some testing integrated into the aggregate build, we'll address that appropriately. > > Thanks Nick! > > ----- Original Message ----- >> Upon further reflection, a better approach might be, for the four >> usecases: >> >> 1. Target Platform [1]: use specific release [3] so that if >> regenerated >> it won't change or break as IUs on the composite site [4] change. >> Means >> every time you rebuild it, the contents will be the same. To update >> it >> to a new version you have to explicitly bump the included URLs to new >> a >> new value. >> >> 2. Building JBTIS aggregate (and JBTIS component projects): use >> minimum >> target platform built based on [3] (which will stay locked to JBT >> 4.0.0) >> >> 3. Testing JBTIS aggregate (and JBTIS component projects): use >> *maximum* >> target platform built based on [4] (which will soon include JBT >> 4.0.1, >> then 4.0.2, etc.) >> >> 4. Installing JBTIS: aggregate site's <references> [2] point to >> latest >> release (composite site) [4]. User only ever sees [4] in his Eclipse, >> (although there's a good chance even that will be hidden). >> >> --- >> >> [1] >> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... >> >> [2] >> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... >> >> [3] >> http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ >> >> [4] http://download.jboss.org/jbosstools/updates/stable/juno/ >> >> --- >> >> Max, does that make more sense? >> >> N >> >> On 02/09/2013 01:01 AM, Max Rydahl Andersen wrote: >>> >>>> Bottom line, I'd recommend having your TP .target file [1], and >>>> your JBTIS aggregate pom.xml [2] point to a *specific JBT >>>> release* [3], rather than the "latest Juno compatible release" >>>> [4]. >>> >>> Why ? >>> >>> Won't this make the p2 list grow of internal list of p2 sites for >>> every update ? >>> >>> We' ve done so much in the past to avoid this for having >>> overlapping p2 site content or am I missing something here that >>> prevent this from happening in this case ? >>> >>> /max >>> >>>> >>>> [1] >>>> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... >>>> >>>> [2]https://github.com/jbosstools/jbosstools-integration-stack/blob/master/... >>>> >>>> [3] >>>> http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ >>>> >>>> [4] http://download.jboss.org/jbosstools/updates/stable/juno/ >>>> >>>> On 02/08/2013 06:31 PM, Rob Cernich wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>>> Are you saying that because of the way JBoss Central and the >>>>>>> discovery mechanism works that this site needs to be free of >>>>>>> any >>>>>>> other JBT artifacts, including repository references to those >>>>>>> sites? >>>>>> >>>>>> It's two parts: >>>>>> >>>>>> 1) yes, jboss central/discovery mechanism to avoid some mismatch >>>>>> in >>>>>> jboss tools versions. >>>>>> >>>>>> 2) even without #1 if JBITS main release site points to specific >>>>>> JBT >>>>>> version (i.e. juno/4.0.0.Final instead of juno/) p2 will keep >>>>>> getting these sites added and p2 will get slower and harder to >>>>>> keep >>>>>> stable for users (and us). >>>>>> >>>>>> If JBTIS main site would just point to the main JBT release site >>>>>> it >>>>>> would *probably* be fine but not sure how it affects builds. (I >>>>>> hate >>>>>> p2's slowness ;) >>>>> >>>>> I was thinking it would just point to ...updates/stable/juno, >>>>> that way it would pick up whatever the latest was. Not sure >>>>> about builds; I don't know the implications. >>>>> >>>>>> >>>>>>> My understand, from the wording on the update site, is that I >>>>>>> can >>>>>>> take a plain old Eclipse Juno install, point it at this site >>>>>>> and >>>>>>> install. However, looking at the contents, it does not have >>>>>>> any >>>>>>> way of resolving core JBT artifacts that might be required by >>>>>>> any >>>>>>> of the integration features. >>>>>>> >>>>>>> We either need to change the text of the site to say start with >>>>>>> a >>>>>>> JBT x.y install or include a repository reference to the JBT >>>>>>> update site. I'm OK with either. >>>>>> >>>>>> Simplest for now would be to update the text. >>>>>> >>>>>> /max >>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Rob >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Wouldn't that have to be another site since this site is what >>>>>>>> JBoss >>>>>>>> central would point to. >>>>>>>> >>>>>>>> /max (sent from my phone) >>>>>>>> >>>>>>>> >>>>>>>> On 07/02/2013, at 17.44, Rob Cernich <rcernich(a)redhat.com&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> It looks like the content.xml does not contain a reference to >>>>>>>>> the >>>>>>>>> JBT core update site. My understanding is that core is a >>>>>>>>> prerequisite for IS (i.e. how could a user point a fresh Juno >>>>>>>>> install at the update site if it doesn't also provide core >>>>>>>>> JBT >>>>>>>>> plugins). >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> Hey all, >>>>>>>>>> >>>>>>>>>> I've finally gotten around to publishing the release process >>>>>>>>>> for >>>>>>>>>> integration stack tooling on jboss.org. Please give it a >>>>>>>>>> read >>>>>>>>>> and >>>>>>>>>> let me know if you have any questions regarding the process. >>>>>>>>>> >>>>>>>>>> The process is designed to help us produce and aggregate >>>>>>>>>> update >>>>>>>>>> site >>>>>>>>>> for all integration tools. You may want to review the >>>>>>>>>> contents >>>>>>>>>> of >>>>>>>>>> the initial build to ensure the correct version (and >>>>>>>>>> features) >>>>>>>>>> for >>>>>>>>>> your component is correct. >>>>>>>>>> >>>>>>>>>> Here are the links: >>>>>>>>>> process - >>>>>>>>>> https://community.jboss.org/wiki/IntegrationToolingReleaseProcess >>>>>>>>>> build - >>>>>>>>>> http://download.jboss.org/jbosstools/updates/integration/juno/integration... >>>>>>>>>> source - >>>>>>>>>> https://github.com/jbosstools/jbosstools-integration-stack >>>>>>>>>> >>>>>>>>>> Please provide any comments, questions, concerns, critiques, >>>>>>>>>> etc. >>>>>>>>>> based on what you see. >>>>>>>>>> >>>>>>>>>> Special thanks to Paul for working hard to get all this >>>>>>>>>> setup. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Rob >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Soa-tools-list mailing list >>>>>>>>>> Soa-tools-list(a)redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>>>>>> _______________________________________________ >>>>>>>>> jbosstools-dev mailing list >>>>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Soa-tools-list mailing list >>>>> Soa-tools-list(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>> >>>> >>>> -- >>>> Nick Boldt :: JBoss by Red Hat >>>> Productization Lead :: JBoss Tools & Dev Studio >>>> http://nick.divbyzero.com >>>> >>>> >>> >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> >> >>

> Not an imaginary concern -- in fact that was my original reason for > wanting to embed the URL of a specific (older) JBT release [3] > rather than the URL of the latest JBT release [4]. If it still embed a specific release then you have the same problem - it is not possible to test the site against another specific site. > But then you said that was less important than the negative > cosmetic effect of seeing multiple JBT update site URLs (4.0.0, > 4.0.1, 4.0.2 vs. just juno/stable) in the user's Help > > Preferences > Install/Update > Available Software Sites. Yes, and I hope you see the same too since this is why you spent so much time on vet the p2 mirror sites which polluted users eclipse p2 install UI. Remember ? :) btw. I think we are mixing up two concerns here: 1) How we and QE test JBTIS site 2) How our jboss tools/jbds users *use* our site. In #1 it is often important we got the exact site pointed to to get the right combination, but with #2 it is assumed things work and here what becomes important is we don't add version specific site to the list of updatesite the user sees/we have to maintain. > We can of course set up install tests that will: > > a) unpack eclipse > b) install JBT (specific version) > c) install JBTIS (specific version) > > That will ensure that: > > * JBTIS can be installed against a specific older version of JBT I'm curious - which site + command would you run to test this ? Using aggregate with linked sites would mean you can't control the specific version of lets say JBT since it would get the content from the linked site if the site being tested contains older/different versions. > AND > * JBTIS can also magically update the version of JBT installed to > the latest at the same time. Not following what this means besides if JBTIS points to the stable JBT core url they will get updates from it if present - just like if they started with just jboss tools first ? /max > https://issues.jboss.org/browse/JBTIS-15 > > N > > On 02/11/2013 08:17 AM, Max Rydahl Andersen wrote: >> Agreed - this also separates nicely the "build time" and >> "user-install time" concern. At build time we wan't specific >> versions, and at user time we keep using stable url [4] >> >> Only downside I can think of and i'm not sure if that is just an >> imaginary issue is that by having aggregate site reference [4] it >> is not possible to test the aggregate together with some other >> JBoss Tools site since it will just go resolve against [4]. If >> that is needed would need to use the composite for such testing. >> >> /max >> >>> I like it. We'll include [4] as a repository reference in the >>> JBTIS aggregate and the TP will continue to include a specific >>> JBT version, e.g. [3]. Once we get some testing integrated into >>> the aggregate build, we'll address that appropriately. >>> >>> Thanks Nick! >>> >>> ----- Original Message ----- >>>> Upon further reflection, a better approach might be, for the >>>> four >>>> usecases: >>>> >>>> 1. Target Platform [1]: use specific release [3] so that if >>>> regenerated >>>> it won't change or break as IUs on the composite site [4] >>>> change. >>>> Means >>>> every time you rebuild it, the contents will be the same. To >>>> update >>>> it >>>> to a new version you have to explicitly bump the included URLs >>>> to new >>>> a >>>> new value. >>>> >>>> 2. Building JBTIS aggregate (and JBTIS component projects): use >>>> minimum >>>> target platform built based on [3] (which will stay locked to >>>> JBT >>>> 4.0.0) >>>> >>>> 3. Testing JBTIS aggregate (and JBTIS component projects): use >>>> *maximum* >>>> target platform built based on [4] (which will soon include JBT >>>> 4.0.1, >>>> then 4.0.2, etc.) >>>> >>>> 4. Installing JBTIS: aggregate site's <references> [2] point to >>>> latest >>>> release (composite site) [4]. User only ever sees [4] in his >>>> Eclipse, >>>> (although there's a good chance even that will be hidden). >>>> >>>> --- >>>> >>>> [1] >>>> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... >>>> >>>> [2] >>>> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... >>>> >>>> [3] >>>> http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ >>>> >>>> [4] http://download.jboss.org/jbosstools/updates/stable/juno/ >>>> >>>> --- >>>> >>>> Max, does that make more sense? >>>> >>>> N >>>> >>>> On 02/09/2013 01:01 AM, Max Rydahl Andersen wrote: >>>>> >>>>>> Bottom line, I'd recommend having your TP .target file [1], >>>>>> and >>>>>> your JBTIS aggregate pom.xml [2] point to a *specific JBT >>>>>> release* [3], rather than the "latest Juno compatible release" >>>>>> [4]. >>>>> >>>>> Why ? >>>>> >>>>> Won't this make the p2 list grow of internal list of p2 sites >>>>> for >>>>> every update ? >>>>> >>>>> We' ve done so much in the past to avoid this for having >>>>> overlapping p2 site content or am I missing something here that >>>>> prevent this from happening in this case ? >>>>> >>>>> /max >>>>> >>>>>> >>>>>> [1] >>>>>> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... >>>>>> >>>>>> [2]https://github.com/jbosstools/jbosstools-integration-stack/blob/master/... >>>>>> >>>>>> [3] >>>>>> http://download.jboss.org/jbosstools/updates/JBossTools-4.0.0.Final.core/ >>>>>> >>>>>> [4] http://download.jboss.org/jbosstools/updates/stable/juno/ >>>>>> >>>>>> On 02/08/2013 06:31 PM, Rob Cernich wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>>> Are you saying that because of the way JBoss Central and >>>>>>>>> the >>>>>>>>> discovery mechanism works that this site needs to be free >>>>>>>>> of >>>>>>>>> any >>>>>>>>> other JBT artifacts, including repository references to >>>>>>>>> those >>>>>>>>> sites? >>>>>>>> >>>>>>>> It's two parts: >>>>>>>> >>>>>>>> 1) yes, jboss central/discovery mechanism to avoid some >>>>>>>> mismatch >>>>>>>> in >>>>>>>> jboss tools versions. >>>>>>>> >>>>>>>> 2) even without #1 if JBITS main release site points to >>>>>>>> specific >>>>>>>> JBT >>>>>>>> version (i.e. juno/4.0.0.Final instead of juno/) p2 will >>>>>>>> keep >>>>>>>> getting these sites added and p2 will get slower and harder >>>>>>>> to >>>>>>>> keep >>>>>>>> stable for users (and us). >>>>>>>> >>>>>>>> If JBTIS main site would just point to the main JBT release >>>>>>>> site >>>>>>>> it >>>>>>>> would *probably* be fine but not sure how it affects builds. >>>>>>>> (I >>>>>>>> hate >>>>>>>> p2's slowness ;) >>>>>>> >>>>>>> I was thinking it would just point to ...updates/stable/juno, >>>>>>> that way it would pick up whatever the latest was. Not sure >>>>>>> about builds; I don't know the implications. >>>>>>> >>>>>>>> >>>>>>>>> My understand, from the wording on the update site, is that >>>>>>>>> I >>>>>>>>> can >>>>>>>>> take a plain old Eclipse Juno install, point it at this >>>>>>>>> site >>>>>>>>> and >>>>>>>>> install. However, looking at the contents, it does not >>>>>>>>> have >>>>>>>>> any >>>>>>>>> way of resolving core JBT artifacts that might be required >>>>>>>>> by >>>>>>>>> any >>>>>>>>> of the integration features. >>>>>>>>> >>>>>>>>> We either need to change the text of the site to say start >>>>>>>>> with >>>>>>>>> a >>>>>>>>> JBT x.y install or include a repository reference to the >>>>>>>>> JBT >>>>>>>>> update site. I'm OK with either. >>>>>>>> >>>>>>>> Simplest for now would be to update the text. >>>>>>>> >>>>>>>> /max >>>>>>>> >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Rob >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> Wouldn't that have to be another site since this site is >>>>>>>>>> what >>>>>>>>>> JBoss >>>>>>>>>> central would point to. >>>>>>>>>> >>>>>>>>>> /max (sent from my phone) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/02/2013, at 17.44, Rob Cernich <rcernich(a)redhat.com&gt; >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> It looks like the content.xml does not contain a >>>>>>>>>>> reference to >>>>>>>>>>> the >>>>>>>>>>> JBT core update site. My understanding is that core is a >>>>>>>>>>> prerequisite for IS (i.e. how could a user point a fresh >>>>>>>>>>> Juno >>>>>>>>>>> install at the update site if it doesn't also provide >>>>>>>>>>> core >>>>>>>>>>> JBT >>>>>>>>>>> plugins). >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> Hey all, >>>>>>>>>>>> >>>>>>>>>>>> I've finally gotten around to publishing the release >>>>>>>>>>>> process >>>>>>>>>>>> for >>>>>>>>>>>> integration stack tooling on jboss.org. Please give it >>>>>>>>>>>> a >>>>>>>>>>>> read >>>>>>>>>>>> and >>>>>>>>>>>> let me know if you have any questions regarding the >>>>>>>>>>>> process. >>>>>>>>>>>> >>>>>>>>>>>> The process is designed to help us produce and aggregate >>>>>>>>>>>> update >>>>>>>>>>>> site >>>>>>>>>>>> for all integration tools. You may want to review the >>>>>>>>>>>> contents >>>>>>>>>>>> of >>>>>>>>>>>> the initial build to ensure the correct version (and >>>>>>>>>>>> features) >>>>>>>>>>>> for >>>>>>>>>>>> your component is correct. >>>>>>>>>>>> >>>>>>>>>>>> Here are the links: >>>>>>>>>>>> process - >>>>>>>>>>>> https://community.jboss.org/wiki/IntegrationToolingReleaseProcess >>>>>>>>>>>> build - >>>>>>>>>>>> http://download.jboss.org/jbosstools/updates/integration/juno/integration... >>>>>>>>>>>> source - >>>>>>>>>>>> https://github.com/jbosstools/jbosstools-integration-stack >>>>>>>>>>>> >>>>>>>>>>>> Please provide any comments, questions, concerns, >>>>>>>>>>>> critiques, >>>>>>>>>>>> etc. >>>>>>>>>>>> based on what you see. >>>>>>>>>>>> >>>>>>>>>>>> Special thanks to Paul for working hard to get all this >>>>>>>>>>>> setup. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Rob >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Soa-tools-list mailing list >>>>>>>>>>>> Soa-tools-list(a)redhat.com >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jbosstools-dev mailing list >>>>>>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Soa-tools-list mailing list >>>>>>> Soa-tools-list(a)redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>>>> >>>>>> >>>>>> -- >>>>>> Nick Boldt :: JBoss by Red Hat >>>>>> Productization Lead :: JBoss Tools & Dev Studio >>>>>> http://nick.divbyzero.com >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Nick Boldt :: JBoss by Red Hat >>>> Productization Lead :: JBoss Tools & Dev Studio >>>> http://nick.divbyzero.com >>>> >>>> >>>> >> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > >