> Now, back to the reason why we have them as TP entries as opposed to > 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 jboss.org downloads page, it shouldn't be an issue where it comes from.

Just because a developer is using a TP doesn't mean they can't add other repositories to their projects.

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.

> b) it is to ensure we are not just using the "master"/nightly builds > of > external dependencies Same comment as above, just because it's in the TP doesn't mean projects can't circumvent it.

> > c) it is to ensure we do not drag in transitive dependencies from > eclipse.org component updatesites which (at least in the past) have > had > 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 > track 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.)

> e) finally it is there to ensure we don't see a drift in multiple > modules adding different versions into their dependency/build chain. > (For core that is less likely since we have jbosstools parent pom to > at > least centralize where the various updatesites are located, but jbtis > is > 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 artifacts).

> So that is the reasons...now ...does the bpmn2 and bpel parts receive > 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.

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 > visible > ? 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.

> > /max > > >> >> ----- Original Message ----- >>> >>> +1! >>> >>> 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 >>> modeler >>> from the JBTIS TP?? >>> >>> --paull >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Rob Cernich" <rcernich(a)redhat.com&gt; >>>> To: "soa-tools-list" <soa-tools-list(a)redhat.com&gt; >>>> 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 >>>> way >>>> we >>>> handle components that come from external sources. To me, it >>>> makes >>>> sense >>>> if >>>> we treat these components the same way we treat our internal >>>> components. >>>> If >>>> we were to do that, these components would no longer be part of >>>> the >>>> JBTIS >>>> 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 >>>> SwitchYard >>>> or >>>> 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 >>>> mechanism >>>> used to reference other internal component dependencies (e.g. >>>> SAVARA >>>> and >>>> SwitchYard). (SwitchYard actually references the BPMN2 repository >>>> directly >>>> specifically to avoid circularities within the tp/repo chain; i.e. >>>> SwitchYard does not require the TP be updated in order to update >>>> BPMN2 >>>> modeller). >>>> >>>> Just an idea. >>>> >>>> Rob >>>> >>>> _______________________________________________ >>>> Soa-tools-list mailing list >>>> Soa-tools-list(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>> >>> >> >> _______________________________________________ >> Soa-tools-list mailing list >> Soa-tools-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/soa-tools-list > > > /max > http://about.me/maxandersen > _______________________________________________ Soa-tools-list mailing list Soa-tools-list(a)redhat.com https://www.redhat.com/mailman/listinfo/soa-tools-list

> >> Now, back to the reason why we have them as TP entries as opposed to > >> 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 > > jboss.org downloads page, it shouldn't be an issue where it comes > > from. > > 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 can't add > > other repositories to their projects. > > Of course everyone can add anything - but we are talking about what we > prefer/recommend/require. > > > 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 provided bits. > > >> b) it is to ensure we are not just using the "master"/nightly builds > >> of > >> 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 > >> eclipse.org component updatesites which (at least in the past) have > >> had > >> 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 > >> track > > > > 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 (or > anything "external") is that the JBTIS TP should not be updated before > needed... > > also it should not have bumped it in the TP version used by all > projects. > > >> e) finally it is there to ensure we don't see a drift in multiple > >> modules adding different versions into their dependency/build chain. > >> (For core that is less likely since we have jbosstools parent pom to > >> at > >> least centralize where the various updatesites are located, but jbtis > >> is > >> 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 > > artifacts). > > 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 > aggregates > 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 receive > >> 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 > synchronzing dependencies. > > > 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 > >> visible > >> ? > > > > 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. > Actually, this was found during the site build, which is actually better, because there is no way of knowing whether or not various components have updated their poms to use the latest TP (which is probably why SY was removed from the distro: to get the site projects building again), so there is no real advantage to keeping this in the TP versus accessing the mirrored repo from the site projects. In either case, the artifacts in question are mirrored appropriately (they're either part of the TP repo or the JBTIS repo).

_______________________________________________ Soa-tools-list mailing list Soa-tools-list(a)redhat.com https://www.redhat.com/mailman/listinfo/soa-tools-list

> Actually, this was found during the site build, which is actually > better, > because there is no way of knowing whether or not various components > have > updated their poms to use the latest TP (which is probably why SY was > removed from the distro: to get the site projects building again), so > there > is no real advantage to keeping this in the TP versus accessing the > mirrored > repo from the site projects. In either case, the artifacts in > question are > mirrored appropriately (they're either part of the TP repo or the > JBTIS > repo). Actually, since we're providing a single TP repo for a platform, I think it actually makes more sense to include things like this in the JBTIS repo. If we need to roll versions in the future, that would mean updating the TP, which could break existing JBTIS repo's (because the latest TP has an incompatible version).