Re: [wildfly-dev] Srcdeps in WildFly and WildFly Core

> On 2017-01-26 12:51, Kabir Khan wrote: >> >>> On 26 Jan 2017, at 11:37, Peter Palaga <ppalaga(a)redhat.com&gt; 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