On 26 Jan 2017, at 11:37, Peter Palaga <ppalaga(a)redhat.com>
wrote:
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?
Yes, or rather it would fail our default CI, apart from runs
where the opt in happens explicitly, which will help with accidentally merging.
Well, could you tell me first what is wrong with merging source
dependencies?
Perhaps that is fine for some projects/branches, but for
WildFly(-core) master we want proper released maven artifacts. I've had a quick look
at
http://maven.apache.org/xsd/core-extensions-1.0.0.xsd but there doesn't seem to be
a way to pass in any config properties to extensions.xml, but perhaps something could be
added to the yaml so you can set a policy there. It still runs the risk of getting merged
though :)
>> 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/65326ef4ff6abc5...
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