On Thu, 26 Mar 2026 at 12:13, Rob Tompkins <[email protected]> wrote: > > > > > On Mar 26, 2026, at 7:55 AM, sebb <[email protected]> wrote: > > > > On Thu, 26 Mar 2026 at 11:37, Elliotte Rusty Harold <[email protected]> > > wrote: > >> > >> On Wed, Mar 25, 2026 at 7:58 PM Thomas Vandahl <[email protected]> wrote: > >>> > >>> Hi folks, > >>> > >>> I would like to build the site for JCS 4.0.0. The japicmp report wants to > >>> compare the current jar with the previous one. In commons-parent, the > >>> configuration uses <artifactId>${project.artifactId}</artifactId> with > >>> the <version>${commons.bc.version}</version>. > >>> > >>> Now, as the rule for major releases is to change the artifactId (from > >>> commons-jcs3-core to commons-jcs4-core), this reference point to > >>> commons-jcs4-core:3.2.1, which of course doesn't exist. > >> > >> Did the Java package name also change? They need to be synced with the > >> artifact ID. > > > > Agreed. > > > > But does japicmp really apply to major version changes? > > These will generally involve breaking API changes. > > Perhaps it’s nice to see for the purposes of version migration from a user > perspective. But, from a validation perspective your point is correct the > report provides moot evidence. > > > > > It should be possible to override the previous version of the jar, but > > this will presumably report everything as a difference, which would > > not be particularly useful. > > > > I don't think japicmp has an option to ignore package name changes, so > > one of the jars would need to be shaded so the two jars used the same > > package names. > > > > I don't know how easy this would be to do in Maven; probably best to > > try manually first. > > +/- 0 on inclusion for major version changes. May help with forward adoption, > but also may be confusing and klugey (unclear to me which is better). If we > were to use it to write migration path documentation then set aside the > japicmp and kept the documentation that would be ideal, but alas forward > progress needs to be mindful of project workload/capacity. I know not what to > do.
AFACT japicmp has a standalone version, and I have just found what is billed as a standalone version of maven shading. This looks easy to use: https://github.com/lucko/jar-relocator If no-one beats me to it, I might try it ... Sebb > Good ideas, good conversation! > > Thank you Elliotte, Sebb, Thomas! > > Cheers, > -Rob > > > > > Sebb > > > >> -- > >> Elliotte Rusty Harold > >> [email protected] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
