>Generally, users of specific components (e.g. TEIID), should
install the
>latest "release" using the JBTIS site. If those same users want to stay
up
>to date with the latest nightly or development version of that component,
>they should also add the update site for that specific component. This
>should work for all cases except where the nightly or dev version changes
>its dependencies in such a way that they cannot be fulfilled by JBTIS.
Yeah, I would prefer to avoid creating too many separate individual sites
cross-referencing each other causing a nice mess of p2 sites for users.
Paul, given that, can we update JBTIS to create a p2 site for the target platform that can
be published and referenced by the aggregate? Referencing the target platform site would
take the place of most of the associate sites listed in the site pom. I suspect you would
publish it up to something like .../integration-stack/target-platform/4.1.1. We would
need to ensure the target platform is tagged, published and promoted in the same way the
aggregate is. Keep in mind, we only need to publish the target platform site when the
integration-stack-base.target file changes. (Ping me on IRC if you want to discuss in
more detail.)
For bleeding edge users its fine, but for our "normal" users which tend to
use more than just *one* of our plugins having actual release of JBTIS is
crucial since it allow us to hand out an actual stable url that has a much
less likelyhood of problems.
p.s. one could argue that bleeding edge users should be okey adding
<teiid-component-site> + JBTIS-TP site for their bleeding edge testing.