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/ta...
[
2]https://github.com/jbosstools/jbosstools-integration-stack/blob/master/...
[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(a)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...
>>>>> 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(a)redhat.com
>>>>>
https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>
>
_______________________________________________
Soa-tools-list mailing list
Soa-tools-list(a)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