Perhaps better for me as well (I couldn’t help myself and started addressing compiler warnings to clean up build output since gradle keeps the output so compact when its not dumping warning output), my main hold off is that I want to be available and engaged when it goes in. I’d like to target early sept, but I don’t want to commit and then delay, so I gave a little room.
Mark On Fri, Aug 16, 2019 at 6:54 AM Eric Pugh <ep...@opensourceconnections.com> wrote: > Sooner is better! I’m reading up on Gradle now ;-) > > > On Aug 16, 2019, at 5:33 AM, Jan Høydahl <jan....@cominvent.com> wrote: > > +1 > > Better to jump in now and have a few weeks of frustration and bug fixing > from all of us than keeping this amazing improvement it a dark branch much > longer :) > I'll probably also try to adapt releaseWidard.py on master to work with > the new build.. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 15. aug. 2019 kl. 23:23 skrev Mark Miller <markrmil...@gmail.com>: > > https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 Update the > lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > > Okay, we are at the point where either this thing lands soon and gains > some contributors to help finish or it overwhelms me and crashes & burns. > That almost sounds negative, but it was actually the plan so far and I'm > pretty excited after all this time invested. I need to punt this over to > the community though - the final implications and ramifications of moving > fully to gradle are just too big for me individually regardless of the time > frame. > > I've done about 95%+ of what I wanted to do before trying to land > something - a few more hoops to jump around. We pull in more deps than we > should right now, I'll deal with that shortly, and mvn publishing needs > work (mostly around solr-server, but dist and publishing both prob need > edge work at least). Those are the main things on my mind. There are > probably a ton of other little things, but I'm thinking those that are > important will rise up quickly and the rest can be handled over time. > > This will be a large change. Some things will still take time to get up to > par with what we have now. Many things will need to be sorted out (jenkins, > releases, smoke tester type things, docs, etc). > > I've also made all the decisions and trade-offs and what not. I'm pretty > happy about that, but I'm sure some will want to discuss and debate some > choices once things are in their face. I've spent a lot of time in my > recent life on this stuff and I'm ready to battle for some of it :) And to > be mistaken, ignorant, or convinced of other paths for some other parts of > it. I'll only say, every time I go from working with the gradle build back > to ant+ivy+mvn, it feels like a big backslide. > > I'm thinking maybe in September/October? And only on master, hopefully > living side by side with ant+ivy+mvn, but the goal would be for that period > to be brief. They can't live in complete harmony - someone has to own the > dependency view of the world for example, the one that actually gets > committed (license, checksums, etc). Otherwise, I've done my best to do > this in a way that doesn't break the current build. Will need to inspect > that closer before landing though. > > This is just another heads up. Once we are in a main branch, I'm hoping a > few of you will either have to jump in and help this land or we will have > to pull it back out I think. Be prepared :) > > -- > - Mark > > http://about.me/markrmiller > > > > _______________________ > *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467 > | http://www.opensourceconnections.com | My Free/Busy > <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless > of whether attachments are marked as such. > > -- - Mark http://about.me/markrmiller
