Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Delombok" entire project #249

Merged
merged 43 commits into from Mar 26, 2019

Conversation

@Sumo99
Copy link
Contributor

commented Mar 25, 2019

This resolves issue #244. I had to commit the files one by one painstakingly, is there a more efficient way to upload an entire folder at once?

Sumo99 added some commits Mar 25, 2019

Sumo99 added some commits Mar 25, 2019

@Sumo99

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2019

Will this compile; I see failing builds?

@cjbrooks12

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

All the failed builds were on Azure Pipelines, and it looks like it just had network problems. The Travis CI checks were successful, so everything's compiling, your changes are looking good.

As for adding an entire folder at once, are you not familiar with the command-line tool Git? Rather than uploading each file from the browser, you should be using Git on your local computer to add all changes at once, rather than each file individually.

Github has a series of guides for how to get started using Git and how it relates to Github (because they are not the same thing). In particular, the following guides would probably be the most helpful to start with:

You may also be interested in using Git from a desktop GUI client rather than the command-line, and I'm partial to GitKraken, but I've also been hearing good things about GitHub Desktop which is targeted more specifically towards beginners and the GitHub ecosystem.

@Sumo99

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2019

Ok thank you! Why do you have four types of continuous integration?

@cjbrooks12

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

Travis CI is the primary one right now, its tests on Linux and Mac, and also has the release workflow.

Appveyor tests on Windows.

Codacy handles code quality, like linting and test coverage reports.

And finally, Azure Pipelines is able to handle Windows, Mac, and Linux tests all in one place. Ideally, I would like to get rid of Travis CI and Appveyor and just run all tests and releases on Azure, but as you can see from those checks, there is some instability on that platform right now. I'm keeping it around in addition to Travis CI and Appveyor so I can continue to evaluate it.

@Sumo99

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2019

Dumb question but why use kotlin for your project; java seems to do fine? Hope I am not annoying with questions.

@cjbrooks12

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

I don't mind at all, I'm happy to answer your questions!

First, I just want to say that Java is a great language, and I really enjoy working in Java. It's perfectly fine to keep developing in the Java language, it's gonna be here for a long time. Even though the majority of code I write for the JVM is Kotlin, I still say Java is my favorite language because of the ecosystem built around it and its wealth of high-quality libraries and frameworks.

But Kotlin is also a great language, and it works incredibly well within the larger JVM ecosystem. I am primarily an Android developer at my day job, which is what got me interested in Kotlin initially (I never really touched it before Google's adoption of it on Android). But the more I use it, the more I like it. For the most part, I tend to write the same style of code as I do with Java 8 and Lombok, but Kotlin's reduction of boilerplate is not dependant upon the hacks that Lombok does.

In general, there are a few things that I greatly prefer in Kotlin that Java does not offer. Keep in mind that all of these are just syntactic sugar over features Java already has, and I just prefer the way Kotlin does it:

  • Class properties, so I don't have to write getters or setters
  • Data classes, especially immutable data classes. These really help to make your code robust and prevent unwanted changes
  • Null safety, which cannot be understated. Personally, I am not as much of a hater of NPEs as a lot of people are, and null can be a very helpful tool for easy-to-use APIs. But being forced to acknowledge when a variable is even able to be null eliminates a whole class of errors and further improves robustness and encourages correct usage of APIs

To be completely honest, my personal recommendation is that, for anyone interested in Kotlin/JVM, you should use it over Java. It's got seamless integration and can be incrementally migrated, you still get all the benefits of the Java ecosystem, but you also get more concise, easier-to-read and easier-to-maintain code.

@Sumo99

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2019

Will this be accepted?

@cjbrooks12

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

Yes, it will, I just haven't had a chance to pull it down locally and check it all out yet. I should get it merged tonight.

@cjbrooks12 cjbrooks12 merged commit c7fe43e into JavaEden:dev Mar 26, 2019

7 checks passed

Codacy/PR Quality Review Up to standards. A positive pull request.
Details
Orchid-Gradle-CI Build #20190326.1 succeeded
Details
Orchid-Gradle-CI (Agent macOS Build) Agent macOS Build succeeded
Details
Orchid-Gradle-CI (Linux Build) Linux Build succeeded
Details
Orchid-Gradle-CI (Windows Build) Windows Build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@cjbrooks12

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

I just merged this PR in, thank you so much for the help here, @Sumo99! I really appreciate it, this is going to make it so much easier to continue migrating code to Kotlin!

cjbrooks12 added a commit that referenced this pull request Apr 5, 2019

"Delombok" entire project (#249)
* Update Social.java

* Update TestResults.java

* Update TestRenderer.java

* Update PageContentComponent.java

* Update Relation.java

* Update JsPage.java

* Update FolderCollection.java

* Update PublicationServiceImpl.java

* Update ScriptPublisher.java

* Update OrchidMenu.java

* Update OrchidResponse.java

* Update PebbleTemplateLoader.java

* Update OrchidSiteImpl.java

* Update OrchidMenuFactory.java

* Update GeneratorMetrics.java

* Update OptionsDescription.java

* Update ArchetypeDescription.java

* Update ArchetypeDescription.java

* Update OptionHolderDescription.java

* Update IndexServiceImpl.java

* Update TemplateTag.java

* Update ModularList.java

* Update OrchidPublisher.java

* Update OrchidView.java

* Update OrchidServer.java

* Update OrchidRoute.java

* Update PebbleWrapperTemplateFilter.java

* Update PebbleWrapperTemplateFunction.java

* Update NetlifyPublisher.java

* Update RenderServiceImpl.java

* Update BuildMetrics.java

* Update TaskServiceImpl.java

* Update CompilerServiceImpl.java

* Update GeneratorServiceImpl.java

* Update PebbleWrapperTemplateTag.java

* Update OrchidContextImpl.java

* Update OrchidFlags.java

* Update EventServiceImpl.java

* Update ExternalResource.java

* Update GithubPagesPublisher.java

* Update OrchidWebserver.java

* Update ResourceServiceImpl.java

* Removes Lombok dependencies entirely.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.