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
Merged

"Delombok" entire project #249

merged 43 commits into from
Mar 26, 2019

Conversation

Sumo99
Copy link
Contributor

@Sumo99 Sumo99 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
Copy link
Contributor Author

Sumo99 commented Mar 25, 2019

Will this compile; I see failing builds?

@cjbrooks12
Copy link
Contributor

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
Copy link
Contributor Author

Sumo99 commented Mar 25, 2019

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

@cjbrooks12
Copy link
Contributor

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
Copy link
Contributor Author

Sumo99 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
Copy link
Contributor

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
Copy link
Contributor Author

Sumo99 commented Mar 25, 2019

Will this be accepted?

@cjbrooks12
Copy link
Contributor

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 orchidhq:dev Mar 26, 2019
@cjbrooks12
Copy link
Contributor

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 pushed a commit that referenced this pull request Apr 5, 2019
* 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants