Clean up dependency mess #101
Assignees
Labels
type: improvement
A minor improvement to an existing feature
Comments
Merged
|
So I've been contemplating this and trying to figure out a solution, but that's indeed quite a mess. It seems to me that the easiest is simply to not reuse the model class, but add a different one. It's simply used for JSON mapping, so it feels a bit overkill to reuse an artifact for this. |
|
Okay, fair enough. The symlink is not a big issue either, but I could replace it with a simple copy of the model when the model stabilizes. |
melix
added a commit
that referenced
this issue
Jan 7, 2025
This commit reworks how the model class is "shared" between the annotation processor and the jazzer plugin. Instead of using a symlink, the code is now generated by a common build plugin. In practice, the 2 modules use the same record, but in a different package. It's also cleaner in the sense that there's no dependency between the plugin and the annotation processor, which would have led to too many classes on classpath. Fixes #101
Merged
|
I have created a PR which I think makes things a bit nicer. |
melix
added a commit
that referenced
this issue
Jan 7, 2025
This commit reworks how the model class is "shared" between the annotation processor and the jazzer plugin. Instead of using a symlink, the code is now generated by a common build plugin. In practice, the 2 modules use the same record, but in a different package. It's also cleaner in the sense that there's no dependency between the plugin and the annotation processor, which would have led to too many classes on classpath. Fixes #101
yawkat
pushed a commit
that referenced
this issue
Jan 7, 2025
This commit reworks how the model class is "shared" between the annotation processor and the jazzer plugin. Instead of using a symlink, the code is now generated by a common build plugin. In practice, the 2 modules use the same record, but in a different package. It's also cleaner in the sense that there's no dependency between the plugin and the annotation processor, which would have led to too many classes on classpath. Fixes #101
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue description
The dependency layout of this project is a bit messy at the moment.
fuzzing-testsandfuzzing-annotation-processorare normal modules.jazzer-pluginis a subproject that is used as a plugin infuzzing-tests. However,jazzer-pluginreads metadata generated byfuzzing-annotation-processor, so it needs a dependency on the model class, which right now is realized through a symlink.This is a very bad solution and I'd prefer an actual dependency on
fuzzing-annotation-processor. That doesn't work with the fact thatjazzer-pluginis a subproject, though. Maybe it's better to makejazzer-plugina normal module, andfuzzing-testsa subproject somehow?I'm also open to moving
fuzzing-teststo an entirely separate github project, if necessary. But I'd prefer to keep it here.The text was updated successfully, but these errors were encountered: