Just wanted to echo what Jean-Louis said and add some details. During the 20 years of these specs living in the JCP, the license requirements stated that you must agree to ship your implementation with all defaults set to the compliant state. You could have flags that enabled non-compliant behavior, but they would have to be off by default and require user action to turn them on.
If we encounter a situation where we don't pass a test, here are the valid
outcomes:
1. We decide to change our default behavior so we can pass the test.
We may chose to create a way to enable the previous behavior, but
we do not work that way by default.
2. We decide we think our behavior is spec-compliant and the TCK is
testing something not defined by or against the spec. We file a
TCK challenge.
A. Our challenge is approved. We can ignore that failure and
still claim compliance.
B. Our challenge is rejected.
i. We execute option #1 and ship a compliant implementation.
ii. We decide we don't care about compliance. Our users may
disagree and may need to patch or fork.
-David
> On May 24, 2022, at 5:12 PM, Jean-Louis MONTEIRO <jeano...@gmail.com> wrote:
>
> I always find it better when we can keep backward compatibility for users.
> But this is a major version and I'm not a big fan of cheap system properties.
>
> If we think it's not good, we should create a challenge to get it fixed in
> the spec + TCK.
> Otherwise, I would keep it the way it is. If it breaks users and we want to
> help them out, it's still time to add the system property or a better
> configuration option and do a maintenance release.
>
> I'd go lazy instead of eager considering it's a major version.
> Meanwhile, I'd create an issue on the TCK + Spec
>
>
> Le mar. 24 mai 2022 à 13:21, Zowalla, Richard
> <richard.zowa...@hs-heilbronn.de> a écrit :
> Romain mentioned the idea (via Slack) of introducing a (cheap) system
> property, which a user can specifiy to get back the old behaviour.
>
> If we want to follow the compatibility appraoch, we should add that
> flag as the spec / RI is really unclear.
>
>
> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
> > I conclude the same thing thanks your pointers so back to the
> > question: do we want to maintain the compat for our user base, do we
> > want to align on the random spec behavior or do we don't care?
> > Indeed I'm always in first team, in particular there since it will be
> > deprecated so the least we touch the best it is but guess it is a 50-
> > 50 case in terms of actual points :s.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > The test in question is
> > > https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
> > >
> > > which expects the plain parameter value instead of
> > > "parameter=value" as
> > > a return value.
> > >
> > > The JavaDoc is also not quite clear about it:
> > >
> > > https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
> > >
> > > with "This method is called for each parameter name/value pair and
> > > should return the normalized representation of the
> > > parameterValue.".
> > >
> > > The spec document itself
> > > https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
> > > doesn't mention anything about it.
> > >
> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
> > > there)
> > > to keep compatibility after removing the references to it.
> > >
> > > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
> > > Bucau:
> > > > Hmm, before that the question is "are the TCK spec compliant", a
> > > lot
> > > > have a reference in the spec we maybe missed, do you have some
> > > > pointers on them? If we were wrong let's fix it, if the TCK are
> > > wrong
> > > > then maybe ignore the TCK?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> > > >
> > > >
> > > > Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > There is a TCK test regarding normalizeMimeTypeParameter which
> > > > > broke with the current impl of normalizeMimeTypeParameter
> > > > >
> > > > > Therefore, I adjusted it but agree that it is mit really
> > > specified.
> > > > > Question would be, if it is "ok" to fail specific tests of the
> > > TCK.
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > > Von: Romain Manni-Bucau <rmannibu...@gmail.com>
> > > > > Gesendet: Dienstag, 24. Mai 2022 11:53:37
> > > > > An: dev@geronimo.apache.org
> > > > > Betreff: Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
> > > > >
> > > > > Not voting negatively but seems we
> > > > > broke normalizeMimeTypeParameter (I guess copying the RI?) and
> > > I'm
> > > > > not sure it should be done.
> > > > > From my understanding this part is not well specified and
> > > highly
> > > > > depends on the impl but I don't see a reson to break existing
> > > > > consumers which I always favor in regards of being aligned on
> > > the
> > > > > RI.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
> > > > >
> > > > >
> > > > > Le mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com> a écrit :
> > > > > > Here we go
> > > > > >
> > > > > > We now pass all TCK and signature tests. Thanks Richard.
> > > > > >
> > > > > > This is essentially the same as the M1 David did last week
> > > but
> > > > > > with the fixes for compliance (See GERONIMO-6832)
> > > > > >
> > > > > > Here is the link for sources
> > > > > >
> > > https://dist.apache.org/repos/dist/dev/geronimo/activation_2.0_spec/
> > > > > >
> > > > > > Here is the svn tag
> > > > > >
> > > https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-activation_2.0_spec-1.0.0/
> > > > > >
> > > > > > Here is the staging repo
> > > > > >
> > > https://repository.apache.org/content/repositories/orgapachegeronimo-1155
> > > > > >
> > > > > > Please vote to approve this release:
> > > > > > [ ] +1 Approve the release
> > > > > > [ ] 0 Abstain (please provide specific comments)
> > > > > > [ ] -1 Don't approve the release (please provide specific
> > > > > > comments)
> > > > > >
> > > > > > This vote will be open for at least 72 hours.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
>
>
> --
> Jean-Louis
smime.p7s
Description: S/MIME cryptographic signature
