[wildfly-dev] Srcdeps in WildFly and WildFly Core

[Peter Palaga]

On 2017-01-26 11:46, Juraci Paixão Kröhling wrote:
> On 01/26/2017 11:25 AM, Kabir Khan wrote:
>> Perhaps rather than a profile in the consuming project as Brian mentions, it should be disabled in srcdeps itself by default? Something along the lines that when its dependency resolution mechanism is hit, it fails unless -Dsrcdeps.enabled is passed in. Of course there is still a risk that someone adds that property to the pom by accident.

Not sure what would be the purpose of making srcdeps opt-in? - To allow 
CI and reviews, but to prevent merging? Well, could you tell me first 
what is wrong with merging source dependencies?

>> Also how does this work for nested projects? Say we add this to WildFly full, and I want to test WildFly with to something which is brought in by wildfly-core (e.g. undertow, Elytron etc.). How would that work?
>
> It works quite nicely. I remember seeing 3 levels of nesting and I'm
> sure it could have even more.
>
> It does delay the main build, though, as srcdeps builds the dependencies
> on demand. It means that the first local build of "wildfly-core" that
> depends on "elytron:1.2.3-src-abc123" will also build Elytron's revision
> "abc123".

Yes, as Juca said, running a build of project A that has a source 
dependency B, the build of B can trigger yet another build of its own 
source dependency C.

Perhaps I should note that the dependency builds run with -DskipTests by 
default so that they finish faster. For dependencies known to use 
checkstyle, license plugin or similar, their builds can be configured to 
skip those too to run even faster, as I do e.g. here 
https://github.com/wildfly/wildfly-core/pull/2122/commits/65326ef4ff6abc5673a605f2394003f9a9537fdb#diff-34efcdaa51afff46bba8cd9c1387e6f5R146

Further, once a source dependency is built, it is installed to Maven 
local repository and re-used from there for all subsequent builds that 
require it. A source dependency thus makes just the first build slower.
The local git repositories are kept too and therefore only the first 
clone takes long. All subsequent dependency builds use just fetch and reset.

-- P