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