-
Notifications
You must be signed in to change notification settings - Fork 42
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
Using annotation processor #96
Comments
So you would annotate domain classes ? Can you give an example of how you see it working from the user point of view ? |
Yes. The thing is most of the domain classes are already annotated somehow (JPA
AssertJ code: interface AssertJGeneratorProvider {
List<Annotation> getSupportedAnnotations();
} User code: @Entity
class MyEntity {
//fields
}
@UserCustomAnnotation
class MyEntityDto {
//fields
} Then there will be an SPI; class MyAssertJGeneratorProvider implements AssertJGeneratorProvider {
@Override
public List<Annotation> getSupportedAnnotations() {
return Arrays.asList(Entity.class, UserCustomAnnotation.class);
}
} The user will also need to provide a file named There is only one caveat which I thought about after creating the issue. That is the location where the generated
The main reason why I opened this issue is to have a better integration within IntelliJ and Maven. IntelliJ does it's own build, so in order to update the assertions I have to invoke the plugin manually. Maybe InteliiJ plugin is a better idea :) |
Writing IDE plugins is the way to go, I tried a few years ago to write an eclipse plugin without much success (very little doc for that). A plugin that would let you select a class or a package and generate assertions for it would be awesome. I have split the generator from the maven plugin to be able to reuse it from IDEs. |
You are right. IDE plugins are the way to go. Do you think creating issues for the Eclipse and IntelliJ plugins makes sense? Maybe someone will pick them up if they see them. I also tried writing an IntelliJ plugin for another project and I am also having problems with the documentation |
IDE plugins should have their own project like the maven plugin, I'm happy to create one here or better in the assertj organization which I plan to migrate all projects to. For an eclipse plugin I would start from https://github.com/maximeAudrain/jenerate as it allows you to generate code (equals and hashcode). |
Completely agree with you. Each plugin belongs to it's own project. If you have one location where you plan extensions or additional repositories for AssertJ, I would say we create 2 issues in there. For IntelliJ plugin this are some that are good to start from:
|
just created https://github.com/assertj/assertj-assertions-generator-idea-plugin. |
@joel-costigliola I can certainly try. The only thing is that I don't have any experience with idea plugin and we'll need some time to make this work. I'll also need to look at the generator code, so I can understand how it interacts. I can try to do #97 first, I think with that I'll have better understanding of the code. |
Sounds like a good plan |
@filiphr I have sent you an invite to be a collaborator of https://github.com/assertj/assertj-assertions-generator-idea-plugin. |
I think we could resurrect this. I've recently been playing around with the Immutables and Mapstruct projects (brilliant stuff), and I think the same process could be used to generate custom assertions without annotating our existing code and would NOT require any IDE plugins. So for the following model...
we would create our assertions interface with the the new annotation:
which would create the following classes:
I'm still not sure about where the annotation should be placed. You could have a
or specifiy the classes as well:
or the classes directly:
This could then be integrated with the Immutables project (maybe?) so that customs assertions could generated when the immutables class are generated. Thoughts? |
I haven't much experience with annotator processor but here's my 2cents. I would go with this:
The annotation should be put in a test scope class, we don't want to have any assertj artefacts for the production code.
Are you referring to using this for Immutables as a concrete usage ? |
Kind of. From my usage of Immutables, it would seem that while the Immutables annotation processor is running it could optionally use the generator in AssertJ to create assertions. You can see this cooperation happening between Mapstruct and Immutables. If Mapstruct sees Immutables on the path, then it will use the builder generated by immutables when performing mappings. I believe this is where real innovation can happen :) |
Have you considered having an annotation processor that can be used for the generator?
I think that it can be done without any direct dependency on AssertJ in the sources. The supported annotation can be some user defined annotation that would be found via an SPI, the configuration parameters can be controlled via APT options.
I haven't looked at the code, but I assume that the entire logic is in here, the maven-plugin just passes the options to the generator that does everything.
Is this something that would be interesting for the generator?
The text was updated successfully, but these errors were encountered: