[wildfly-dev] Srcdeps in WildFly and WildFly Core

[Peter Palaga]

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 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 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

> Rostislav
>
>>  > 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
>>>>
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev