[wildfly-dev] Srcdeps in WildFly and WildFly Core

Kabir Khan kabir.khan at jboss.com
Thu Jan 26 05:25:13 EST 2017


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.

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?


> On 26 Jan 2017, at 10:09, Juraci Paixão Kröhling <jcosta at redhat.com> wrote:
> 
> On 01/26/2017 10:52 AM, Petr Sakar wrote:
>> I agree with Brian. PR with SRC dependency *should not* be merged to master branch, that would create problems down the road.
>> You can use other branch as base for such merges and related CI
> 
> Let me share my experience with using srcdeps in Hawkular.
> 
> We've been bitten by this situation, where a srcdeps would be listed as 
> a dependency and the release process would eventually fail (and it was 
> an ugly failure). This is why there's a feature (on by default, IIRC), 
> which fails fast if the release profile is being used.
> 
> A good practice in Hawkular Services is to _avoid_ having srcdeps, but 
> it's _acceptable_ to have it on master, as long as it's removed by the 
> release date. Most of the time, there's no srcdeps in our pom.xml files, 
> but when we need it, it allows us to keep moving without asking N 
> developers to release the whole dependency chain.
> 
> - Juca.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




More information about the wildfly-dev mailing list