I don't know the technical details, but I think it's just natural that you need some sort of an adapter that maps each parser into the Jenkins plugin. Yeah, it will add some code (but you shouldn't need to duplicate code). That's the price you must pay for separation of concerns. However, you will collect the benefits later on.
Yes, it's no duplication, just a wrapper for each parser and model class. I've done this for the parsers of the violations plugin already quite some time ago, see ViolationsAdapter. (Note that this implementation is working only partly, since the parsers of the violations plug-in are not serializable and will not work on slave builds.)
Would it be possible to somehow, dynamically resolve and construct these adapters, so that you wouldn't have to explicitly write each?
Yes, see ViolationsRegistry.
Sounds good. I'm sure you'll come to terms about dependency libraries if you work on this: use what you need, omit what you don't. You'll start with what you got (minus the Jenkins dependencies), and if Tomas wants less dependencies, I'm sure he's quick to refactor the code.
Besides, you can still depend on more dependencies in warnings-plugin. It's just violations-lib that should be minimal.
If you got tests there, it's less likely that things will break.
Yes, if you want to replace the parsers with something simpler, go ahead
I just don't have the time to replace existing and working (and tested) code with something that produces the same results in a different way
Tell them they should really fix their code
I tried but this issue pops up from time to time
I know I'm over-simplifying things but you should "just":
1. Tomas copies/merges the parsers from warnings-plugin into violations-lib.
2. Agree/ensure on the parser API in violations-lib.
3. Ulli switches from built-in parsers into violations-lib. Put whatever you need there, we'll have just single parser implementations in the end, which is the goal of this ticket. You can tune things later on, if need be.
Even if steps 2-3 never succeed, there's benefit in step one, as violations-lib will get quite a few parsers that are now missing.
I think this is a feasible approach. I think 2 should be done before 1: otherwise a lot of things will break afterwards.
Yes, it's no duplication, just a wrapper for each parser and model class. I've done this for the parsers of the violations plugin already quite some time ago, see ViolationsAdapter. (Note that this implementation is working only partly, since the parsers of the violations plug-in are not serializable and will not work on slave builds.)
Yes, see ViolationsRegistry.
Yes, if you want to replace the parsers with something simpler, go ahead
I just don't have the time to replace existing and working (and tested) code with something that produces the same results in a different way
I tried but this issue pops up from time to time
I think this is a feasible approach. I think 2 should be done before 1: otherwise a lot of things will break afterwards.