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

[Nick Boldt]

If you build against updates/stable/juno (that is, it's in your TP [1]) 
then there should be no problem pointing to that from the pom that 
builds the aggregate site [2] (so that the site's content.xml contains 
<references> to that site.

Alternatively, you could point to a SPECIFIC JBT release [3] so that 
rather than building against one version and referencing a different 
one, you'd use the *same URL* in both cases: the TP (at build time) and 
the site's content.xml's <references> (at install time).

Using the specific version (eg., JBT 4.0.0.Final) would not prevent a 
user from subsequently trying to upgrade their Eclipse install to 
include JBT 4.0.1.Final (once we release that) but it will guarantee 
installation should proceed as the devs/QE intend. (This is why we 
stopped depending on Eclipse's latest released simultaneous release site 
in favour of SPECIFIC mirrors on download.jboss.org.)

AND, should there be a reason (however unlikely) to *prevent* upgrading 
from [Eclipse 4.2.1 + JBT 4.0.0.Final + JBTIS 4.0.0.Final] to [Eclipse 
4.2.2 + JBT 4.0.1.Final + JBTIS 4.0.0.Final], the JBTIS features/plugins 
can set the correct upper bounds on their requirements/dependencies to 
prevent such an upgrade.

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

[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