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

Mon Feb 11 08:17:57 EST 2013

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