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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev