You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2019/11/06 17:35:50 UTC
Gradle build
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
+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 <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Dawid Weiss <da...@gmail.com>.
> — Getting the equivalent of “ant server dist” to run.
I never managed to understand what the proper assembly workflow is in
Solr, to be honest... the "create-package", "dist-*", "package-*"
tasks -- do all of these make sense (and need to be exposed in
gradle)?
> — Getting the ref guide built.
This should be done on a branch already.
> — I’m sure other things will crop up.
Oh, I'm sure they will ;)
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Tomas Fernandez Lobbe <tf...@apple.com.INVALID>.
+1 to option 2 to begin with. I don’t know if we need to wait for a major release for this change, but I think it may be easier to iterate while it’s only in master for a while.
> On Nov 7, 2019, at 2:41 PM, Adrien Grand <jp...@gmail.com> wrote:
>
> I'd be fine with option 2 but I have a slight preference for option 3.
> If we see the Gradle build as the future default build, then we need
> to start using it and I wonder that having to use a different workflow
> on branch_8x would be an incentive to keep using the Ant build
> instead.
>
> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com> wrote:
>>
>> I’m fine with Option 2.
>>
>> Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
>>
>> Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.
>>
>> Cassandra
>> On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>, wrote:
>>
>> Option 2.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Martin Gainty <mg...@hotmail.com>.
if for no other reason than to standardise on a sane trunk everyone can work on
+1 for backport to 8
________________________________
From: Erick Erickson <er...@gmail.com>
Sent: Saturday, November 9, 2019 10:41 AM
To: dev@lucene.apache.org <de...@lucene.apache.org>
Subject: Re: Gradle build
OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s too long.
To Cassandra’s point: I fully sympathize for two reasons:
1> the more we all can use Gradle all the time, the faster it’ll get into its final shape
2> the longer we have to add patches, the harder it’ll be to backport
Therefore I’m going to push for back-porting Real Soon Now, next weekend if possible. As soon as we have evidence that the Gradle build doesn’t break Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, I propose to back-port to 8x.
Let the fun begin!
Erick
> On Nov 8, 2019, at 8:30 PM, Gus Heck <gu...@gmail.com> wrote:
>
> +1 to option 2
>
> On Thu, Nov 7, 2019 at 6:23 PM David Smiley <da...@gmail.com> wrote:
>
> Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve on one branch while it’s new.
>
> On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand <jp...@gmail.com> wrote:
> I'd be fine with option 2 but I have a slight preference for option 3.
> If we see the Gradle build as the future default build, then we need
> to start using it and I wonder that having to use a different workflow
> on branch_8x would be an incentive to keep using the Ant build
> instead.
>
> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com> wrote:
> >
> > I’m fine with Option 2.
> >
> > Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
> >
> > Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.
> >
> > Cassandra
> > On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>, wrote:
> >
> > Option 2.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
> Sent from Gmail Mobile
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Cassandra Targett <ca...@gmail.com>.
I hoped to push my Ref Guide changes to the gradle_8 branch yesterday but got distracted with some other stuff for work. I don’t expect I’ll have time to work on it this weekend so if you push the other bits to master this weekend, I’ll make a new branch off master and will hopefully be able to get it in quickly early next week (I’m traveling Tuesday-Friday, so we’ll see).
Cassandra
On Nov 9, 2019, 9:41 AM -0600, Erick Erickson <er...@gmail.com>, wrote:
> OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s too long.
>
> To Cassandra’s point: I fully sympathize for two reasons:
>
> 1> the more we all can use Gradle all the time, the faster it’ll get into its final shape
>
> 2> the longer we have to add patches, the harder it’ll be to backport
>
> Therefore I’m going to push for back-porting Real Soon Now, next weekend if possible. As soon as we have evidence that the Gradle build doesn’t break Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, I propose to back-port to 8x.
>
> Let the fun begin!
>
> Erick
>
> > On Nov 8, 2019, at 8:30 PM, Gus Heck <gu...@gmail.com> wrote:
> >
> > +1 to option 2
> >
> > On Thu, Nov 7, 2019 at 6:23 PM David Smiley <da...@gmail.com> wrote:
> >
> > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve on one branch while it’s new.
> >
> > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand <jp...@gmail.com> wrote:
> > I'd be fine with option 2 but I have a slight preference for option 3.
> > If we see the Gradle build as the future default build, then we need
> > to start using it and I wonder that having to use a different workflow
> > on branch_8x would be an incentive to keep using the Ant build
> > instead.
> >
> > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com> wrote:
> > >
> > > I’m fine with Option 2.
> > >
> > > Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
> > >
> > > Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.
> > >
> > > Cassandra
> > > On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>, wrote:
> > >
> > > Option 2.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >
> >
> >
> > --
> > Adrien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> > --
> > Sent from Gmail Mobile
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Gradle build
Posted by Erick Erickson <er...@gmail.com>.
OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s too long.
To Cassandra’s point: I fully sympathize for two reasons:
1> the more we all can use Gradle all the time, the faster it’ll get into its final shape
2> the longer we have to add patches, the harder it’ll be to backport
Therefore I’m going to push for back-porting Real Soon Now, next weekend if possible. As soon as we have evidence that the Gradle build doesn’t break Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, I propose to back-port to 8x.
Let the fun begin!
Erick
> On Nov 8, 2019, at 8:30 PM, Gus Heck <gu...@gmail.com> wrote:
>
> +1 to option 2
>
> On Thu, Nov 7, 2019 at 6:23 PM David Smiley <da...@gmail.com> wrote:
>
> Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve on one branch while it’s new.
>
> On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand <jp...@gmail.com> wrote:
> I'd be fine with option 2 but I have a slight preference for option 3.
> If we see the Gradle build as the future default build, then we need
> to start using it and I wonder that having to use a different workflow
> on branch_8x would be an incentive to keep using the Ant build
> instead.
>
> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com> wrote:
> >
> > I’m fine with Option 2.
> >
> > Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
> >
> > Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.
> >
> > Cassandra
> > On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>, wrote:
> >
> > Option 2.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
> Sent from Gmail Mobile
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Gus Heck <gu...@gmail.com>.
+1 to option 2
On Thu, Nov 7, 2019 at 6:23 PM David Smiley <da...@gmail.com>
wrote:
>
> Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve
> on one branch while it’s new.
>
> On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand <jp...@gmail.com> wrote:
>
>> I'd be fine with option 2 but I have a slight preference for option 3.
>> If we see the Gradle build as the future default build, then we need
>> to start using it and I wonder that having to use a different workflow
>> on branch_8x would be an incentive to keep using the Ant build
>> instead.
>>
>> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com>
>> wrote:
>> >
>> > I’m fine with Option 2.
>> >
>> > Putting my project manager hat on, I’d really like to see a central
>> list or Jira issues of the things we want to make sure to do before we can
>> turn off Ant. The list/sub-tasks could be compiled after it’s merged to
>> master, but it would be nice if we could approach this in a coordinated way
>> so we’re all able to figure out quickly what remains - I think we’ll have a
>> higher chance of faster success that way. Hopefully also people would sign
>> up for the things that they will volunteer to drive to completion instead
>> of hanging back because they aren’t sure what needs to be done.
>> >
>> > Dawid and I worked on the Ref Guide transition to Gradle in a separate
>> branch and it’s either finished or very close to it IMO. It includes the PR
>> I put up last night to remove the PDF build tasks. I just need to merge it
>> into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to
>> do by tomorrow.
>> >
>> > Cassandra
>> > On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>,
>> wrote:
>> >
>> > Option 2.
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com>
>> 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: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
> Sent from Gmail Mobile
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Gradle build
Posted by David Smiley <da...@gmail.com>.
Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve
on one branch while it’s new.
On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand <jp...@gmail.com> wrote:
> I'd be fine with option 2 but I have a slight preference for option 3.
> If we see the Gradle build as the future default build, then we need
> to start using it and I wonder that having to use a different workflow
> on branch_8x would be an incentive to keep using the Ant build
> instead.
>
> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com>
> wrote:
> >
> > I’m fine with Option 2.
> >
> > Putting my project manager hat on, I’d really like to see a central list
> or Jira issues of the things we want to make sure to do before we can turn
> off Ant. The list/sub-tasks could be compiled after it’s merged to master,
> but it would be nice if we could approach this in a coordinated way so
> we’re all able to figure out quickly what remains - I think we’ll have a
> higher chance of faster success that way. Hopefully also people would sign
> up for the things that they will volunteer to drive to completion instead
> of hanging back because they aren’t sure what needs to be done.
> >
> > Dawid and I worked on the Ref Guide transition to Gradle in a separate
> branch and it’s either finished or very close to it IMO. It includes the PR
> I put up last night to remove the PDF build tasks. I just need to merge it
> into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to
> do by tomorrow.
> >
> > Cassandra
> > On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>,
> wrote:
> >
> > Option 2.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com>
> 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: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Sent from Gmail Mobile
Re: Gradle build
Posted by Adrien Grand <jp...@gmail.com>.
I'd be fine with option 2 but I have a slight preference for option 3.
If we see the Gradle build as the future default build, then we need
to start using it and I wonder that having to use a different workflow
on branch_8x would be an incentive to keep using the Ant build
instead.
On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <ca...@gmail.com> wrote:
>
> I’m fine with Option 2.
>
> Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
>
> Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.
>
> Cassandra
> On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>, wrote:
>
> Option 2.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Gradle build
Posted by Cassandra Targett <ca...@gmail.com>.
I’m fine with Option 2.
Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.
Cassandra
On Nov 6, 2019, 3:07 PM -0600, David Smiley <da...@gmail.com>, wrote:
> Option 2.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
Re: Gradle build
Posted by David Smiley <da...@gmail.com>.
Option 2.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <er...@gmail.com>
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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>