> 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.
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]
