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

[Max Rydahl Andersen]

>> 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,

I assume you mean it was found in the site build of JBTIS because it was 
part of the TP and conflicted with SY's usage of IU names ?

> 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),

Unless if components would agree on having a uniform way of overriding 
the TP used for building - then it could be (more easily) be verified, 
i.e. Paul L. could run a build to verify without having to ping everyone 
to verify basic updates.

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

Also no advantage to have each components point to the site projects 
afaics - with TP its at least done consistently in one place.

 From my perspective the "glitch" this time around was an update to TP 
was done without a coordinated reason. I've suggested Paul to look at 
what we do recently on jboss tools core to make the reasons for TP 
changes more clear so we actually know from where the change request 
came - in this case it was not PM, but QE asking for updating the 
component and in the process it was forgotten other parts might be 
affected.

If just move it out of the TP then each component need to update their 
link for this "External" component when testing if the component causes 
any conflict for them.

Hence my suggestion is still to keep it in TP and actually coordinate 
the upgrades with a deadline to make the changes easier to react to and 
document if/when there are issues since each team are on so wildly 
different schedules.

WDYT?

/max
http://about.me/maxandersen