<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 15 Aug 2017 08:17, &quot;Carlo de Wolf&quot; &lt;<a href="mailto:cdewolf@redhat.com">cdewolf@redhat.com</a>&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That would be no different than a project provisioning the runtime. At which point the project can do whatever tests they see fit to ensure final integration into the product.<br>
<br>
Tie to this component upgrades being dictated from down the lines of dependencies instead of coming from above and I think you would have all bases covered.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">+1 that would be awesome. </div><div dir="auto"><br></div><div dir="auto">In the Hibernate team we&#39;d be open to volunteer testing such a new process but we&#39;re looking forward for directions from the WildFly team... or shall we just move forward with the current notion of feature packs? I heard rumours of someone to experiment with new tools? Please let us know.</div><div dir="auto"><br></div><div dir="auto">Thanks</div><div dir="auto">Sanne </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888"><br>
<br>
Carlo</font><div class="elided-text"><br>
<br>
On 08/14/2017 05:24 PM, Sanne Grinovero wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 14 August 2017 at 15:48, James Perkins &lt;<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There&#39;s no way we can have tests for every feature that every project brings<br>
into WildFly.<br>
</blockquote>
Indeed: we could add some more tests, but there&#39;s a practical limit;<br>
the combined Hibernate projects would potentially contribute some<br>
~8000 additional tests - but that&#39;s also adding some 3 hours testing<br>
to each build, which doesn&#39;t scale.<br>
You might want to hand-pick some strategical ones covering<br>
integration, but such a manual selection is bound to be out of date in<br>
no time.<br>
<br>
On the other hand Carlo make a good point: the need to make sure such<br>
things don&#39;t happen again.<br>
<br>
I suspect the solution is to be found in some evolution of the<br>
&quot;feature packs&quot; concept. The primary problem is that in upstream<br>
(Hibernate projects) we pick our own dependencies and build our own<br>
modules.<br>
This same structure is then replicated in WildFly, but the structure<br>
of the modules and the versions are just crafted by humans to look<br>
like the same - which introduces the need for us to &quot;watch&quot; what<br>
you&#39;re all changing, as versions could drift apart, to the point of<br>
not actually working correctly in some cases.<br>
We need to make sure that the very same combination of module<br>
definitions and dependencies that we use to test upstream is<br>
incorporater verbatim into WildFly.<br>
<br>
That would be a reliable solution, and without the need to expand on<br>
the testsuite dimensions - neither code (maintenance) nor build times.<br>
It would also avoid you all needing to install the 30+ RDBMS vendors &amp;<br>
versions we support to actually run all those tests.<br>
<br>
Tomaž had kindly contributed a prototype for Hibernate Search to<br>
publish feature packs, and I loved the idea as it addresses such<br>
problems, but then we failed to find a consensus about how this would<br>
work.<br>
I&#39;m still looking forward to hear some clarification on such plans:<br>
  - <a href="http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html" rel="noreferrer" target="_blank">http://lists.jboss.org/piperma<wbr>il/wildfly-dev/2017-January/<wbr>005686.html</a><br>
<br>
Thanks,<br>
Sanne<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf &lt;<a href="mailto:cdewolf@redhat.com" target="_blank">cdewolf@redhat.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
These form of conflicts must be guarded in a test(suite) that is part of<br>
WildFly release criteria.<br>
<br>
Carlo<br>
<br>
<br>
On 08/12/2017 11:44 AM, Sanne Grinovero wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks James! I&#39;ve sent a PR to restore the previous version.<br>
<br>
I&#39;ll be checking some more cross-project dependency requirements next<br>
weeek.<br>
<br>
On 12 August 2017 at 01:08, James Perkins &lt;<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It looks like it came in as part of<br>
<a href="https://issues.jboss.org/browse/WFLY-7908" rel="noreferrer" target="_blank">https://issues.jboss.org/brows<wbr>e/WFLY-7908</a>. I&#39;m personally not a big fan<br>
of<br>
these sweeping version updates like this for this exact reason. We&#39;ve<br>
had<br>
issues with this type of thing before and I do think we need a better<br>
approach.<br>
<br>
IMO we can definitely downgrade this. I also see no other modules that<br>
depend on it either.<br>
<br>
On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero &lt;<a href="mailto:sanne@hibernate.org" target="_blank">sanne@hibernate.org</a>&gt;<br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I just noticed that the Apache Avro version included in WildFly was<br>
upgraded to 1.8.1.<br>
<br>
This breaks Hibernate Search. It wasn&#39;t caught by automated<br>
integration tests as this aspect wasn&#39;t covered by integration tests<br>
within the wildfly codebase - we have them within Hibernate.<br>
<br>
A quick grep on the module definitions doesn&#39;t reveal any other user,<br>
and &quot;git blame&quot; seems to suggest it was updated just for the sake of<br>
updating some components.. so I&#39;m guessing there is no other<br>
stackeholder I should align with?<br>
<br>
1# Could we please revert it to 1.7.6, which is what Hibernate Search<br>
requires?<br>
<br>
Alternatively we&#39;ll need some ad-hoc coding on Hibernate Search and a<br>
new version respin - with all associated risks - just for the sake of<br>
updating this.<br>
<br>
2# What can we do to prevent such things in the future?<br>
<br>
I can of course contribute some more integration tests but it&#39;s never<br>
going to be enough: there will always be more tests &quot;upstream&quot;. Could<br>
we rather agree on some improved communication process when you all<br>
consider updating an indirect dependency?<br>
<br>
Thanks,<br>
Sanne<br>
<br>
   - <a href="https://issues.jboss.org/browse/WFLY-9221" rel="noreferrer" target="_blank">https://issues.jboss.org/brows<wbr>e/WFLY-9221</a><br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a><br>
</blockquote>
<br>
<br>
<br>
--<br>
James R. Perkins<br>
JBoss by Red Hat<br>
</blockquote>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a><br>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
--<br>
James R. Perkins<br>
JBoss by Red Hat<br>
</blockquote></blockquote>
<br>
</div></blockquote></div><br></div></div></div>