Re: [jbosstools-dev] [Soa-tools-list] JBTIS: Managment of External Components
> 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