Lombok
Hi everyone, I am considering adding Lombok as a compile-time dependency ( https://projectlombok.org/) so we can reduce the amount of boilerplate code and reduce the size of some of our classes. I have a small proof of concept PR ready to go. Before I do so, I want to find out if people have tried it before and how they feel about it, especially when used with IDEs like IntelliJ and/or Eclipse? Thanks, -Aditya
Re: Lombok
I've only touched a few classes in my PR, but I feel like there's a lot more boilerplate floating around that can be removed. Having said that, I agree with your point regarding Kotlin, but for the Java code I would find Lombok pretty useful. Have included a link to the PR: https://github.com/apache/geode/pull/2815 -Aditya On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer wrote: > The Spring world/community are heavy users of Lombok. > > In essence it is "nice", BUT it does now add a new dependency on a > library that is to provide functionality that developers should provide. > IJ Idea does provide support for Lombok. > > I have not yet seen any code bloat that Lombok could reduce for us. > Also, the reduction is only in terms of "visible", the compiled class > might be more verbose. > > Kotlin on the other hand, as some of the boilerplate code built in as a > language feature. I prefer that over choosing a library, that might have > compatibility issues in the future. > > Also, Kotlin's conciseness is also a language feature rather than > library plugin. I've also seen cases where compiled Java was larger than > the equivalent compiled Kotlin code. > > --Udo > > > On 11/8/18 10:31, Aditya Anchuri wrote: > > Hi everyone, > > > > I am considering adding Lombok as a compile-time dependency ( > > https://projectlombok.org/) so we can reduce the amount of boilerplate > code > > and reduce the size of some of our classes. I have a small proof of > concept > > PR ready to go. Before I do so, I want to find out if people have tried > it > > before and how they feel about it, especially when used with IDEs like > > IntelliJ and/or Eclipse? > > > > Thanks, > > -Aditya > > > >
Re: Permissions for Docker & JIRA
Also cherry-picked the LICENSE fix onto the release branch. Anthony > On Nov 8, 2018, at 10:04 AM, Anthony Baker wrote: > > Done! > >> On Nov 8, 2018, at 9:31 AM, Alexander Murmann wrote: >> >> Hi everyone, >> >> In order to perform all necessary steps to release 1.8.0, I need the >> following permissions: >> * Admin permissions for JIRA (username "amurmann") >> * Upload permissions for Docker Hub (username "ajmurmann") >> >> Thank you! >
Re: Permissions for Docker & JIRA
Done! > On Nov 8, 2018, at 9:31 AM, Alexander Murmann wrote: > > Hi everyone, > > In order to perform all necessary steps to release 1.8.0, I need the > following permissions: > * Admin permissions for JIRA (username "amurmann") > * Upload permissions for Docker Hub (username "ajmurmann") > > Thank you!
Re: Lombok
The Spring world/community are heavy users of Lombok. In essence it is "nice", BUT it does now add a new dependency on a library that is to provide functionality that developers should provide. IJ Idea does provide support for Lombok. I have not yet seen any code bloat that Lombok could reduce for us. Also, the reduction is only in terms of "visible", the compiled class might be more verbose. Kotlin on the other hand, as some of the boilerplate code built in as a language feature. I prefer that over choosing a library, that might have compatibility issues in the future. Also, Kotlin's conciseness is also a language feature rather than library plugin. I've also seen cases where compiled Java was larger than the equivalent compiled Kotlin code. --Udo On 11/8/18 10:31, Aditya Anchuri wrote: Hi everyone, I am considering adding Lombok as a compile-time dependency ( https://projectlombok.org/) so we can reduce the amount of boilerplate code and reduce the size of some of our classes. I have a small proof of concept PR ready to go. Before I do so, I want to find out if people have tried it before and how they feel about it, especially when used with IDEs like IntelliJ and/or Eclipse? Thanks, -Aditya
Re: [DISCUSS] Cutting 1.8 release branch
I’m working on a review of LICENSE and NOTICE. Looks like a few things slipped in that need to be declared. Anthony > On Nov 2, 2018, at 12:42 PM, Bruce Schuchardt wrote: > > Fixes for PRClientServerRegionFunctionExecutionDUnitTest and > CreateAsyncEventQueueCommandDUnitTest have been pushed to develop. > > > On 11/2/18 11:05 AM, Alexander Murmann wrote: >> Hi Ryan, >> >> I am currently waiting for the failing DUnit tests to pass and then plan to >> cut the release branch. Does it work for you if the fixes for GEODE-5972 >> would be merged to the branch after it has been cut? >> >> On Fri, Nov 2, 2018 at 9:57 AM Ryan McMahon wrote: >> >>> Bill Burcham and I have been working on a data inconsistency issue which >>> involves a lost event across WAN sites during rebalance on the originating >>> site. We are currently performing root cause analysis. Below is a Geode >>> ticket which we will update with more details as we learn more. >>> >>> https://issues.apache.org/jira/browse/GEODE-5972 >>> >>> On Thu, Nov 1, 2018 at 5:23 PM Ernest Burghardt >>> wrote: >>> and PR 390 has been approved and merged On Thu, Nov 1, 2018 at 5:10 PM Ernest Burghardt wrote: > geode-native fixes are in https://github.com/apache/geode-native/pull/390 > On Thu, Nov 1, 2018 at 4:06 PM Anthony Baker >>> wrote: >> The geode-native source headers I mentioned in [1] need to be cleaned up. >> Anthony >> >> [1] >> >>> https://lists.apache.org/thread.html/8c9da19d7c0ef0149b1ed79bf0cecde38f17a854ecfa0f0a42f1ff0b@%3Cdev.geode.apache.org%3E >>> On Nov 1, 2018, at 2:01 PM, Bruce Schuchardt < >>> bschucha...@pivotal.io> >> wrote: >>> This PR has been merged to develop >>> >>> >>> On 11/1/18 1:35 PM, Bruce Schuchardt wrote: I would like to get this PR in the release: >> https://github.com/apache/geode/pull/2757 I'm testing the merge to develop now On 11/1/18 1:18 PM, Sai Boorlagadda wrote: > Sure! agree that we should hold the releases unless there is a > critical issue. > > This is not a gating issue and the code is already committed to >> develop. > Sai > > On Thu, Nov 1, 2018 at 1:03 PM Alexander Murmann < amurm...@pivotal.io > wrote: > >> In the spirit of the previously discussed timed releases, we >>> should >> only >> hold cutting the release for critical issues, that for some >>> reason >> (not >> sure how that might be) should not be fixed after the branch has >> been cut. >> Waiting for features leads us down the slippery slope we are >>> trying >> to >> avoid by having timed releases. Does that make sense? >> >> On Thu, Nov 1, 2018 at 12:45 PM Sai Boorlagadda < >> sai.boorlaga...@gmail.com >> wrote: >> >>> I would like to resolve GEODE-5338 as it is currently waiting >>> for >>> doc update. >>> >>> Sai >>> >>> On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann < >> amurm...@pivotal.io> >>> wrote: >>> Hi everyone, It's time to cut the release branch, since we are moving to >>> time >> based releases. Are there any reasons why a release branch should not be >> cut >> as soon as possible? >> >
Re: Lombok
Note: If the PR gets accepted, people that use IntelliJ idea or Eclipse will need to use the Lombok plugin for their respective IDEs -- for IntelliJ people will also need to enable annotation processing in the compiler settings if not already enabled. On Thu, Nov 8, 2018 at 12:02 PM Aditya Anchuri wrote: > I've only touched a few classes in my PR, but I feel like there's a lot > more boilerplate floating around that can be removed. Having said that, I > agree with your point regarding Kotlin, but for the Java code I would find > Lombok pretty useful. Have included a link to the PR: > > https://github.com/apache/geode/pull/2815 > > -Aditya > > > > On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer wrote: > >> The Spring world/community are heavy users of Lombok. >> >> In essence it is "nice", BUT it does now add a new dependency on a >> library that is to provide functionality that developers should provide. >> IJ Idea does provide support for Lombok. >> >> I have not yet seen any code bloat that Lombok could reduce for us. >> Also, the reduction is only in terms of "visible", the compiled class >> might be more verbose. >> >> Kotlin on the other hand, as some of the boilerplate code built in as a >> language feature. I prefer that over choosing a library, that might have >> compatibility issues in the future. >> >> Also, Kotlin's conciseness is also a language feature rather than >> library plugin. I've also seen cases where compiled Java was larger than >> the equivalent compiled Kotlin code. >> >> --Udo >> >> >> On 11/8/18 10:31, Aditya Anchuri wrote: >> > Hi everyone, >> > >> > I am considering adding Lombok as a compile-time dependency ( >> > https://projectlombok.org/) so we can reduce the amount of boilerplate >> code >> > and reduce the size of some of our classes. I have a small proof of >> concept >> > PR ready to go. Before I do so, I want to find out if people have tried >> it >> > before and how they feel about it, especially when used with IDEs like >> > IntelliJ and/or Eclipse? >> > >> > Thanks, >> > -Aditya >> > >> >>
Re: Lombok
I’d prefer to keep lombok usage out of our public API’s. I’d like to be able to write javadoc for all public methods. Also, I don’t want a user to have to understand Lombok to read our API’s or do an extra step to setup their IDE. For internal usage I’m agnostic with a small dose of concern on equals/hashcode in critical code paths. My $0.02, Anthony > On Nov 8, 2018, at 1:57 PM, Aditya Anchuri wrote: > > Note: If the PR gets accepted, people that use IntelliJ idea or Eclipse > will need to use the Lombok plugin for their respective IDEs -- for > IntelliJ people will also need to enable annotation processing in the > compiler settings if not already enabled. > > On Thu, Nov 8, 2018 at 12:02 PM Aditya Anchuri wrote: > >> I've only touched a few classes in my PR, but I feel like there's a lot >> more boilerplate floating around that can be removed. Having said that, I >> agree with your point regarding Kotlin, but for the Java code I would find >> Lombok pretty useful. Have included a link to the PR: >> >> https://github.com/apache/geode/pull/2815 >> >> -Aditya >> >> >> >> On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer wrote: >> >>> The Spring world/community are heavy users of Lombok. >>> >>> In essence it is "nice", BUT it does now add a new dependency on a >>> library that is to provide functionality that developers should provide. >>> IJ Idea does provide support for Lombok. >>> >>> I have not yet seen any code bloat that Lombok could reduce for us. >>> Also, the reduction is only in terms of "visible", the compiled class >>> might be more verbose. >>> >>> Kotlin on the other hand, as some of the boilerplate code built in as a >>> language feature. I prefer that over choosing a library, that might have >>> compatibility issues in the future. >>> >>> Also, Kotlin's conciseness is also a language feature rather than >>> library plugin. I've also seen cases where compiled Java was larger than >>> the equivalent compiled Kotlin code. >>> >>> --Udo >>> >>> >>> On 11/8/18 10:31, Aditya Anchuri wrote: Hi everyone, I am considering adding Lombok as a compile-time dependency ( https://projectlombok.org/) so we can reduce the amount of boilerplate >>> code and reduce the size of some of our classes. I have a small proof of >>> concept PR ready to go. Before I do so, I want to find out if people have tried >>> it before and how they feel about it, especially when used with IDEs like IntelliJ and/or Eclipse? Thanks, -Aditya >>> >>>
Re: [DISCUSS] including Java11 in the pipelines
The key issue here is how closely the PR pipeline’s testing should match the develop pipeline. If parity is desirable, then we need to either add Java11 test jobs to the PR pipeline, or go back to having Java11 tests be non-gating in the develop pipeline. If instead we want PR to be just a smoke-test that runs only a subset of the tests that develop runs, we should discuss that subset explicitly (the line might be better drawn somewhere other than strictly Java 8 vs 11). -Owen > On Nov 7, 2018, at 1:34 PM, Jinmei Liao wrote: > > First of all, I believe all gating tests should be run in precheckin. If we > make jdk11 tests gating, we should make it part of the precheckin. If we > don't put them in precheckin, they should not be gating. > > Secondly, If we don't make jdk11 tests gating, soon they will become like > windows tests, people only look at them after it's been failing for days, > which is not good. > > Thirdly, for non-gating tests, we probably should run them after all the > gating tests are done. > > On Wed, Nov 7, 2018 at 11:39 AM Owen Nichols wrote: > >> Now that tests are passing under Java 11, it was recommended last week to >> make Java 11 tests gating for the develop pipeline. [Fyi, Windows tests >> are not yet gating, meaning the pipeline will success and publish artifacts >> even if a Windows tests fails.] >> >> Three topics merit discussion: >> >> 1) For the Geode 1.8 release, should the release notes advertise >> “experimental support for Java 11” or no support? If the latter, should >> Java 11 tests still be gating on the 1.8 release branch, or only on develop? >> >> 2) As of now, pre-checkin runs tests only against Java8. Now that Java11 >> is gating in develop, should we now be testing against both Java8 and >> Java11 as part of validating pull requests? >> >> 3) In the develop pipeline, should non-gating jobs continue to be run in >> parallel with gating jobs? Or would it be better to change the develop >> pipeline to only run the non-gating tests after all gating jobs have passed? >> >> Thanks, >> -Owen >> >> P.S. after a brief trial of combining Java8 and Java11 tests into a single >> pipeline job, that was reverted and it looks like separate jobs are here to >> stay. Combined jobs made it difficult to look at dual scrolling outputs >> and dual archive-results steps. If you feel there’s a better solution, >> please speak up. >> >> > > -- > Cheers > > Jinmei
Re: Lombok
Regarding is vs get, Lombok generates a getter as "isFoo" if foo is a boolean type -- but a Boolean object type by default gets generated as getFoo(). I personally like that, because I want to make sure I communicate in that getter that the type is nullable. On Thu, Nov 8, 2018 at 2:33 PM Anthony Baker wrote: > I’d prefer to keep lombok usage out of our public API’s. I’d like to be > able to write javadoc for all public methods. Also, I don’t want a user to > have to understand Lombok to read our API’s or do an extra step to setup > their IDE. > > For internal usage I’m agnostic with a small dose of concern on > equals/hashcode in critical code paths. > > My $0.02, > Anthony > > > > On Nov 8, 2018, at 1:57 PM, Aditya Anchuri wrote: > > > > Note: If the PR gets accepted, people that use IntelliJ idea or Eclipse > > will need to use the Lombok plugin for their respective IDEs -- for > > IntelliJ people will also need to enable annotation processing in the > > compiler settings if not already enabled. > > > > On Thu, Nov 8, 2018 at 12:02 PM Aditya Anchuri > wrote: > > > >> I've only touched a few classes in my PR, but I feel like there's a lot > >> more boilerplate floating around that can be removed. Having said that, > I > >> agree with your point regarding Kotlin, but for the Java code I would > find > >> Lombok pretty useful. Have included a link to the PR: > >> > >> https://github.com/apache/geode/pull/2815 > >> > >> -Aditya > >> > >> > >> > >> On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer wrote: > >> > >>> The Spring world/community are heavy users of Lombok. > >>> > >>> In essence it is "nice", BUT it does now add a new dependency on a > >>> library that is to provide functionality that developers should > provide. > >>> IJ Idea does provide support for Lombok. > >>> > >>> I have not yet seen any code bloat that Lombok could reduce for us. > >>> Also, the reduction is only in terms of "visible", the compiled class > >>> might be more verbose. > >>> > >>> Kotlin on the other hand, as some of the boilerplate code built in as a > >>> language feature. I prefer that over choosing a library, that might > have > >>> compatibility issues in the future. > >>> > >>> Also, Kotlin's conciseness is also a language feature rather than > >>> library plugin. I've also seen cases where compiled Java was larger > than > >>> the equivalent compiled Kotlin code. > >>> > >>> --Udo > >>> > >>> > >>> On 11/8/18 10:31, Aditya Anchuri wrote: > Hi everyone, > > I am considering adding Lombok as a compile-time dependency ( > https://projectlombok.org/) so we can reduce the amount of > boilerplate > >>> code > and reduce the size of some of our classes. I have a small proof of > >>> concept > PR ready to go. Before I do so, I want to find out if people have > tried > >>> it > before and how they feel about it, especially when used with IDEs like > IntelliJ and/or Eclipse? > > Thanks, > -Aditya > > >>> > >>> > >
Release branch for Apache Geode 1.8.0 has been cut
Hello everyone, As discussed previously created a new release branch for Apache Geode 1.8.0 - "release/1.8.0" Please do review and raise any concern with the release branch. If no concerns are raised, we will start with the voting for the release candidate soon. This also means that all tickets JIRA that get resolved on develop should be marked with 1.9.0 as their fix version. Thanks! Alexander
Re: [DISCUSS] including Java11 in the pipelines
Sounds like the overwhelming consensus is to keep Java11 gating, add Java11 to PR, and defer non-gating tests. I have prepared PRs for these changes: https://github.com/apache/geode/pull/2806 (add Java11 to PR pipeline) https://github.com/apache/geode/pull/2816 (run non-gating jobs only after gating jobs have passed) Please review and merge. Thanks, -Owen > On Nov 8, 2018, at 9:41 AM, Patrick Rhomberg wrote: > > I agree with Jinmei on all points. I definitely think there should be > parity between precheckin and the main pipeline, but that might just be > because I caused the main pipeline to fail on Java11 this week. > > On Wed, Nov 7, 2018 at 1:34 PM, Jinmei Liao wrote: > >> First of all, I believe all gating tests should be run in precheckin. If we >> make jdk11 tests gating, we should make it part of the precheckin. If we >> don't put them in precheckin, they should not be gating. >> >> Secondly, If we don't make jdk11 tests gating, soon they will become like >> windows tests, people only look at them after it's been failing for days, >> which is not good. >> >> Thirdly, for non-gating tests, we probably should run them after all the >> gating tests are done. >> >> On Wed, Nov 7, 2018 at 11:39 AM Owen Nichols wrote: >> >>> Now that tests are passing under Java 11, it was recommended last week to >>> make Java 11 tests gating for the develop pipeline. [Fyi, Windows tests >>> are not yet gating, meaning the pipeline will success and publish >> artifacts >>> even if a Windows tests fails.] >>> >>> Three topics merit discussion: >>> >>> 1) For the Geode 1.8 release, should the release notes advertise >>> “experimental support for Java 11” or no support? If the latter, should >>> Java 11 tests still be gating on the 1.8 release branch, or only on >> develop? >>> >>> 2) As of now, pre-checkin runs tests only against Java8. Now that Java11 >>> is gating in develop, should we now be testing against both Java8 and >>> Java11 as part of validating pull requests? >>> >>> 3) In the develop pipeline, should non-gating jobs continue to be run in >>> parallel with gating jobs? Or would it be better to change the develop >>> pipeline to only run the non-gating tests after all gating jobs have >> passed? >>> >>> Thanks, >>> -Owen >>> >>> P.S. after a brief trial of combining Java8 and Java11 tests into a >> single >>> pipeline job, that was reverted and it looks like separate jobs are here >> to >>> stay. Combined jobs made it difficult to look at dual scrolling outputs >>> and dual archive-results steps. If you feel there’s a better solution, >>> please speak up. >>> >>> >> >> -- >> Cheers >> >> Jinmei >>
Re: Apache Geode Branch Housekeeping
I'm pretty sure we want to keep the release tags for every release we've made, in case someone wants to check something against old releases. On Thu, Nov 8, 2018 at 5:04 PM Anthony Baker wrote: > Notes: > > - Older release/* branches may be removed. > - Do not remove branches like native-client-software-grant, sga2, > wan_cq_donation, etc. Those need to be preserved as a provenance record. > - Do not remove master or develop :-) > > > Anthony > > > > On Nov 8, 2018, at 4:55 PM, Patrick Rhomberg > wrote: > > > > Hello all! > > > > We currently have 182 branches on the apache/geode repository. This is > > excessive. > > Please fork the main repository and save your branches there. If you > > must use the apache/geode repository for some reason, please be diligent > in > > your removal of dead branches. > > > > *I would like to begin removing branches soon.* > > > > Many branches appear to refer to JIRA tickets that are closed, or have > > pull requests against them that have been merged. These seem safe to > > delete. > > Many branches are thousands of commits behind develop or months to even > > years old. Some of these branches have no commits since they were > > branched. Release branches notwithstanding, these seem relatively safe > to > > delete. I suspect there are some that should be maintained for legal or > > legacy reasons, in which case please let me know. > > > > This can be done most safely if you, as a responsible developer and > > reasonably-clean adult, were to pick up your own room. If you have > > anything listed under "Your branches" at [1], please copy them to your > fork > > and remove them from apache/geode. > > > > Thank you. > > > > Imagination is Change. > > ~ Patrick > > > > [1] https://github.com/apache/geode/branches/yours > >
Re: Apache Geode Branch Housekeeping
Our release tags should already be protected. We create all of our release tags under rel/ which apache protects by default. [1] Maybe we should just create rel/XXX tags for the heads of the branches Anthony mentioned and delete the branches themselves? https://git-wip-us.apache.org/docs/switching-to-git.html#protected-ref-lists On Thu, Nov 8, 2018 at 4:55 PM Patrick Rhomberg wrote: > Hello all! > > We currently have 182 branches on the apache/geode repository. This is > excessive. > Please fork the main repository and save your branches there. If you > must use the apache/geode repository for some reason, please be diligent in > your removal of dead branches. > > *I would like to begin removing branches soon.* > > Many branches appear to refer to JIRA tickets that are closed, or have > pull requests against them that have been merged. These seem safe to > delete. > Many branches are thousands of commits behind develop or months to even > years old. Some of these branches have no commits since they were > branched. Release branches notwithstanding, these seem relatively safe to > delete. I suspect there are some that should be maintained for legal or > legacy reasons, in which case please let me know. > > This can be done most safely if you, as a responsible developer and > reasonably-clean adult, were to pick up your own room. If you have > anything listed under "Your branches" at [1], please copy them to your fork > and remove them from apache/geode. > > Thank you. > > Imagination is Change. > ~ Patrick > > [1] https://github.com/apache/geode/branches/yours >
Re: Lombok
As an informative comparison on conciseness offering same functionality:
Java Code:
import java.io.Serializable; import lombok.Getter; import org.apache.geode.cache.configuration.CacheConfig.GatewayReceiver; import org.apache.geode.cache.configuration.DeclarableType; /** * This class stores the arguments provided in the create
gateway-receiver command. */ @Getter public class GatewayReceiverFunctionArgsimplements Serializable {
private static final long serialVersionUID = -5158224572470173267L; private
final BooleanmanualStart; private final IntegerstartPort; private final
IntegerendPort; private final StringbindAddress; private final
IntegersocketBufferSize; private final IntegermaximumTimeBetweenPings; private
final String[]gatewayTransportFilters; private final StringhostnameForSenders;
private final BooleanifNotExists; public
GatewayReceiverFunctionArgs(GatewayReceiver configuration, Boolean ifNotExists)
{
this.manualStart = configuration.isManualStart(); this.startPort =
configuration.getStartPort() !=null ?
Integer.valueOf(configuration.getStartPort()) :null; this.endPort =
configuration.getEndPort() !=null ?
Integer.valueOf(configuration.getEndPort()) :null; this.bindAddress =
configuration.getBindAddress(); this.socketBufferSize =
configuration.getSocketBufferSize() !=null ?
Integer.valueOf(configuration.getSocketBufferSize()) :null;
this.maximumTimeBetweenPings = configuration.getMaximumTimeBetweenPings()
!=null ? Integer.valueOf(configuration.getMaximumTimeBetweenPings()) :null;
this.gatewayTransportFilters = configuration.getGatewayTransportFilter() !=null
?
configuration.getGatewayTransportFilter().stream().map(DeclarableType::getClassName)
.toArray(String[]::new)
:null; this.hostnameForSenders =
configuration.getHostnameForSenders(); this.ifNotExists = ifNotExists; }
}
The equivalent Kotlin definition is:
import org.apache.geode.cache.configuration.CacheConfig
import org.apache.geode.cache.configuration.ClassWithParametersType
import java.io.Serializable
data class GatewayReceiverFunctionArgs
@JvmOverloads private constructor(val manualStart: Boolean, val startPort: Int?, val
endPort: Int?, val bindAddress: String, val socketBufferSize: Int?, val
maximumTimeBetweenPings: Int?, val gatewayTransportFilters: Array, val
hostNameForSender: String, val ifNotExists: Boolean) : Serializable{
constructor(configuration: CacheConfig.GatewayReceiver, ifNotExists:
Boolean) :
this(configuration.isManualStart, configuration.startPort?.toInt(),
configuration.endPort?.toInt(), configuration.bindAddress,
configuration.socketBufferSize?.toInt(), configuration.maximumTimeBetweenPings?.toInt(),
configuration.gatewayTransportFilter ?.map { classWithParametersType:
ClassWithParametersType-> classWithParametersType.className }
?.toTypedArray()
?:emptyArray(), configuration.hostnameForSenders, ifNotExists)
companion object {
@JvmStatic val serialVersionUID = -5158224572470173267L }
}
On 11/8/18 12:02, Aditya Anchuri wrote:
I've only touched a few classes in my PR, but I feel like there's a lot
more boilerplate floating around that can be removed. Having said that, I
agree with your point regarding Kotlin, but for the Java code I would find
Lombok pretty useful. Have included a link to the PR:
https://github.com/apache/geode/pull/2815
-Aditya
On Thu, Nov 8, 2018 at 11:24 AM Udo Kohlmeyer wrote:
The Spring world/community are heavy users of Lombok.
In essence it is "nice", BUT it does now add a new dependency on a
library that is to provide functionality that developers should provide.
IJ Idea does provide support for Lombok.
I have not yet seen any code bloat that Lombok could reduce for us.
Also, the reduction is only in terms of "visible", the compiled class
might be more verbose.
Kotlin on the other hand, as some of the boilerplate code built in as a
language feature. I prefer that over choosing a library, that might have
compatibility issues in the future.
Also, Kotlin's conciseness is also a language feature rather than
library plugin. I've also seen cases where compiled Java was larger than
the equivalent compiled Kotlin code.
--Udo
On 11/8/18 10:31, Aditya Anchuri wrote:
Hi everyone,
I am considering adding Lombok as a compile-time dependency (
https://projectlombok.org/) so we can reduce the amount of boilerplate
code
and reduce the size of some of our classes. I have a small proof of
concept
PR ready to go. Before I do so, I want to find out if people have tried
it
before and how they feel about it, especially when used with IDEs like
IntelliJ and/or Eclipse?
Thanks,
-Aditya
Apache Geode Branch Housekeeping
Hello all! We currently have 182 branches on the apache/geode repository. This is excessive. Please fork the main repository and save your branches there. If you must use the apache/geode repository for some reason, please be diligent in your removal of dead branches. *I would like to begin removing branches soon.* Many branches appear to refer to JIRA tickets that are closed, or have pull requests against them that have been merged. These seem safe to delete. Many branches are thousands of commits behind develop or months to even years old. Some of these branches have no commits since they were branched. Release branches notwithstanding, these seem relatively safe to delete. I suspect there are some that should be maintained for legal or legacy reasons, in which case please let me know. This can be done most safely if you, as a responsible developer and reasonably-clean adult, were to pick up your own room. If you have anything listed under "Your branches" at [1], please copy them to your fork and remove them from apache/geode. Thank you. Imagination is Change. ~ Patrick [1] https://github.com/apache/geode/branches/yours
Re: Apache Geode Branch Housekeeping
Notes: - Older release/* branches may be removed. - Do not remove branches like native-client-software-grant, sga2, wan_cq_donation, etc. Those need to be preserved as a provenance record. - Do not remove master or develop :-) Anthony > On Nov 8, 2018, at 4:55 PM, Patrick Rhomberg wrote: > > Hello all! > > We currently have 182 branches on the apache/geode repository. This is > excessive. > Please fork the main repository and save your branches there. If you > must use the apache/geode repository for some reason, please be diligent in > your removal of dead branches. > > *I would like to begin removing branches soon.* > > Many branches appear to refer to JIRA tickets that are closed, or have > pull requests against them that have been merged. These seem safe to > delete. > Many branches are thousands of commits behind develop or months to even > years old. Some of these branches have no commits since they were > branched. Release branches notwithstanding, these seem relatively safe to > delete. I suspect there are some that should be maintained for legal or > legacy reasons, in which case please let me know. > > This can be done most safely if you, as a responsible developer and > reasonably-clean adult, were to pick up your own room. If you have > anything listed under "Your branches" at [1], please copy them to your fork > and remove them from apache/geode. > > Thank you. > > Imagination is Change. > ~ Patrick > > [1] https://github.com/apache/geode/branches/yours
Re: Apache Geode Branch Housekeeping
For a matter of safety, perhaps we should as INFRA to protect those branches? > On Nov 8, 2018, at 5:04 PM, Anthony Baker wrote: > > Notes: > > - Older release/* branches may be removed. > - Do not remove branches like native-client-software-grant, sga2, > wan_cq_donation, etc. Those need to be preserved as a provenance record. > - Do not remove master or develop :-) > > > Anthony > > >> On Nov 8, 2018, at 4:55 PM, Patrick Rhomberg wrote: >> >> Hello all! >> >> We currently have 182 branches on the apache/geode repository. This is >> excessive. >> Please fork the main repository and save your branches there. If you >> must use the apache/geode repository for some reason, please be diligent in >> your removal of dead branches. >> >> *I would like to begin removing branches soon.* >> >> Many branches appear to refer to JIRA tickets that are closed, or have >> pull requests against them that have been merged. These seem safe to >> delete. >> Many branches are thousands of commits behind develop or months to even >> years old. Some of these branches have no commits since they were >> branched. Release branches notwithstanding, these seem relatively safe to >> delete. I suspect there are some that should be maintained for legal or >> legacy reasons, in which case please let me know. >> >> This can be done most safely if you, as a responsible developer and >> reasonably-clean adult, were to pick up your own room. If you have >> anything listed under "Your branches" at [1], please copy them to your fork >> and remove them from apache/geode. >> >> Thank you. >> >> Imagination is Change. >> ~ Patrick >> >> [1] https://github.com/apache/geode/branches/yours >
Re: [DISCUSS] including Java11 in the pipelines
I agree with Jinmei on all points. I definitely think there should be parity between precheckin and the main pipeline, but that might just be because I caused the main pipeline to fail on Java11 this week. On Wed, Nov 7, 2018 at 1:34 PM, Jinmei Liao wrote: > First of all, I believe all gating tests should be run in precheckin. If we > make jdk11 tests gating, we should make it part of the precheckin. If we > don't put them in precheckin, they should not be gating. > > Secondly, If we don't make jdk11 tests gating, soon they will become like > windows tests, people only look at them after it's been failing for days, > which is not good. > > Thirdly, for non-gating tests, we probably should run them after all the > gating tests are done. > > On Wed, Nov 7, 2018 at 11:39 AM Owen Nichols wrote: > > > Now that tests are passing under Java 11, it was recommended last week to > > make Java 11 tests gating for the develop pipeline. [Fyi, Windows tests > > are not yet gating, meaning the pipeline will success and publish > artifacts > > even if a Windows tests fails.] > > > > Three topics merit discussion: > > > > 1) For the Geode 1.8 release, should the release notes advertise > > “experimental support for Java 11” or no support? If the latter, should > > Java 11 tests still be gating on the 1.8 release branch, or only on > develop? > > > > 2) As of now, pre-checkin runs tests only against Java8. Now that Java11 > > is gating in develop, should we now be testing against both Java8 and > > Java11 as part of validating pull requests? > > > > 3) In the develop pipeline, should non-gating jobs continue to be run in > > parallel with gating jobs? Or would it be better to change the develop > > pipeline to only run the non-gating tests after all gating jobs have > passed? > > > > Thanks, > > -Owen > > > > P.S. after a brief trial of combining Java8 and Java11 tests into a > single > > pipeline job, that was reverted and it looks like separate jobs are here > to > > stay. Combined jobs made it difficult to look at dual scrolling outputs > > and dual archive-results steps. If you feel there’s a better solution, > > please speak up. > > > > > > -- > Cheers > > Jinmei >
Permissions for Docker & JIRA
Hi everyone, In order to perform all necessary steps to release 1.8.0, I need the following permissions: * Admin permissions for JIRA (username "amurmann") * Upload permissions for Docker Hub (username "ajmurmann") Thank you!
