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

Nick Boldt nboldt at redhat.com
Mon Feb 11 12:19:58 EST 2013 

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