[
https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi...
]
Mickael Istria commented on JBIDE-18742:
----------------------------------------
Note for the aggregation, because aggregator sometimes run against the same composite, so
no change happen.
But since the publication script is using rsync, the time it takes is linear with the
amount of content changed. So in case nothing has changed, rsync will end up doing mostly
nothing but comparing artifacts.
So in any case, we don't need a smarter comparator than rsync, that seems optimal for
the task of publishing a new aggregate
Only rely on rsync to publish new aggregate (remove other
comparators)
----------------------------------------------------------------------
Key: JBIDE-18742
URL:
https://issues.jboss.org/browse/JBIDE-18742
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: build
Reporter: Mickael Istria
Fix For: 4.3.0.Alpha1
Instead of the composite-install test to decide whether we aggregate or not, it would be
simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to
decide whether we want to publish the new composite or not.
It's more or less just a matter of scripting
{code:none}
p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/
http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\<
-e ^\> > p2diff_snapshot
if [[ -s p2diff_snapshot ]]; then
./publish.sh
fi
{code}
Another benefit is that it allows us to get rid of the composite (1 less couple of files
to maintain)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)