[wildfly-dev] Srcdeps in WildFly and WildFly Core

[Peter Palaga]

On 2017-01-26 12:51, Kabir Khan wrote:
>
>> On 26 Jan 2017, at 11:37, Peter Palaga <ppalaga at 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/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
>>
>