+1 to option 2. As I'm working on the package manager, I hope to move to splitting up pieces of Solr into their own packages (so as to have a lean core). Having the gradle build will be important at that time, so I have keen interest in seeing it merged soon.
On Wed, Nov 6, 2019 at 11:06 PM Erick Erickson <[email protected]> wrote: > > All: > > re: SOLR-13452. I’m now coming down on both sides of the issue. My motive > here is if this was pushed, even in its current incomplete state, people > would have an easier time contributing to the effort. Of course this means I > would be asking people to use the gradle build at least on master if at all > possible. > > There are several assumptions I’m making here: > > - we can keep running the Ant build as long as necessary. Ant would be our > primary build process. The purpose of pushing the current Gradle effort is to > make it easier for others to contribute and “just try it”. > > - There are no conflicts between the Gradle and Ant builds, so we can > continue to use Ant as necessary until we make the switch. > > - people will commit up front to putting some effort into this. I flat > guarantee I won’t carry the load alone. If nobody else steps up, I’ll table > it. I will volunteer to push fixes from non-committers. > — Yes, people can do this already with the gradle_8 branch, it’d just be > easier if it was already in the pull. > > - moving to Gradle as our primary workflow won’t happen until we work out > some of the kinks, things like. > — running on Jenkins. > — Getting the equivalent of “ant server dist” to run. > — Getting the ref guide built. > — I’m sure other things will crop up. > > > So there are several options, please let me know which one you prefer: > > 1. do nothing. People can check out the gradle_8 build and work on it. There > has been some of this so far, many thanks. > > 2. merge it into master only. TBD is when we take Ant out of master. > > 3. merge into both master and 8x. Assuming we can continue to use both, I’m > not sure what advantage there is to merging into 8x. This seems like > something that should come along with a major version release. > > 4. wait until it’s feature-complete. Based on the evidence so far, this may > be a long time coming. > > Also, the timing is fungible. I don’t see a downside as long as we can > continue to build with Ant. I certainly _do_ see a downside if we have to do > everything Ant does immediately after pushing to whatever branches. > > Erick > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
