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

Rob Cernich rcernich at redhat.com
Sun Feb 10 20:31:46 EST 2013


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


More information about the jbosstools-dev mailing list