Email from tomazcerar:

Hey guys,

This whole dispute around upstream / downstream dependencies.

I did analysis of whole dependency tree for all quickstarts (prod & upstream).
In most cases they consume only spec api jars/poms which is the ideal scenario,
as this means problems with prod rebuilds are not a big deal, as spec and api deps rarely change
and are in most cases interchangeable with community ones without problems.

Problem is few quickstarts that use EAP dependency components much more directly.
examples of such deps are

hibernate
various security
picketbox
picketlink
security-api
security subsystem
cxf client
arquillian

And in some cases this dependencies are inadvertently bring in much more than is asked for.

Good (or bad) example would be "ejb-security-interceptors" QS which has dependence on
seemingly innocent org.jboss.eap:wildfly-security-api:jar:7.0.0.GA-redhat-2

But as it happens this "api" jar depends on org.jboss.eap:wildfly-security which is actual security subsystem,
that has than transitive dependencies to half of the server.
This brings number of required dependencies to build this quickstart trough the roof.

And such simple mistakes, in this case on engineering side, complicate building & testing.
If we keep quickstarts to consume only spec & API dependencies this whole prod rebuild cycle and
need for temp maven repo will end up beeing non issue.

There will always be some quickstarts that need to depend on more internal stuff,
which do require prod rebuild deps, but those are only a few and they can get improved consume as little as possible.

As immediate action, I will send some PRs today that cleanup dep tree a bit, which should help the work right away.
This shouldn't disturb Sande's work for time being, but will just help with the process at least until we agree upon further action next week.

–
tomaz