+1 On Mon, Jun 20, 2022 at 6:57 AM Jean-Louis MONTEIRO <jeano...@gmail.com> wrote:
> Is there any interest to vote on this one? > > Le lun. 30 mai 2022 à 16:10, Jean-Louis MONTEIRO <jeano...@gmail.com> a > écrit : > >> up ... >> >> Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau <rmannibu...@gmail.com> >> a écrit : >> >>> +1 after the discussion in the other thread and points Richard raised >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> Le mer. 25 mai 2022 à 02:13, Jean-Louis MONTEIRO <jeano...@gmail.com> a >>> écrit : >>> >>>> here is my own +1 (binding) >>>> >>>> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO <jeano...@gmail.com> >>>> a écrit : >>>> >>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> Jean-Louis >>>> >>> >> >> -- >> Jean-Louis >> > > > -- > Jean-Louis > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
