6:09 a.m.
On 2017-01-26 12:51, Kabir Khan wrote:
> 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.
Yes, I see your preference, but I do not see clearly why you want to ban
source dependencies from master.
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 :)
Yes, extensions.xml does not allow for passing any config params to
extensions. Srcdeps.yaml would be a better place for such an option. I
can add it once there is enough consensus to go that way. -- P
>
>>> 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
>