Re: [jbosstools-dev] [Soa-tools-list] JBTIS: Managment of External Components

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. Same comment as above, just because it's in the TP doesn't mean projects can't circumvent it. Same comment as above. 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.) 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). 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.) 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.