Re: [jbosstools-dev] [Soa-tools-list] JBoss Tools Integration Stack Release Process

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