[ https://issues.jboss.org/browse/JBIDE-17210?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-17210: ------------------------------------ If the aggregate builds frequently, people like Denis complain it moves too fast and builds that depend on it break. But now that builds depend on specific components instead of an upstream aggregation (or composite), the only build affected by frequent changes to the JBT aggregate in master is the JBDS build (which depends on it for its content). Meanwhile, frequent builds also trigger complaints from other Jenkins users because we're tying up resources and just respinning content for no reason. So... ages ago I implemented a bit of logic that says "check the upstream composite site; if content has changed there, we need a new aggregate. If not, don't rebuild the aggregate." This logic is here: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... HOWEVER... when the composite install test fails, it won't report correctly if the site contents are the same or not; in fact, it simply refrains from kicking the downstream aggregation, and the result is the JBT nightly master branch update site aggregate is horribly out of date. The reason for the failure is logged and simple enough to fix: {code} [p2.dir] !MESSAGE The installable unit org.jboss.tools.gwt.feature.feature.group has not been found. {code} Basically, we 're trying to install a feature that no longer exists in the composite, and p2 director doesn't take too kindly to that sort of shenanigan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira