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

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Scott, what you describe below is what the sigtest tool does.
That's why we use it.  And that's why it needs to be enhanced
to address the problem I described.

The signature file generation is done when the TCK is being constructed,
we don't need it at testing time, but the same tool does both.

Scott Marlow wrote on 2/14/20 6:52 AM:
> On Thu, Feb 13, 2020 at 8:38 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>>
>> 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.
> 
> Would it be possible for the current signature driver code in the
> platform TCK, to be enhanced to generate signatures?  Currently, we
> verify that that EE implementation jars (on app server classpath) have
> the correct API signatures and that a deployment also has the correct
> API signatures, doesn't this mean that we can read the API signatures
> currently?  If we can read the signatures, does that mean we could
> generate them as well?
> 
> If this could work, we would only use the "generate signature files"
> mode when building the TCK but not include the generator class in the
> platform TCK distribution.
> 
>>
>>
>> -- 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.
> 
> +1 if someone could create a sigtest (JDK) pull request that solves this!
> 
>>
>> 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.
> 
> Scott
> 
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-community__;!!GqivPVa7Brio!MOOLzxwfPzTn5qD7lQ8NXTj4dhCK-20zTyGLVr7QbHSHP7Tp-zkQtuD23WjlCb7IdQ$ 
>