[wildfly-dev] Srcdeps in WildFly and WildFly Core

[Rostislav Svoboda]

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

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