Re: [jakarta.ee-community] Help wanted: improved signature test tool

[Mark Thomas <markt@xxxxxxxxxx>]

On 14/02/2020 16:45, Andy Guibert wrote:
>>  Not true. Apache Tomcat ships its own ALv2 licensed API JARs and I don't
>> see that changing any time soon.
> 
> JavaEE API jars were CDDL/GPL licensed, but JakartaEE API jars are EPLv2
> licensed which are far more permissive. With the new EPLv2 licesned API
> jars, will Tomcat still need to repackage as APLv2?

It isn't a repackaging. It is an independent implementation.

And yes, I think Tomcat will continue to provide those JARs.

During the development phase of a spec iteration, being able to
experiment with variations of the API without having to wait for an
upstream release is very useful. For example, the feedback obtained via
Tomcat during the development of the HttpServletMapping API.

Yes there is a maintenance cost but that is outweighed by the benefits.
If that balance changes, I expect the decision will be revisited. But,
as I said, I don't see that changing any time soon.

Mark


> 
> On Fri, Feb 14, 2020 at 8:44 AM Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
> 
>     On 14/02/2020 14:19, Andy Guibert wrote:
>     > Hi Bill,
>     >
>     > When I was porting JSON-B TCK tests out of the JT harness I came
>     across
>     > this topic. IIRC SigTest is part of the TCK because in the old days of
>     > JavaEE we didn't actually ship an API jar that implementations could
>     > include -- all of the implementations had to write up the API
>     > classes/interfaces themselves.
>     >
>     > Nowadays all of the implementations just pull in the API jars from
>     Maven
>     > Central and expose them in the runtime,
> 
>     Not true. Apache Tomcat ships its own ALv2 licensed API JARs and I don't
>     see that changing any time soon.
> 
>     > so SigTest doesn't really
>     > provide any testing value for implementations.
> 
>     Because of the above, I disagree.
> 
>     Mark
> 
> 
>     > However, SigTest can be useful for detecting API changes as specs
>     > evolve, particularly to make sure we follow semantic versioning
>     rules in
>     > the API. For this, I suggest we use a maven plugin called
>     > "bnd-baseline-maven-plugin" [1]. This plugin essentially scans the
>     > produced API jar at build time and compares it to the previous version
>     > to ensure that semantic versioning rules are followed.
>     >
>     >
>     [1] https://github.com/bndtools/bnd/tree/master/maven/bnd-baseline-maven-plugin
>     >
>     > --
>     > Andy
>     >
>     > On Thu, Feb 13, 2020 at 7:38 PM Bill Shannon
>     <bill.shannon@xxxxxxxxxx <mailto:bill.shannon@xxxxxxxxxx>
>     > <mailto:bill.shannon@xxxxxxxxxx <mailto:bill.shannon@xxxxxxxxxx>>>
>     wrote:
>     >
>     >     -- Background
>     >
>     >     Part of our TCK test suites is a signature test that verifies that
>     >     the API
>     >     signatures of an implementation match what's expected from the
>     >     specification.
>     >     The signature test is based on a file that records the API
>     >     signatures.  The
>     >     sigtest tool [1] (part of the OpenJDK project) is used to generate
>     >     the signature
>     >     file base on a "reference implementation" - an implementation that
>     >     is believed
>     >     to exhibit the correct signatures.
>     >
>     >     The recorded signatures include every field and method in every
>     >     class and
>     >     interface in the API, as well as the information for every
>     superclass or
>     >     interface.  A consequence of this is that it records the
>     signatures of
>     >     every JDK class used by the API.
>     >
>     >     That means that a different signature file is needed to test
>     an API on
>     >     JDK 12 vs JDK 11 (for example), even though the API works
>     identically on
>     >     both.  There's no way to say "this API requires JDK 11 or newer".
>     >
>     >     There are some features in the sigtest tool that seem like
>     they should
>     >     work to limit the recorded signatures to only the API being
>     tested, or
>     >     to exclude the signatures for JDK classes, but these features
>     have never
>     >     worked the way I wanted them to work.  I've tried for years to
>     convince
>     >     the sigtest team of what I wanted, but their perspective is
>     that of
>     >     testing
>     >     the JDK itself, which obviously never has this problem.
>     >
>     >
>     >     -- Help Wanted
>     >
>     >     I'd love it if someone in the Jakarta EE community could work
>     with the
>     >     sigtest team, explain to them what's needed, and help them
>     make the
>     >     existing
>     >     features work as needed, or create new features to do what we
>     need.
>     >
>     >     Worst case, someone could fork the sigtest tool and add the
>     feature that
>     >     we need.  The obvious disadvantage of this approach is that
>     the tool
>     >     would need to be kept up to date with every new JDK release. 
>     We need
>     >     a long term solution, not a one-off solution.
>     >
>     >     If you're interested, you should start by familiarizing yourself
>     >     with the
>     >     existing sigtest tool, try it out with a few APIs, then contact me
>     >     for more
>     >     background.
>     >
>     >     Thanks for any help!
>     >
>     >
>     >     P.S.  I've filed a bug [2] against the platform TCK that can
>     be used
>     >     to track
>     >     any work in this area.
>     >
>     >
>     >     [1] https://wiki.openjdk.java.net/display/CodeTools/sigtest
>     >     [2] https://github.com/eclipse-ee4j/jakartaee-tck/issues/156
>     >     _______________________________________________
>     >     jakarta.ee-community mailing list
>     >     jakarta.ee-community@xxxxxxxxxxx
>     <mailto:jakarta.ee-community@xxxxxxxxxxx>
>     >     <mailto:jakarta.ee-community@xxxxxxxxxxx
>     <mailto:jakarta.ee-community@xxxxxxxxxxx>>
>     >     To change your delivery options, retrieve your password, or
>     >     unsubscribe from this list, visit
>     >     https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>     >
>     >
>     > _______________________________________________
>     > jakarta.ee-community mailing list
>     > jakarta.ee-community@xxxxxxxxxxx
>     <mailto:jakarta.ee-community@xxxxxxxxxxx>
>     > To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     > https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>     >
> 
>     _______________________________________________
>     jakarta.ee-community mailing list
>     jakarta.ee-community@xxxxxxxxxxx
>     <mailto:jakarta.ee-community@xxxxxxxxxxx>
>     To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
> 
> 
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>