<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/21/2013 10:32 AM, Mickael Istria
wrote:<br>
</div>
<blockquote cite="mid:519BAFC0.1000408@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 05/21/2013 06:56 PM, Denis Golovin
wrote:<br>
</div>
<blockquote cite="mid:519BA73C.6040201@exadel.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">The problem is
org.jboss.tools.tests is not part of <br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true"
href="http://download.jboss.org/jbosstools/updates/nightly/core/trunk/plugins/">http://download.jboss.org/jbosstools/updates/nightly/core/trunk/plugins/</a><br>
</div>
</blockquote>
That's right. However it's part of <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://download.jboss.org/jbosstools/updates/nightly/integrationtests/trunk">http://download.jboss.org/jbosstools/updates/nightly/integrationtests/trunk</a>
site, so when enabling no profile, the default nightly sites (core
and integration tests) are used, so it should resolve this bundle.<br>
Is this something you can reproduce at every build? It could
happen when your build tries to get content at the same time
aggregation is getting published.<br>
</blockquote>
<br>
Pushing process can be implemented different way to avoid this
issue, I saw it many times and it is a bit annoying. I remember we
spend some time with Nick to tackle it, but problem seems still
here.<br>
<br>
Idea behind this fix is really simple:<br>
1. Leave old published bits as is on the server side and just upload
new ones<br>
2. Update compositeArtifacts.xml first and include uploaded update
site from step 1<br>
3. Update compositeContent.xml: include new uploaded update site
from step 1 and remove oldest one<br>
4. Update compositeArtifacts.xml and remove oldest one<br>
5. Remove oldest update site folder<br>
<br>
Note there are no operations related to renaming/moving previously
uploaded update sites and that the key point to have previously
uploaded sites available while new one is in uploading stage.<br>
<br>
It should significantly reduce amount of errors because we keep two
update sites for each jbosstools-module, so at least one update site
is always available through composite update site for module. There
could be still problems for builds with slow connection, but
connection should be slow enough to live through at least two builds
for jbosstools module. This could be implemented as maven plug-n and
number of builds to keep in composite could be a good candidate for
configuration parameters.<br>
<br>
It is not really critical but nice to have.<br>
<br>
Denis<br>
<br>
<blockquote cite="mid:519BAFC0.1000408@redhat.com" type="cite">
<div class="moz-signature">-- <br>
Mickael Istria<br>
Eclipse developer at <a moz-do-not-send="true"
href="http://www.jboss.org/tools">JBoss, by Red Hat</a><br>
<a moz-do-not-send="true"
href="http://mickaelistria.wordpress.com">My blog</a> - <a
moz-do-not-send="true" href="http://twitter.com/mickaelistria">My
Tweets</a></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
jbosstools-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a></pre>
</blockquote>
<br>
</body>
</html>