Gradle build

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Gradle build

Erick Erickson
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Ishan Chattopadhyaya
+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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Dawid Weiss-2
In reply to this post by Erick Erickson
> — 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

david.w.smiley@gmail.com
In reply to this post by Erick Erickson
Option 2.

~ David Smiley
Apache Lucene/Solr Search Developer


On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Cassandra Targett
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 <[hidden email]>, wrote:
Option 2.

~ David Smiley
Apache Lucene/Solr Search Developer


On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Adrien Grand
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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Tomas Fernandez Lobbe-3
+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

david.w.smiley@gmail.com
In reply to this post by Adrien Grand

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Sent from Gmail Mobile
Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Gus Heck
+1 to option 2

On Thu, Nov 7, 2019 at 6:23 PM David Smiley <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>


--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Sent from Gmail Mobile


--
Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Erick Erickson
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 <[hidden email]> wrote:
>
> +1 to option 2
>
> On Thu, Nov 7, 2019 at 6:23 PM David Smiley <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
> Sent from Gmail Mobile
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Cassandra Targett
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 <[hidden email]>, 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 <[hidden email]> wrote:

+1 to option 2

On Thu, Nov 7, 2019 at 6:23 PM David Smiley <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]



--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Sent from Gmail Mobile


--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build

Martin Gainty
In reply to this post by Erick Erickson
if for no other reason than to standardise on a sane trunk everyone can work on
+1 for backport to 8



From: Erick Erickson <[hidden email]>
Sent: Saturday, November 9, 2019 10:41 AM
To: [hidden email] <[hidden email]>
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 <[hidden email]> wrote:
>
> +1 to option 2
>
> On Thu, Nov 7, 2019 at 6:23 PM David Smiley <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
> Sent from Gmail Mobile
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]