japicmp
japicmp copied to clipboard
siom79
Build fails if new artifact removes a class even with major version change
I'm using <breakBuildBasedOnSemanticVersioning>true</breakBuildBasedOnSemanticVersioning> to enforce proper semantic versioning in my maven builds.
I think removing a class is allowed if I bump the major version, but the plugin fails the build, and suggests I add --ignore-missing-classes.
Removing a class is not a compatible change. What if someone is already using it?
tecywiz121 [email protected] schrieb am Do., 14. Dez. 2017, 07:09:
I'm using <breakBuildBasedOnSemanticVersioning>true</breakBuildBasedOnSemanticVersioning> to enforce proper semantic versioning in my maven builds.
I think removing a class is allowed if I bump the major version, but the plugin fails the build, and suggests I add --ignore-missing-classes.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtGOhLFqSTpK-Ur5CeIkjjNuTeJKMks5tALu0gaJpZM4RBlw6 .
Can you post the complete output?
twogee [email protected] schrieb am Do., 14. Dez. 2017, 08:34:
What about change of Java version? #168 https://github.com/siom79/japicmp/issues/168
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190#issuecomment-351631178, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtLGKQQmvPH1he7qEw3coYTOmXwz-ks5tAM9zgaJpZM4RBlw6 .
Tried to create a minimal working example and realized that the class that was removed was in a dependency, not in the jar I'm trying to compare.
I'll finish up an example still if you think that'll help.
This explains the ignore missing classes hint you have seen. The tool does not compare the transitive dependencies, too. Hence you don't have to provide an example.
tecywiz121 [email protected] schrieb am Do., 14. Dez. 2017, 17:07:
Tried to create a minimal working example and realized that the class that was removed was in a dependency, not in the jar I'm trying to compare.
I'll finish up an example still if you think that'll help.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190#issuecomment-351755319, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtANFq_Vh-_lwqK5092LAM21DsiHnks5tAUejgaJpZM4RBlw6 .
It still fails the build when this happens, which I think is incorrect.
Should the ignore missing classes option be enabled automatically when the major version changes? Or is it relatively safe to ignore missing classes all the time?
What relation does your code have to the missing class? Why does it compile without this class?
tecywiz121 [email protected] schrieb am Do., 14. Dez. 2017, 17:50:
It still fails the build when this happens, which I think is incorrect.
Should the ignore missing classes option be enabled automatically when the major version changes? Or is it relatively safe to ignore missing classes all the time?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190#issuecomment-351768713, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtLTXW67xnRjQZi0KoB4w544rKJO4ks5tAVHDgaJpZM4RBlw6 .
We're doing some restructuring, and we moved the class into a different package. The new code has been updated to point at the new location.
Have you tried to configure japicmp using multiple old version artefacts? This way you can for example create one report for all of your artefacts in the parent pom file.
tecywiz121 [email protected] schrieb am Do., 14. Dez. 2017, 19:54:
We're doing some restructuring, and we moved the class into a different package. The new code has been updated to point at the new location.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190#issuecomment-351802658, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtLTN75Kq_5DWC5u_AxowT0Imk_zOks5tAW7VgaJpZM4RBlw6 .
I'm not sure what you mean. What are multiple old version artifacts?
We don't actually have a single parent pom file. All of the projects build independently, which is why we care so much about semantic versioning.
Take a at this pom in the integration tests of japicmp: https://github.com/siom79/japicmp/blob/master/japicmp-testbase/japicmp-test-maven-plugin/pom.xml
The execution multiple version shows how to specify more than one jar file.
If you have separate projects you could create a new project for japicmp reporting and reference all the single projects there.
tecywiz121 [email protected] schrieb am Do., 14. Dez. 2017, 22:36:
I'm not sure what you mean. What are multiple old version artifacts?
We don't actually have a single parent pom file. All of the projects build independently, which is why we care so much about semantic versioning.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190#issuecomment-351843100, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtAbQkInmPrjd9PDWrtk_4bRJFbiDks5tAZTYgaJpZM4RBlw6 .
Ah, I think I see what you're saying. Do one giant japicmp for everything so that nothing is a transitive dependency.
That seems a little impractical since we'll have to include every dependency from every project (in case a dependency we use removes a class.) Is that correct, or am I misunderstanding?
Yes, you would need to include every dependency from every project that you consider to be part of the API.
But somehow you must specify what is your API and what is not. Or do you have a better idea?
tecywiz121 [email protected] schrieb am Do., 14. Dez. 2017, 22:57:
Ah, I think I see what you're saying. Do one giant japicmp for everything so that nothing is a transitive dependency.
That seems a little impractical since we'll have to include every dependency from every project (in case a dependency we use removes a class.) Is that correct, or am I misunderstanding?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/siom79/japicmp/issues/190#issuecomment-351848432, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPtBNocsWPJXw4aAo9841eqDBxHaUEks5tAZnYgaJpZM4RBlw6 .
I think it'd be much easier to automatically ignore missing classes if the major version changes. You sidestep the whole "what is part of the api" question.
@siom79: I am seeing this problem too. I'm not sure I understand, is this behaviour by design? Why is a missing class not just marked as an incompatibility instead of an error?
