You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2022/05/24 09:44:45 UTC
[VOTE] Geronimo activation_2.0_spec 1.0.0
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
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Raymond Augé <ra...@liferay.com>.
+1
On Mon, Jun 20, 2022 at 6:57 AM Jean-Louis MONTEIRO <je...@gmail.com>
wrote:
> Is there any interest to vote on this one?
>
> Le lun. 30 mai 2022 à 16:10, Jean-Louis MONTEIRO <je...@gmail.com> a
> écrit :
>
>> up ...
>>
>> Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau <rm...@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 <je...@gmail.com> a
>>> écrit :
>>>
>>>> here is my own +1 (binding)
>>>>
>>>> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO <je...@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.zowalla@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.zowalla@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.zowalla@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 <rm...@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 <
>>>>>> > > > > jlmonteiro@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
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by fpapon <fp...@apache.org>.
+1 (binding)
regards,
On 20/06/2022 12:57, Jean-Louis MONTEIRO wrote:
> Is there any interest to vote on this one?
>
> Le lun. 30 mai 2022 à 16:10, Jean-Louis MONTEIRO <je...@gmail.com>
> a écrit :
>
> up ...
>
> Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau
> <rm...@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
> <je...@gmail.com> a écrit :
>
> here is my own +1 (binding)
>
> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO
> <je...@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
> <ri...@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.zowalla@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.zowalla@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
> <rm...@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 <
> > > > > jlmonteiro@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
--
--
François
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Is there any interest to vote on this one?
Le lun. 30 mai 2022 à 16:10, Jean-Louis MONTEIRO <je...@gmail.com> a
écrit :
> up ...
>
> Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau <rm...@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 <je...@gmail.com> a
>> écrit :
>>
>>> here is my own +1 (binding)
>>>
>>> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO <je...@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.zowalla@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.zowalla@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.zowalla@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 <rm...@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 <
>>>>> > > > > jlmonteiro@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
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
up ...
Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau <rm...@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 <je...@gmail.com> a
> écrit :
>
>> here is my own +1 (binding)
>>
>> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO <je...@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.zowalla@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.zowalla@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.zowalla@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 <rm...@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 <
>>>> > > > > jlmonteiro@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
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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 <je...@gmail.com> a
écrit :
> here is my own +1 (binding)
>
> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO <je...@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.zowalla@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.zowalla@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.zowalla@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 <rm...@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 <
>>> > > > > jlmonteiro@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
>
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
here is my own +1 (binding)
Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO <je...@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.zowalla@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.zowalla@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.zowalla@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 <rm...@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 <
>> > > > > jlmonteiro@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
Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Right, because the issue is not people having migrated but people migrating
when jakarta releases are available so think you are right, it covers
something like 0 user ;)
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 à 09:56, Zowalla, Richard <
richard.zowalla@hs-heilbronn.de> a écrit :
> Hi,
>
> JL wrote "Meanwhile, I'd create an issue on the TCK + Spec" in another
> mail and as I want to learn something about the involved workflows /
> processes (sorry - never had to deal with it):
>
> - What would we need to do to challenge the TCK + Spec in this regard?
> - Who can do this - I assume it is vendor-driven, so PMC?
> - Is it something super time consuming?
> - Is it opening an issue and writing some elaborated text explaining
> the situation / unclarity?
>
> I guess, that the user community who already migrated to jakarta.*
> isn't that big at the moment (my assumption), so perhaps there is
> enought time to open a challenge and clarify the situation. If users
> complain, we can go still do a "bug" fix release?
>
> Gruß
> Richard
>
>
>
> Am Mittwoch, dem 25.05.2022 um 09:03 +0200 schrieb Romain Manni-Bucau:
> > Hi
> >
> > The small notes on that are:
> >
> > - rare impl actually do (asf ones but also other vendors), it is
> > always a compromise between users/customers/consumers and specs
> > - there is always a blurry line on some defaults (trivial example is
> > default impl or provider impl even when defined in spec)
> > - another blurry line is for libs vs distros
> >
> > So overall we are still free to choose in most cases even if we
> > should tend to what you described.
> >
> > Side note: I dont want to emphasize the disrespect of that rule but
> > the fact *we* must choose at the end.
> >
> >
> > Le mer. 25 mai 2022 à 03:20, David Blevins <da...@gmail.com>
> > a écrit :
> > > > On May 24, 2022, at 6:14 PM, David Blevins <
> > > david.blevins@gmail.com> wrote:
> > > >
> > > > 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.
> > >
> > > To be clear I could have used a better word than "flags." You can
> > > have any means you like to enable non-compliant behavior such as
> > > annotations, alternate jars, etc. Anything that must be done
> > > explicitly by a user to put themselves knowingly in a non-compliant
> > > state.
> > >
> > >
> > > -David
> > >
>
Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi,
JL wrote "Meanwhile, I'd create an issue on the TCK + Spec" in another
mail and as I want to learn something about the involved workflows /
processes (sorry - never had to deal with it):
- What would we need to do to challenge the TCK + Spec in this regard?
- Who can do this - I assume it is vendor-driven, so PMC?
- Is it something super time consuming?
- Is it opening an issue and writing some elaborated text explaining
the situation / unclarity?
I guess, that the user community who already migrated to jakarta.*
isn't that big at the moment (my assumption), so perhaps there is
enought time to open a challenge and clarify the situation. If users
complain, we can go still do a "bug" fix release?
Gruß
Richard
Am Mittwoch, dem 25.05.2022 um 09:03 +0200 schrieb Romain Manni-Bucau:
> Hi
>
> The small notes on that are:
>
> - rare impl actually do (asf ones but also other vendors), it is
> always a compromise between users/customers/consumers and specs
> - there is always a blurry line on some defaults (trivial example is
> default impl or provider impl even when defined in spec)
> - another blurry line is for libs vs distros
>
> So overall we are still free to choose in most cases even if we
> should tend to what you described.
>
> Side note: I dont want to emphasize the disrespect of that rule but
> the fact *we* must choose at the end.
>
>
> Le mer. 25 mai 2022 à 03:20, David Blevins <da...@gmail.com>
> a écrit :
> > > On May 24, 2022, at 6:14 PM, David Blevins <
> > david.blevins@gmail.com> wrote:
> > >
> > > 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.
> >
> > To be clear I could have used a better word than "flags." You can
> > have any means you like to enable non-compliant behavior such as
> > annotations, alternate jars, etc. Anything that must be done
> > explicitly by a user to put themselves knowingly in a non-compliant
> > state.
> >
> >
> > -David
> >
Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
The small notes on that are:
- rare impl actually do (asf ones but also other vendors), it is always a
compromise between users/customers/consumers and specs
- there is always a blurry line on some defaults (trivial example is
default impl or provider impl even when defined in spec)
- another blurry line is for libs vs distros
So overall we are still free to choose in most cases even if we should tend
to what you described.
Side note: I dont want to emphasize the disrespect of that rule but the
fact *we* must choose at the end.
Le mer. 25 mai 2022 à 03:20, David Blevins <da...@gmail.com> a
écrit :
> > On May 24, 2022, at 6:14 PM, David Blevins <da...@gmail.com>
> wrote:
> >
> > 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.
>
> To be clear I could have used a better word than "flags." You can have
> any means you like to enable non-compliant behavior such as annotations,
> alternate jars, etc. Anything that must be done explicitly by a user to
> put themselves knowingly in a non-compliant state.
>
>
> -David
>
>
Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)
Posted by David Blevins <da...@gmail.com>.
> On May 24, 2022, at 6:14 PM, David Blevins <da...@gmail.com> wrote:
>
> 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.
To be clear I could have used a better word than "flags." You can have any means you like to enable non-compliant behavior such as annotations, alternate jars, etc. Anything that must be done explicitly by a user to put themselves knowingly in a non-compliant state.
-David
Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)
Posted by David Blevins <da...@gmail.com>.
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 <je...@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 <ri...@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.zowalla@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.zowalla@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 <rm...@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 <
> > > > > jlmonteiro@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
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
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.zowalla@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.zowalla@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.zowalla@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 <rm...@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 <
> > > > > jlmonteiro@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
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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.zowalla@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.zowalla@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 <rm...@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 <
> > > > jlmonteiro@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
> > > > >
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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 mar. 24 mai 2022 à 12:57, Zowalla, Richard <
richard.zowalla@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.zowalla@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 <rm...@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 <
> > > jlmonteiro@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
> > > >
>
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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.zowalla@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 <rm...@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 <
> > jlmonteiro@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
> > >
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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 mar. 24 mai 2022 à 12:33, Zowalla, Richard <
richard.zowalla@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 <rm...@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 <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 mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <jl...@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
>>
>
AW: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
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 <rm...@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<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 mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <jl...@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<http://www.tomitribe.com/>
Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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 mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <jl...@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
>
[VOTE RESULT] Geronimo activation_2.0_spec 1.0.0
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Hi!
Vote passed with 4 +1 and no other votes. I'll proceed.
Thanks so much everyone.
JLouis
Le mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro <jl...@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