[jbosstools-dev] [Soa-tools-list] JBoss Tools Integration Stack Release Process
Rob Cernich
rcernich at redhat.com
Mon Feb 11 12:46:13 EST 2013
Hey guys,
For automated testing, we can setup the target platform to use specific bits, e.g. base JBTIS TP (specifies JBT and other third-party dependencies) plus specific JBTIS artifacts.
For QA, they could install a specific version of JBT first, then add-on JBTIS. Worst case, QA would have to verify their install configuration to make sure no updates to JBT were performed when installing JBTIS artifacts. This should be easy to verify by diff'ing the entries in the configuration history.
Best,
Rob
----- Original Message -----
>
> > 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/target-platform/integration-tools.target#L123
> >>>>
> >>>> [2]
> >>>> https://github.com/jbosstools/jbosstools-integration-stack/blob/master/aggregate-site/pom.xml#L209
> >>>>
> >>>> [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/target-platform/integration-tools.target#L123
> >>>>>>
> >>>>>> [2]https://github.com/jbosstools/jbosstools-integration-stack/blob/master/aggregate-site/pom.xml#L209
> >>>>>>
> >>>>>> [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 at redhat.com>
> >>>>>>>>>> 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-stack/aggregate/4.0.0/
> >>>>>>>>>>>> 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 at redhat.com
> >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> jbosstools-dev mailing list
> >>>>>>>>>>> jbosstools-dev at lists.jboss.org
> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Soa-tools-list mailing list
> >>>>>>> Soa-tools-list at 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
> >
> >
>
>
More information about the jbosstools-dev
mailing list