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

Max Rydahl Andersen max.andersen at redhat.com
Mon Feb 11 12:36:02 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].

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