> What submodules don't solve is releases - if you're > on a particular unreleased Lucene version then releasing > Solr would still mean you need some kind of > "public" pinned Lucene release for the > Mavenworld.
Can we then update the submodule to point to the release tag or sha that Lucene got released from? On Sat, 1 May, 2021, 11:45 am Dawid Weiss, <[email protected]> wrote: > > Other than literally adding the git submodule, would we do anything else > to modify the gradle build so that or do we (and Jenkinsfile) have to > manually do a step to install Lucene before proceeding? > > Technically you add a submodule and then make a composite build from > Solr side. I can provide a PR that does it if you wish... This is > simple. What submodules don't solve is releases - if you're on a > particular unreleased Lucene version then releasing Solr would still > mean you need some kind of "public" pinned Lucene release for the > Maven world. If you distribute the entire thing as binaries you can > just publish a snapshot of Lucene code, of course. > > > I think adding git submodule means that we have to add back in all the > build code for it. > > No. The submodule is just a reference to a particular repository (and > commit) - the build code and remains nearly identical as it was with > Lucene. Composite builds in gradle are quite nice in that they're > (almost) transparent compared to dependency references. > > > At which point, I'd rather just copy and commit the > > code they have so we don't have to learn another git system. > > It's not really a different git system - it's a mechanism of > interacting with multiple repositories at once. Yes, it does add some > additional complexity but I think sooner or later you'll have to > interact with it anyway - many people favor monorepos these days and > this is a common way to assemble them from fragmented > sub-repositories. > > > I've > > heard submodules don't play nice with Jenkins, but don't have any > > direct experience with them. > > Some tools may require an additional flag to initialize and clone > sub-modules on the initial pull. Or manually. > > git submodule init > git submodule update --recursive. > > To summarize - I am not pushing for submodules, I do think they're a > viable alternative but pinned Maven references are simpler. The > problem with maven references is that we'd need a long(er) term maven > repository where such pinned references would live (without being > wiped out). Perhaps infra can help here and it'd solve the problem. > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
