> Now, back to the reason why we have them as TP entries as opposed
> other components is a few:
> a) to make sure we have a download.jboss.org
mirror since eclipse
> mirrors are unreliable/slower (especially for people outside US)
Not sure how having this in the TP guarantees there is a mirror. If
developers are constrained to _only_ using dependencies located on a
downloads page, it shouldn't be an issue where it comes
Part of the TP steps we have is that the updatesite we take from get
mirrored. We don't refer to non-mirrored content - if we do thats a bug
Just because a developer is using a TP doesn't mean they
other repositories to their projects.
Of course everyone can add anything - but we are talking about what we
Furthermore, if a project depends on another component provided by
JBoss (e.g. SAVARA depends on SwitchYard), those projects aren't in
the TP and users must manage those dependencies themselves.
Yes - but for now lets focus on the eclipse.org
> b) it is to ensure we are not just using the
> external dependencies
Same comment as above, just because it's in the TP doesn't mean
projects can't circumvent it.
No, of course not. projects can also commit code that deletes all users
files when it is high noon - we try and trust where we can :)
> c) it is to ensure we do not drag in transitive dependencies from
component updatesites which (at least in the past) have
> lots of updatesite references to mix of p2 sites that resulted in
> duplicated dependencies and/or wrong/non-deterministic p2 resolution
> (because the updatessites
> was one of a or b)
Same comment as above.
> d) the eclipse.org
parts tend to participate in the eclipse release
> train - thus (for simplicity) using them via TP makes it easier to
One of the subtleties that I think you've missed is that the BPMN2
modeller is a feature provided by JBTIS and not simply a dependency
required by other features. By moving the version of the BPMN2
modeller forward, the JBTIS site project was broken as the dependency
set was not aligned. If the BPMN2 modeller feature were included as
part of the site project, instead of the TP project, everybody can
move forward in lock step. That said, you could also argue that the
site project shouldn't have been updated until _all_ projects were
ready, which did not occur in this case. (I'd be happy with this
solution as well.)
Yes, I believe if there is a dependency coming in from eclipse.org
anything "external") is that the JBTIS TP should not be updated before
also it should not have bumped it in the TP version used by all
> e) finally it is there to ensure we don't see a drift in
> modules adding different versions into their dependency/build chain.
> (For core that is less likely since we have jbosstools parent pom to
> least centralize where the various updatesites are located, but jbtis
> much more spread out...hence a TP seem more relevant?)
I don't think this is a problem since this is all included via the
JBTIS site build. There is no way different dependency chains will be
injected since the individual project sites should not be including
references to other sites. My understanding is that we prune this
info when we create our mirrored sites, so we shouldn't be picking up
anything extra when we build our product sites. That said, if this is
not the case, then it pretty much has to be in the TP to keep from
polluting the product site (although, I think Nick has some special
magic that prunes repository references from the generated site
Yeah, the main "extra validation" we get by having thngs in TP is that
the compilation at project level will fail early where as if JBTIS just
it will not necessarily see any errors unless you actually run a 100%
coverage test on it.
> So that is the reasons...now ...does the bpmn2 and bpel parts
> many active updates that makes it non-feasible just including updates
> via the "normal" TP update process ?
That I can't answer, but I suspect the reason the BPMN2 modeller was
bumped without proper coordination was because somebody in product
management was asking for it.
Yeah but product management requests should not void the process of
The Eclipse BPMN2 modeller is part of our product suite, so I would
expect that it's lifecycle will fall in line with our product
lifecycles, meaning it will be treated similarly to JBoss provided
features, which is another reason to treat it as a we treat JBoss
components. (This is pure speculation, by the way.)
> ..and/or are there some hidden burdens in this that might not be
I don't think there's anything hidden here. SwitchYard has been
specifying a repository for BPMN2 modeller since we started requiring
it. This allows us to bump the version before it gets bumped in
JBTIS, allowing both to move forward in tandem when everybody is ready
to do so. We're actually doing this now, since we started working on
the update prior to the TP being updated, and it's working just fine.
Yes, you can always add a custom repo in for doing development work -
but once you can start relying on more coordinated TP content this seem
to be a better option.
btw. I actually think for JBoss Tools we could more safely use this
approach (Since we compile/build all projects and have conventions for
repo references so can override in the build to get API
incompatibilities to fail build quickly) - for JBTIS where there is no
such step I feel sharing TP would be a safer approach (since if things
goes bad they are found...like this where a dependency was updated that
did not match what you expected).
If it had not been in the TP this mismatch could have been hidden for a
while - and only be discovered late.
>> ----- Original Message -----
>>> reducing the TP complexity is certainly a good idea - can we get a
>>> show of
>>> virtual hands who in IS component land actually pulls the BPMN2
>>> from the JBTIS TP??
>>> ----- Original Message -----
>>>> From: "Rob Cernich" <rcernich(a)redhat.com>
>>>> To: "soa-tools-list" <soa-tools-list(a)redhat.com>
>>>> Sent: Wednesday, August 27, 2014 3:13:31 PM
>>>> Subject: [Soa-tools-list] JBTIS: Managment of External Components
>>>> Hey all,
>>>> The recent update of BPMN2 modeller caused me to think about the
>>>> handle components that come from external sources. To me, it
>>>> we treat these components the same way we treat our internal
>>>> we were to do that, these components would no longer be part of
>>>> target platform and would instead be part of the features list
>>>> described in
>>>> the jbosstools and devstudio modules.
>>>> In my opinion, this is a better way to treat these types of
>>>> dependencies as
>>>> they are components in their own right (i.e. no different than
>>>> Teiid, e.g.). If they are also dependencies used by other
>>>> components, they
>>>> would need to be managed by those other components using the same
>>>> used to reference other internal component dependencies (e.g.
>>>> SwitchYard). (SwitchYard actually references the BPMN2 repository
>>>> specifically to avoid circularities within the tp/repo chain; i.e.
>>>> SwitchYard does not require the TP be updated in order to update
>>>> Just an idea.
>>>> Soa-tools-list mailing list
>> Soa-tools-list mailing list
Soa-tools-list mailing list