Skip to content

Pure Java Project Generator #2083

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

Merged
merged 23 commits into from
Oct 12, 2023
Merged

Pure Java Project Generator #2083

merged 23 commits into from
Oct 12, 2023

Conversation

csviri
Copy link
Collaborator

@csviri csviri commented Oct 9, 2023

Generator will generate a project and a minimal implementation of an operator.

@csviri csviri self-assigned this Oct 9, 2023
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 9, 2023
Copy link
Collaborator

@andreaTP andreaTP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like an excellent initiative!
Added a few comments, but is a great start! 👏

@csviri csviri linked an issue Oct 9, 2023 that may be closed by this pull request
@csviri csviri requested review from metacosm and andreaTP October 9, 2023 16:16
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: csviri <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: csviri <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
@csviri csviri force-pushed the project-generator branch from 33ce95e to 3900d23 Compare October 10, 2023 11:21
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
@csviri csviri marked this pull request as ready for review October 10, 2023 14:07
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 10, 2023
@openshift-ci openshift-ci bot requested a review from adam-sandor October 10, 2023 14:07
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
@@ -29,7 +29,7 @@ jobs:
./mvnw ${MAVEN_ARGS} formatter:validate -Dconfigfile=$PWD/contributing/eclipse-google-style.xml -pl '!operator-framework-bom' --file pom.xml
./mvnw ${MAVEN_ARGS} impsort:check -pl '!operator-framework-bom' --file pom.xml
- name: Run unit tests
run: ./mvnw ${MAVEN_ARGS} -B test --file pom.xml
run: ./mvnw ${MAVEN_ARGS} clean install --file pom.xml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this changed to to an install instead of simply testing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bom was then not accessible from the project, if there is no install


public class {{artifactClassId}}Spec {

private String value;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure we should be adding a value here since it will always often be removed and changing the value name / type is more work than just adding one from scratch, imo.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to have a minimalistic working project generated in these generators. So added a very simple implementation that can be instantly tried out.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I understand the point but as a user, I'm annoyed when I get generated code that's useless. My opinion is that if it isn't code that the user can use as-is or with only minimal changes, then it shouldn't be generated. In this case, it's easier to add the fields directly instead of having to have one generated and having to then change it afterwards, imo.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with create a field here, it would help people to getting started. Although it is indeed a noise for advanced users.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that it should be obvious that fields need to be added to the spec when creating a primary resource but if it's not, maybe then a comment should be generated to explain the purpose of this class and the status one. A comment would be better to help people get started since it would clarify the intent without creating noise that would interfere with the eventual functionality to be implemented.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it's much better to have something working, since new users can something actually see working. For those who actually understand already it is just simply a matter deleting few lines of code. We can comment this in code but also in readme that this is a simplistic operator generated, but it is actually working. So this helps people to make those first hard baby steps.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we'll have to agree to disagree. Especially considering that people will need to remember to re-apply the CRD each time they modify their CR, this might cause confusion for users to have something generated that's wrong and then they might forget to update it when they actually modify it. So adding a dummy value here is not really helping anything because that's not really the "hard" part of getting the operator to run in the first place.


import io.javaoperatorsdk.operator.api.ObservedGenerationAwareStatus;

public class {{artifactClassId}}Status extends ObservedGenerationAwareStatus {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the extends clause?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is just to not have the status empty, we can have simpler status in theory, but in the sample observed generation makes sense.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I'm also ok with an empty status.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could actually make sense to make status classes handle observed generation automatically instead of being opt-in. If it's a best practice, maybe it should be enforced by default and made it opt-out? (I forgot we had that feature, to be honest 😅 )

import java.util.Optional;

@ControllerConfiguration
public class {{artifactClassId}}Reconciler implements Reconciler<{{artifactClassId}}CustomResource>, EventSourceInitializer<{{artifactClassId}}CustomResource> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should be generating such complex code. While I understand the idea is to show examples of what can be done, in most instances, this code will only be deleted / changed and might confuse less advanced users who might think it is required for some reason. Generally speaking, I would expect code generation to only generate the minimal amount of code that is required to get started and/or things that will always be required (though you could make a point that things are always needed should be part of the framework anyway).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add comment to explain, but see the idea above to generate a minimal working implementatio. As it is done in generators like quarkus, that generates an ednpoint with "hellow world" response.

Copy link
Collaborator

@metacosm metacosm Oct 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, a minimal implementation is simply a reconciler that does nothing or maybe just outputs the name of resources it watches when an event occurs on of them. That's not what this is doing as it's adding an informer for ConfigMap, which has nothing to do with reconciling the primary resource. Not only does it go beyond what an MVP would be but it also adds code that will almost never be useful, imo. If we wanted to have a more complete example, I would rather have something using managed dependents anyway.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean somthing meaningful that does something. I don't think this is bad, actually might help people to getting started. Also can add there comment, why is it this way.

Copy link
Collaborator

@metacosm metacosm Oct 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to have something that does something out of the box, we should use the managed dependent approach because that's what we want people to use by default.

Copy link
Collaborator Author

@csviri csviri Oct 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is although eventually a preferred usage for some cases, it simply does not work for all cases. And the idea is to have an entry project, again understand the basic principles how it works.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A basic project should use managed dependents, period. It should address most users' needs. If they need more than managed dependents, they're already past the basic stuff and don't need to have their hand held by the code generator.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, generated code is not meant to be documentation, it's meant to get people started quickly without adding stuff they don't need just for the sake of exposure. Otherwise, that's a tutorial and the goals are different. The other aspect to take into account is that this generator will have to be maintained to follow the evolution of the rest of the code and the more complex it is, the more tricky it will be to maintain it up to date.

Copy link
Collaborator Author

@csviri csviri Oct 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if following your logic, the dependent resource usage is actually more code, additional class, etc. I think we could actually go with also that, so if you insist I can add a ConfigMapDependentResource.
Eventually I want to add an Integration test (next PR) that checks if the ConfigMap changed / created. That is why the logic there. As usually generators do, to generate some basic tests also.

This but also other generators like Spring Boot, Quarkus does, also not meant there as docs, neither here. But it is very helpful (at least to my experience) to have something very simple sample that is actually working and does something, instead of empty code. Since much easier to modify that, then figuring out from docs how to start with simplest case. This is worth the maintenance burden.

So can change it to use dependent resource, and the test later.

Signed-off-by: csviri <csviri@gmail.com>
Signed-off-by: csviri <csviri@gmail.com>
Signed-off-by: csviri <csviri@gmail.com>
@csviri csviri requested a review from metacosm October 11, 2023 11:19
Signed-off-by: csviri <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
Signed-off-by: Attila Mészáros <csviri@gmail.com>
@csviri csviri merged commit 9485c0c into next Oct 12, 2023
@csviri csviri deleted the project-generator branch October 12, 2023 11:57
csviri added a commit that referenced this pull request Oct 18, 2023
Signed-off-by: Attila Mészáros <csviri@gmail.com>
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.

Pure Java Project Bootsrapping
4 participants