+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 <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
--
--
François
