On 2017-01-26 13:46, Rostislav Svoboda wrote:
> 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?
>>>>> along the lines that when its dependency resolution mechanism is
>>>>> 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
>> 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 think the question is different:
Which of current problems is srcdeps solving ?
It is an improvement of the development process through simplifying it
and making it faster.
As I said in the initial message, the main advantage of srcdeps is that
changes in components can be integrated, tested and reviewed in wildfly
and wildfly-core immediately after they are committed to a public
component branch. The developer does not need to wait for the component
release. He gets the feedback from CI and reviewers faster. I do not
think anything changes for quality engineers, given that the current
proposal assumes srcdeps-free releases. -- P
> > I've had a quick look at
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
>>>>> full, and I want to test WildFly with to something which is brought
>>>>> 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
>>>> depends on "elytron:1.2.3-src-abc123" will also build
>>> 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
>>> 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
> wildfly-dev mailing list