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

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

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.

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

AND * JBTIS can also magically update the version of JBT installed to the latest at the same time.

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