Re: [VOTE] Move ahead with creating a reusable JWT module

[David Blevins]

Ah.  My intention was a +1 would mean "We should create new JWT module in 
Geronimo now, regardless of what TomEE is discussing."

Not "can we ever" in a general sense, but should we do it right now.

If someone would like to wait a bit longer, they should not vote +1.  It could 
still happen later of course.


-David

> On Mar 18, 2018, at 7:32 PM, John D. Ament  wrote:
> 
> Just to make sure I understand.  a +1 on this to me means there may be a 
> module created in geronimo.  Maybe not.  But either way it shouldn't stop 
> what TomEE is doing.
> 
> On Sun, Mar 18, 2018 at 8:59 PM David Blevins  wrote:
> My vote would be -0 and I hesitate even for a negative anything.
> 
> I think the "Geronimo will do it anyway, collaborate or not" perspective 
> feels a bit like an ultimatum.  That said, if people truly do want to move on 
> regardless of what happens in TomEE, that's exactly what should happen.
> 
> I feel strongly that a project should not be obstructed by other projects who 
> feel ownership over an domain, be forced to collaborate, or otherwise be 
> stopped in their tracks.
> 
> Here's how I'd like my vote read:
> 
>  - Waiting to see what TomEE decides or creates would be ideal in my mind, 
> but not necessary if there is support for moving forward
> 
>  - I wouldn't help, but I wouldn't stand in the way
> 
>  - I continue to have reservations naming reusable components after a dead 
> app server.  I managed to have all my best efforts remain perfectly invisible 
> under the name "OpenEJB" and "EJB."  If people want to put effort into 
> reforming the 15 year-old Geronimo brand, they are welcome to do so, but I 
> can't sign up for that again.  I can't pretend this isn't a significant 
> obstacle.
> 
>  - I continue to feel we'd be stronger together (TomEE and Geronimo).  With 
> these false lines making everyone have to get commit twice and hiding our 
> best work under a dead website and brand, we aren't getting the strength and 
> speed we need.
> 
> 
> As long as I feel understood, not pushed into doing something I don't want to 
> do, I'm more than happy.
> 
> 
> -David
> 
> > On Mar 18, 2018, at 5:05 PM, David Blevins  wrote:
> >
> > Two votes are up in the TomEE community on what to do with PR #123 ( 
> > https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE 
> > should merge it.  The second vote is if TomEE should attempt to extract it.
> >
> > It was said 3-4 times in the discussion between both communities "geronimo 
> > will have a jwt-auth impl."  This is absolutely ok, there is no rule that 
> > two projects cannot do the same or similar thing.  Apache Tamaya exists and 
> > there is a Geronimo Config, both aim at MicroProfile Config compliance.  
> > This is OK by ASF standards and one community is not judged good or bad for 
> > choosing to also implement something.
> >
> > That said, decisions like this should be made by the project clearly.  Some 
> > people may want to move ahead now.  Some people may want to wait and see 
> > how things go with TomEE.
> >
> > Vote: Move ahead with creating a reusable JWT module
> >
> > +1 Let's get on this, now.  There may be two impls, but that's ok.
> > -+0
> > -1 Let's wait / maybe later / other
> >
> >
> > -David
> >
> 

Re: [VOTE] Move ahead with creating a reusable JWT module

[John D. Ament]

Just to make sure I understand.  a +1 on this to me means there may be a
module created in geronimo.  Maybe not.  But either way it shouldn't stop
what TomEE is doing.

On Sun, Mar 18, 2018 at 8:59 PM David Blevins 
wrote:

> My vote would be -0 and I hesitate even for a negative anything.
>
> I think the "Geronimo will do it anyway, collaborate or not" perspective
> feels a bit like an ultimatum.  That said, if people truly do want to move
> on regardless of what happens in TomEE, that's exactly what should happen.
>
> I feel strongly that a project should not be obstructed by other projects
> who feel ownership over an domain, be forced to collaborate, or otherwise
> be stopped in their tracks.
>
> Here's how I'd like my vote read:
>
>  - Waiting to see what TomEE decides or creates would be ideal in my mind,
> but not necessary if there is support for moving forward
>
>  - I wouldn't help, but I wouldn't stand in the way
>
>  - I continue to have reservations naming reusable components after a dead
> app server.  I managed to have all my best efforts remain perfectly
> invisible under the name "OpenEJB" and "EJB."  If people want to put effort
> into reforming the 15 year-old Geronimo brand, they are welcome to do so,
> but I can't sign up for that again.  I can't pretend this isn't a
> significant obstacle.
>
>  - I continue to feel we'd be stronger together (TomEE and Geronimo).
> With these false lines making everyone have to get commit twice and hiding
> our best work under a dead website and brand, we aren't getting the
> strength and speed we need.
>
>
> As long as I feel understood, not pushed into doing something I don't want
> to do, I'm more than happy.
>
>
> -David
>
> > On Mar 18, 2018, at 5:05 PM, David Blevins 
> wrote:
> >
> > Two votes are up in the TomEE community on what to do with PR #123 (
> https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE
> should merge it.  The second vote is if TomEE should attempt to extract it.
> >
> > It was said 3-4 times in the discussion between both communities
> "geronimo will have a jwt-auth impl."  This is absolutely ok, there is no
> rule that two projects cannot do the same or similar thing.  Apache Tamaya
> exists and there is a Geronimo Config, both aim at MicroProfile Config
> compliance.  This is OK by ASF standards and one community is not judged
> good or bad for choosing to also implement something.
> >
> > That said, decisions like this should be made by the project clearly.
> Some people may want to move ahead now.  Some people may want to wait and
> see how things go with TomEE.
> >
> > Vote: Move ahead with creating a reusable JWT module
> >
> > +1 Let's get on this, now.  There may be two impls, but that's ok.
> > -+0
> > -1 Let's wait / maybe later / other
> >
> >
> > -David
> >
>
>

Re: [VOTE] Move ahead with creating a reusable JWT module

[David Blevins]

My vote would be -0 and I hesitate even for a negative anything.

I think the "Geronimo will do it anyway, collaborate or not" perspective feels 
a bit like an ultimatum.  That said, if people truly do want to move on 
regardless of what happens in TomEE, that's exactly what should happen.

I feel strongly that a project should not be obstructed by other projects who 
feel ownership over an domain, be forced to collaborate, or otherwise be 
stopped in their tracks.

Here's how I'd like my vote read:

 - Waiting to see what TomEE decides or creates would be ideal in my mind, but 
not necessary if there is support for moving forward

 - I wouldn't help, but I wouldn't stand in the way

 - I continue to have reservations naming reusable components after a dead app 
server.  I managed to have all my best efforts remain perfectly invisible under 
the name "OpenEJB" and "EJB."  If people want to put effort into reforming the 
15 year-old Geronimo brand, they are welcome to do so, but I can't sign up for 
that again.  I can't pretend this isn't a significant obstacle.

 - I continue to feel we'd be stronger together (TomEE and Geronimo).  With 
these false lines making everyone have to get commit twice and hiding our best 
work under a dead website and brand, we aren't getting the strength and speed 
we need.


As long as I feel understood, not pushed into doing something I don't want to 
do, I'm more than happy.


-David

> On Mar 18, 2018, at 5:05 PM, David Blevins  wrote:
> 
> Two votes are up in the TomEE community on what to do with PR #123 ( 
> https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE 
> should merge it.  The second vote is if TomEE should attempt to extract it.
> 
> It was said 3-4 times in the discussion between both communities "geronimo 
> will have a jwt-auth impl."  This is absolutely ok, there is no rule that two 
> projects cannot do the same or similar thing.  Apache Tamaya exists and there 
> is a Geronimo Config, both aim at MicroProfile Config compliance.  This is OK 
> by ASF standards and one community is not judged good or bad for choosing to 
> also implement something.
> 
> That said, decisions like this should be made by the project clearly.  Some 
> people may want to move ahead now.  Some people may want to wait and see how 
> things go with TomEE.
> 
> Vote: Move ahead with creating a reusable JWT module
> 
> +1 Let's get on this, now.  There may be two impls, but that's ok.
> -+0 
> -1 Let's wait / maybe later / other
> 
> 
> -David
> 

Re: [VOTE] Move ahead with creating a reusable JWT module

[John D. Ament]

On Sun, Mar 18, 2018 at 8:05 PM David Blevins 
wrote:

> Two votes are up in the TomEE community on what to do with PR #123 (
> https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE
> should merge it.  The second vote is if TomEE should attempt to extract it.
>
>
Ok, this helps a lot.  Thanks David!



> It was said 3-4 times in the discussion between both communities "geronimo
> will have a jwt-auth impl."  This is absolutely ok, there is no rule that
> two projects cannot do the same or similar thing.  Apache Tamaya exists and
> there is a Geronimo Config, both aim at MicroProfile Config compliance.
> This is OK by ASF standards and one community is not judged good or bad for
> choosing to also implement something.
>

Yes, and with that said its even completely valid for us to take the code
from TomEE and drop it in to a separate Geronimo library, if that's the
route we take.  However, we would need to figure out what that dividing
line is in the code between standalone library & TomEE specific integration.


>
> That said, decisions like this should be made by the project clearly.
> Some people may want to move ahead now.  Some people may want to wait and
> see how things go with TomEE.
>
> Vote: Move ahead with creating a reusable JWT module
>
>  +1 Let's get on this, now.  There may be two impls, but that's ok.
>  -+0
>  -1 Let's wait / maybe later / other
>
>
>
+1 for what you've said.


> -David
>
>

[VOTE] Move ahead with creating a reusable JWT module

[David Blevins]

Two votes are up in the TomEE community on what to do with PR #123 ( 
https://github.com/apache/tomee/pull/123 ).  The first vote is if TomEE should 
merge it.  The second vote is if TomEE should attempt to extract it.

It was said 3-4 times in the discussion between both communities "geronimo will 
have a jwt-auth impl."  This is absolutely ok, there is no rule that two 
projects cannot do the same or similar thing.  Apache Tamaya exists and there 
is a Geronimo Config, both aim at MicroProfile Config compliance.  This is OK 
by ASF standards and one community is not judged good or bad for choosing to 
also implement something.

That said, decisions like this should be made by the project clearly.  Some 
people may want to move ahead now.  Some people may want to wait and see how 
things go with TomEE.

Vote: Move ahead with creating a reusable JWT module

 +1 Let's get on this, now.  There may be two impls, but that's ok.
 -+0 
 -1 Let's wait / maybe later / other


-David

Re: MP-JWT progress

[David Blevins]

> On Mar 18, 2018, at 2:38 PM, Romain Manni-Bucau  wrote:
> 
> Are you against/-1ing g-jwt-auth?

I wouldn't do that, but it's also clear to me the discussion in this thread can 
be significantly clearer.  Objections were made that weren't resolved.  The 
discussion started as what do "we" do with we meaning TomEE and Geronimo.  At 
some point in the middle it was stated Geronimo has already made a decision.  I 
also have the feeling people may have opinions that are in-between a full TomEE 
vs Geronimo decision, such as wanting to put work into inching closer to get a 
better view before deciding.

I think all these things are fine, but we need some healthy votes so people can 
move forward with clear support.


-David

Re: [VOTE] XBean 4.7 release

[John D. Ament]

On Sun, Mar 18, 2018 at 4:39 PM Romain Manni-Bucau 
wrote:

> Up John? Are you ok to change your vote to a -0 and not veto the release
> since we are good legally but just didnt respect a good practise?
>

-1's on releases are never vetos.  Very surprised you don't know this.  You
should review [1] and [2] esp since you're a new chair.

[1]: http://www.apache.org/legal/release-policy.html#release-approval
[2]: https://www.apache.org/foundation/voting.html



>
> If not I can rerun the release tomorrow and add another not standard file
> to replace our notice mention but i dont see any reason to require another
> vote for that for now.
>
>
> Le 15 mars 2018 07:11, "Romain Manni-Bucau"  a
> écrit :
>
>> @John: is it ok to keep it for this release and have another discuss
>> thread about it for you - legally we are ok anyway?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>> 2018-03-15 1:17 GMT+01:00 Mark Struberg :
>>
>>> I see. Note that the updated guideline does say 'need not' and not 'MUST
>>> NOT'.
>>> Yes we should probably remove it. But no, it's not a show stopper imo.
>>>
>>> LieGrue,
>>> strub
>>>
>>> > Am 15.03.2018 um 01:01 schrieb John D. Ament :
>>> >
>>> >
>>> >
>>> > On Wed, Mar 14, 2018 at 7:54 PM John D. Ament 
>>> wrote:
>>> > On Wed, Mar 14, 2018 at 7:43 PM Mark Struberg 
>>> wrote:
>>> > +1 it's not incorrect. Please read the BSD3c license
>>> >
>>> > > 1. Redistributions of source code must retain the above copyright
>>> > >notice, this list of conditions and the following disclaimer.
>>> > >
>>> > > 2. Redistributions in binary form must reproduce the above copyright
>>> > >notice, this list of conditions and the following disclaimer in
>>> the
>>> > >   documentation and/or other materials provided with the
>>> distribution.
>>> >
>>> > It needs noticing. That's why we put it into NOTICE ;)
>>> >
>>> > +1 from me.
>>> >
>>> >
>>> > Sorry but you're incorrect.  The copyright claim is already present by
>>> copying in their license file.
>>> >
>>> > BTW here's a legal ticket explain what should and should not go into a
>>> notice file
>>> >
>>> > https://issues.apache.org/jira/browse/LEGAL-262
>>> >
>>> > There's an explicit call out to MIT and BSD being excluded.
>>> >
>>> >
>>> >
>>> > LieGrue,
>>> > strub
>>> >
>>> >
>>> > > Am 14.03.2018 um 19:00 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
>>> > >
>>> > >
>>> > >
>>> > > Le 14 mars 2018 18:51, "John D. Ament"  a
>>> écrit :
>>> > > ASF policy is that NOTICE files are present when the consumed
>>> product includes a NOTICE file.  In BSD-3-Clause products, the copyright
>>> statement (including download link) is in the license file.  So its enough
>>> to list it there.
>>> > >
>>> > > My vote: -1 due to incorrect NOTICE file.
>>> > >
>>> > > It is not incorrect since the license is particular it must be in
>>> notice to be able to put all parts together on user side. If you dont you
>>> let users do again this job which is insanely bad.
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Mar 14, 2018 at 1:46 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>> > >
>>> > >
>>> > > Le 14 mars 2018 18:30, "John D. Ament"  a
>>> écrit :
>>> > > Why does the NOTICE file in the resulting JAR (for the ASM shaded
>>> dependency) include
>>> > >
>>> > > This product includes software developed at
>>> > > OW2 Consortium (http://asm.ow2.org/)
>>> > >
>>> > > There is no notice file associated with ASM 6.1, so we should not
>>> need to declare any notice.
>>> > >
>>> > > Well it is not an asf licensed software nor an asf project so it is
>>> no bad IMHO to list it here. Also their website look a bit outdated so I
>>> was not sure it was that ok to completely drop it.
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Mar 14, 2018 at 12:54 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>> > > yep, as written ;)
>>> > >
>>> > >
>>> > > Romain Manni-Bucau
>>> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> > >
>>> > > 2018-03-14 17:51 GMT+01:00 Jean-Louis MONTEIRO :
>>> > > Romain,
>>> > >
>>> > > as far as I have seen, there is only the ASM upgrade, right?
>>> > >
>>> > > Le mer. 14 mars 2018 à 17:49, Romain Manni-Bucau <
>>> rmannibu...@gmail.com> a écrit :
>>> > > Hi!
>>> > >
>>> > > Please VOTE for the release of Apache XBean-4.7.
>>> > >
>>> > > Here is the staging repo:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1049
>>> > > The source distribution can be found 

Re: MP-JWT progress

[John D. Ament]

On Sun, Mar 18, 2018 at 5:38 PM Romain Manni-Bucau 
wrote:

>
>
> Le 18 mars 2018 21:29, "David Blevins"  a écrit :
>
>
> > On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau 
> wrote:
> >
> > 1. code will be at geronimo - whatever happens at tomee
>
> As far as I understand the topic is still open and no git repos have been
> created anywhere yet, is that right?
>
>
> Yes
>
>
> Is there anyone on the Geronimo side who would be open to collaborating on
> a reusable JWT library under the TomEE project for a change?  Something not
> branded tomee or geronimo.
>
>
> This is what was proposed to be created @g which is just an umbrella, no
> more a project delivery by itself.
>
> Are you against/-1ing g-jwt-auth?
>

As mentioned elsewhere in the thread, I am against bringing something in
geronimo that is TomEE specific.  I haven't looked at the code (as far as I
can tell, nothing is linked in this thread so I have no idea if code even
exists) but based on what I've seen with implementing JWT it's closely tied
to your container.  So I don't believe its a good fit.

Why is your preference to bring this into geronimo?


>
>
>
> -David
>
>
>

Re: MP-JWT progress

[Romain Manni-Bucau]

Le 18 mars 2018 21:29, "David Blevins"  a écrit :


> On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau 
wrote:
>
> 1. code will be at geronimo - whatever happens at tomee

As far as I understand the topic is still open and no git repos have been
created anywhere yet, is that right?


Yes


Is there anyone on the Geronimo side who would be open to collaborating on
a reusable JWT library under the TomEE project for a change?  Something not
branded tomee or geronimo.


This is what was proposed to be created @g which is just an umbrella, no
more a project delivery by itself.

Are you against/-1ing g-jwt-auth?



-David

Re: [VOTE] XBean 4.7 release

[Romain Manni-Bucau]

Up John? Are you ok to change your vote to a -0 and not veto the release
since we are good legally but just didnt respect a good practise?

If not I can rerun the release tomorrow and add another not standard file
to replace our notice mention but i dont see any reason to require another
vote for that for now.


Le 15 mars 2018 07:11, "Romain Manni-Bucau"  a
écrit :

> @John: is it ok to keep it for this release and have another discuss
> thread about it for you - legally we are ok anyway?
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
> 2018-03-15 1:17 GMT+01:00 Mark Struberg :
>
>> I see. Note that the updated guideline does say 'need not' and not 'MUST
>> NOT'.
>> Yes we should probably remove it. But no, it's not a show stopper imo.
>>
>> LieGrue,
>> strub
>>
>> > Am 15.03.2018 um 01:01 schrieb John D. Ament :
>> >
>> >
>> >
>> > On Wed, Mar 14, 2018 at 7:54 PM John D. Ament 
>> wrote:
>> > On Wed, Mar 14, 2018 at 7:43 PM Mark Struberg 
>> wrote:
>> > +1 it's not incorrect. Please read the BSD3c license
>> >
>> > > 1. Redistributions of source code must retain the above copyright
>> > >notice, this list of conditions and the following disclaimer.
>> > >
>> > > 2. Redistributions in binary form must reproduce the above copyright
>> > >notice, this list of conditions and the following disclaimer in the
>> > >   documentation and/or other materials provided with the distribution.
>> >
>> > It needs noticing. That's why we put it into NOTICE ;)
>> >
>> > +1 from me.
>> >
>> >
>> > Sorry but you're incorrect.  The copyright claim is already present by
>> copying in their license file.
>> >
>> > BTW here's a legal ticket explain what should and should not go into a
>> notice file
>> >
>> > https://issues.apache.org/jira/browse/LEGAL-262
>> >
>> > There's an explicit call out to MIT and BSD being excluded.
>> >
>> >
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> > > Am 14.03.2018 um 19:00 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> > >
>> > >
>> > >
>> > > Le 14 mars 2018 18:51, "John D. Ament"  a
>> écrit :
>> > > ASF policy is that NOTICE files are present when the consumed product
>> includes a NOTICE file.  In BSD-3-Clause products, the copyright statement
>> (including download link) is in the license file.  So its enough to list it
>> there.
>> > >
>> > > My vote: -1 due to incorrect NOTICE file.
>> > >
>> > > It is not incorrect since the license is particular it must be in
>> notice to be able to put all parts together on user side. If you dont you
>> let users do again this job which is insanely bad.
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Mar 14, 2018 at 1:46 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>> > >
>> > >
>> > > Le 14 mars 2018 18:30, "John D. Ament"  a
>> écrit :
>> > > Why does the NOTICE file in the resulting JAR (for the ASM shaded
>> dependency) include
>> > >
>> > > This product includes software developed at
>> > > OW2 Consortium (http://asm.ow2.org/)
>> > >
>> > > There is no notice file associated with ASM 6.1, so we should not
>> need to declare any notice.
>> > >
>> > > Well it is not an asf licensed software nor an asf project so it is
>> no bad IMHO to list it here. Also their website look a bit outdated so I
>> was not sure it was that ok to completely drop it.
>> > >
>> > >
>> > >
>> > > On Wed, Mar 14, 2018 at 12:54 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>> > > yep, as written ;)
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> > >
>> > > 2018-03-14 17:51 GMT+01:00 Jean-Louis MONTEIRO :
>> > > Romain,
>> > >
>> > > as far as I have seen, there is only the ASM upgrade, right?
>> > >
>> > > Le mer. 14 mars 2018 à 17:49, Romain Manni-Bucau <
>> rmannibu...@gmail.com> a écrit :
>> > > Hi!
>> > >
>> > > Please VOTE for the release of Apache XBean-4.7.
>> > >
>> > > Here is the staging repo: https://repository.apache.org/
>> content/repositories/orgapachegeronimo-1049
>> > > The source distribution can be found here:
>> https://repository.apache.org/content/repositories/orgapache
>> geronimo-1049/org/apache/xbean/xbean/4.7/xbean-4.7-source-release.zip
>> > > sha1 is ea25f3fda5d9abea891a62abf738d1024f289dd5
>> > >
>> > > Change is only about upgrade asm to 6.1 (java 10).
>> > >
>> > > [+1] ship it
>> > > [+0] meh, don’t care
>> > > [-1] nope, stop because ${reason}
>> > >
>> > > The VOTE is open for 72h.
>> > >
>> > > Here is my +1.
>> > >
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau |  

Re: MP-JWT progress

[David Blevins]

> On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau  
> wrote:
> 
> 1. code will be at geronimo - whatever happens at tomee

As far as I understand the topic is still open and no git repos have been 
created anywhere yet, is that right?

Is there anyone on the Geronimo side who would be open to collaborating on a 
reusable JWT library under the TomEE project for a change?  Something not 
branded tomee or geronimo.


-David

Re: MP-JWT progress

[Romain Manni-Bucau]

2018-03-18 20:38 GMT+01:00 David Blevins :

> In case that wasn't clear, gentle objection to moving this now.
>
> If we can get this merged and at least a snapshot out, that'd be preferred.
>

I'm not following the rational here. Let me try to summarize another time
for you to ensure we speak of the same thing:

1. code will be at geronimo - whatever happens at tomee
2. code we worked on with JL has no tomee dependency (see 4 to be complete
here)
3. as the MP-Config work Roberto did, we'll need a TCK module (next to the
Roberto's one) for jwt-auth spec + a modification of the MP distro
4. TomEE had some propagation bug we need to fix - MP or not since it
happens with a plain servlet

So the JWT-Auth PR for TomEE can be:

A. this one which means TomEE will have an implementation of JWT-Auth and
Geronimo another one
B. the JWT-Auth code moves to Geronimo and TomEE merges from this PR 3 and 4

Just to restate it since it seems we restart from a blank page ;): I'm -1
on A to avoid to split our effort and noise as ASF and +1 for B.


>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> On Mar 18, 2018, at 12:26 PM, David Blevins 
> wrote:
>
> I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge
> this at least?
>
>
> -David
>
> On Mar 9, 2018, at 3:20 AM, John D. Ament  wrote:
>
> I don't think its a good idea to move TomEE code into Geronimo.
>
> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau 
> wrote:
>
> If there is no other comment, any objection to move it to
> geronimo-jwt-auth? (let say if not we do it on monday european time)
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
>  ee-8-high-performance>
>
> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
>
>
> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro 
> :
>
> Hi community,
>
>
> So we now have something close in terms of MP-JWT implementation.
>
> With the playground branch I've been working on (Thanks Romain for the
> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> TCK
> I have eagerly added - see ticket on MP-JWT).
>
> Now the question is how do we proceed?
> Knowing that most of the code is not TomEE specific.
>
>
> I'd move it to G to a new git repo keeping only the tck exec - a bit like
> Roberto started with config. I'll be happy to help fixing the small
> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
>
>
>
> Only few things are in the TomcatSecurityService but that can remain in
> TomEE because it's not really MP-JWT specific either.
>
>
> +1, was overdue anyway for our servlet-ejb integration
>
>
>
> Here is the PR for discussion
> https://github.com/apache/tomee/pull/123
>
> Cheers
> Jean-Louis
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
>
>
>
>
>

Re: MP-JWT progress

[David Blevins]

In case that wasn't clear, gentle objection to moving this now.

If we can get this merged and at least a snapshot out, that'd be preferred.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Mar 18, 2018, at 12:26 PM, David Blevins  wrote:
> 
> I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge this 
> at least?
> 
> 
> -David
> 
>> On Mar 9, 2018, at 3:20 AM, John D. Ament  wrote:
>> 
>> I don't think its a good idea to move TomEE code into Geronimo.
>> 
>> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau 
>> wrote:
>> 
>>> If there is no other comment, any objection to move it to
>>> geronimo-jwt-auth? (let say if not we do it on monday european time)
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>> 
>>> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
>>> 
 
 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro 
 :
 
> Hi community,
> 
> 
> So we now have something close in terms of MP-JWT implementation.
> 
> With the playground branch I've been working on (Thanks Romain for the
> help), we now pass 100% of the TCK (including a missing part in MP-JWT
> TCK
> I have eagerly added - see ticket on MP-JWT).
> 
> Now the question is how do we proceed?
> Knowing that most of the code is not TomEE specific.
> 
 
 I'd move it to G to a new git repo keeping only the tck exec - a bit like
 Roberto started with config. I'll be happy to help fixing the small
 remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
 
 
> 
> Only few things are in the TomcatSecurityService but that can remain in
> TomEE because it's not really MP-JWT specific either.
> 
 
 +1, was overdue anyway for our servlet-ejb integration
 
 
> 
> Here is the PR for discussion
> https://github.com/apache/tomee/pull/123
> 
> Cheers
> Jean-Louis
> 
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
 
 
>>> 
> 

Re: MP-JWT progress

[David Blevins]

I'd lean towards the side of John Ament and Jon Gallimore.  Can we merge this 
at least?


-David

> On Mar 9, 2018, at 3:20 AM, John D. Ament  wrote:
> 
> I don't think its a good idea to move TomEE code into Geronimo.
> 
> On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau 
> wrote:
> 
>> If there is no other comment, any objection to move it to
>> geronimo-jwt-auth? (let say if not we do it on monday european time)
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>> 
>> 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau :
>> 
>>> 
>>> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro 
>>> :
>>> 
 Hi community,
 
 
 So we now have something close in terms of MP-JWT implementation.
 
 With the playground branch I've been working on (Thanks Romain for the
 help), we now pass 100% of the TCK (including a missing part in MP-JWT
 TCK
 I have eagerly added - see ticket on MP-JWT).
 
 Now the question is how do we proceed?
 Knowing that most of the code is not TomEE specific.
 
>>> 
>>> I'd move it to G to a new git repo keeping only the tck exec - a bit like
>>> Roberto started with config. I'll be happy to help fixing the small
>>> remaining enhancements to do (jwt parsing based on jsonb/p, config etc).
>>> 
>>> 
 
 Only few things are in the TomcatSecurityService but that can remain in
 TomEE because it's not really MP-JWT specific either.
 
>>> 
>>> +1, was overdue anyway for our servlet-ejb integration
>>> 
>>> 
 
 Here is the PR for discussion
 https://github.com/apache/tomee/pull/123
 
 Cheers
 Jean-Louis
 
 
 --
 Jean-Louis Monteiro
 http://twitter.com/jlouismonteiro
 http://www.tomitribe.com
 
>>> 
>>> 
>> 

Re: MP-JWT progress

[Jean-Louis Monteiro]

I can do it tomorrow morning romain

Le 18 mars 2018 18:31, "Romain Manni-Bucau"  a
écrit :

> quick heads up: if no objection in between I plan to start creating the
> project tomorrow to let JL importing the code he did.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  rmannibucau> |
> LinkedIn  | Book
>  ee-8-high-performance>
>
> 2018-03-12 16:33 GMT+01:00 Rudy De Busscher :
>
> > OK (non-binding of course :) for generic classes at Geronimo.
> >
> > On 12 March 2018 at 16:01, Jean-Louis Monteiro  >
> > wrote:
> >
> > > So what's the conclusion here?
> > >
> > > Should I request a git repo on geronimo and extract all generic classes
> > > there along side with other implementations?
> > > Or do you guys prefer another tomee repo with the MP-JWT impl?
> > >
> > > I don't mind if they go here and there, just need to know so I can move
> > on
> > > with the contribution.
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > > On Fri, Mar 9, 2018 at 2:15 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > 2018-03-09 12:37 GMT+01:00 Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com>
> > > > :
> > > >
> > > > > Currently this in a PR, so it hasn't actually been merged anywhere.
> > > > There's
> > > > > some at least some TomEE specific code, so some modules need
> defining
> > > > > before it can be "moved" in my view.
> > > > >
> > > > > Rudy's point is good one - no doubt a generic, reusable module may
> > well
> > > > be
> > > > > what we end up with. Wherever that lives when it has clearly been
> > > > defined,
> > > > > it needs documenting and showing how to use it.
> > > > >
> > > > > We talked previously about being able to have modules in separate
> > repos
> > > > > under TomEE. Is there some issue with doing that? What's the rush
> to
> > > > shift
> > > > > this off to Geronimo?
> > > > >
> > > >
> > > > No rush, geronimo will have a jwt-auth impl and I was waiting JL push
> > > what
> > > > he did before speaking of creating a project @G. I would like to
> share
> > > the
> > > > same impl with tomee to avoid to x2 the effort. however if not
> desired
> > it
> > > > is fine as well.
> > > >
> > > > It is also important to keep in mind that on tomee side there is *no*
> > > > specific code, only fixes in the propagation which also impact
> > > webprofile,
> > > > nothing linked to MP or this particular spec.
> > > >
> > > >
> > > >
> > > > >
> > > > > Jon
> > > > >
> > > > > On Fri, Mar 9, 2018 at 11:27 AM, Rudy De Busscher <
> > > rdebussc...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I'm not saying we should move TomEE code into Geronimo.
> > > > > >
> > > > > > If we move the generic stuff for JWT Auth to Geronimo, it will
> not
> > be
> > > > > > enough to have it completely functional. And that should be made
> > > clear
> > > > > from
> > > > > > the beginning for all potential usages.
> > > > > >
> > > > > > On 9 March 2018 at 12:20, John D. Ament 
> > > wrote:
> > > > > >
> > > > > > > I don't think its a good idea to move TomEE code into Geronimo.
> > > > > > >
> > > > > > > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > If there is no other comment, any objection to move it to
> > > > > > > > geronimo-jwt-auth? (let say if not we do it on monday
> european
> > > > time)
> > > > > > > >
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau  |  Blog
> > > > > > > >  | Old Blog
> > > > > > > >  | Github
> > > > > > > >  | LinkedIn
> > > > > > > >  | Book
> > > > > > > >  > > > > > > ee-8-high-performance>
> > > > > > > >
> > > > > > > > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > >>
> > > > > > > >> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> > > > > > > jlmonte...@tomitribe.com>
> > > > > > > >> :
> > > > > > > >>
> > > > > > > >>> Hi community,
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> So we now have something close in terms of MP-JWT
> > > implementation.
> > > > > > > >>>
> > > > > > > >>> With the playground branch I've been working on (Thanks
> > Romain
> > > > for
> > > > > > the
> > > > > > > >>> help), we now pass 100% of the TCK (including a missing
> part
> > in
> > > > > > 

[jira] [Commented] (GERONIMO-6601) geronimo spec jar files produce Invalid module name in JPMS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404071#comment-16404071
 ] 

ASF GitHub Bot commented on GERONIMO-6601:
--

GitHub user christopher-johnson opened a pull request:

https://github.com/apache/geronimo-specs/pull/8

[GERONIMO-6601] adds Automatic-Module-Name

the duplication of the maven-jar-plugin configuration in every module 
pom.xml seems required with the current project hierarchy.  

The value of  
```xml

``` 
is set in a property `` in the event that this 
should change.

The property values are consistent with the top-level exported package name 
with a few exceptions.  Several specs export more than one primary package, for 
example, `geronimo-jcdi_1.0_spec`, that exports
`javax.decorator` and  `javax.enterprise`.  In that case, I arbitrarily 
chose `javax.decorator`. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/christopher-johnson/geronimo-specs 
automatic-modules

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geronimo-specs/pull/8.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #8


commit 9258a9fb73ffce045ee104523d58c4ddf7b83599
Author: Christopher Hanna Johnson 
Date:   2018-03-18T16:44:05Z

[GERONIMO-6601] adds Automatic-Module-Name




> geronimo spec jar files produce Invalid module name in JPMS 
> 
>
> Key: GERONIMO-6601
> URL: https://issues.apache.org/jira/browse/GERONIMO-6601
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Christopher Johnson
>Priority: Major
>
> libraries that depend on geronimo specs cannot be compiled as JPMS modules 
> because of the naming convention used for the jars and the absence of an 
> {{Automatic-Module-Name}} directive in MANIFEST.MF. 
> Reference: 
> [https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-]
>  for how JPMS determines module names.
> For example, geronimo-annotation_1.2_spec-1.0-alpha-1.jar causes this 
> exception:
>  
> {code:java}
> Error occurred during initialization of boot layer 
> java.lang.module.FindException: Unable to derive module descriptor for 
> /home/christopher/.gradle/caches/modules-2/files-2.1/org.apache.geronimo.specs/geronimo-annotation_1.2_spec/1.0-alpha-1/804747c40f1145ae9cc13cb9e927fca82e6e3c1b/geronimo-annotation_1.2_spec-1.0-alpha-1.jar
>  Caused by: java.lang.IllegalArgumentException: geronimo.annotation.1.2.spec: 
> Invalid module name: '1' is not a Java identifier
> {code}
> This problem occurs with all geronimo specs that include a version in the 
> artifact ID.  For example, activemq-client depends on 
> geronimo-j2ee-management_1.1_spec-1.0.1.jar so it cannot be compiled as a 
> JPMS module.
>  
> Solution could be to add 
> {code:java}
> Automatic-Module-Name
> {code}
> to the pom.xml:
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] geronimo-specs pull request #8: [GERONIMO-6601] adds Automatic-Module-Name

[christopher-johnson]

GitHub user christopher-johnson opened a pull request:

https://github.com/apache/geronimo-specs/pull/8

[GERONIMO-6601] adds Automatic-Module-Name

the duplication of the maven-jar-plugin configuration in every module 
pom.xml seems required with the current project hierarchy.  

The value of  
```xml

``` 
is set in a property `` in the event that this 
should change.

The property values are consistent with the top-level exported package name 
with a few exceptions.  Several specs export more than one primary package, for 
example, `geronimo-jcdi_1.0_spec`, that exports
`javax.decorator` and  `javax.enterprise`.  In that case, I arbitrarily 
chose `javax.decorator`. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/christopher-johnson/geronimo-specs 
automatic-modules

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geronimo-specs/pull/8.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #8


commit 9258a9fb73ffce045ee104523d58c4ddf7b83599
Author: Christopher Hanna Johnson 
Date:   2018-03-18T16:44:05Z

[GERONIMO-6601] adds Automatic-Module-Name




---

Re: MP-JWT progress

[Romain Manni-Bucau]

quick heads up: if no objection in between I plan to start creating the
project tomorrow to let JL importing the code he did.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book


2018-03-12 16:33 GMT+01:00 Rudy De Busscher :

> OK (non-binding of course :) for generic classes at Geronimo.
>
> On 12 March 2018 at 16:01, Jean-Louis Monteiro 
> wrote:
>
> > So what's the conclusion here?
> >
> > Should I request a git repo on geronimo and extract all generic classes
> > there along side with other implementations?
> > Or do you guys prefer another tomee repo with the MP-JWT impl?
> >
> > I don't mind if they go here and there, just need to know so I can move
> on
> > with the contribution.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Fri, Mar 9, 2018 at 2:15 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > 2018-03-09 12:37 GMT+01:00 Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com>
> > > :
> > >
> > > > Currently this in a PR, so it hasn't actually been merged anywhere.
> > > There's
> > > > some at least some TomEE specific code, so some modules need defining
> > > > before it can be "moved" in my view.
> > > >
> > > > Rudy's point is good one - no doubt a generic, reusable module may
> well
> > > be
> > > > what we end up with. Wherever that lives when it has clearly been
> > > defined,
> > > > it needs documenting and showing how to use it.
> > > >
> > > > We talked previously about being able to have modules in separate
> repos
> > > > under TomEE. Is there some issue with doing that? What's the rush to
> > > shift
> > > > this off to Geronimo?
> > > >
> > >
> > > No rush, geronimo will have a jwt-auth impl and I was waiting JL push
> > what
> > > he did before speaking of creating a project @G. I would like to share
> > the
> > > same impl with tomee to avoid to x2 the effort. however if not desired
> it
> > > is fine as well.
> > >
> > > It is also important to keep in mind that on tomee side there is *no*
> > > specific code, only fixes in the propagation which also impact
> > webprofile,
> > > nothing linked to MP or this particular spec.
> > >
> > >
> > >
> > > >
> > > > Jon
> > > >
> > > > On Fri, Mar 9, 2018 at 11:27 AM, Rudy De Busscher <
> > rdebussc...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I'm not saying we should move TomEE code into Geronimo.
> > > > >
> > > > > If we move the generic stuff for JWT Auth to Geronimo, it will not
> be
> > > > > enough to have it completely functional. And that should be made
> > clear
> > > > from
> > > > > the beginning for all potential usages.
> > > > >
> > > > > On 9 March 2018 at 12:20, John D. Ament 
> > wrote:
> > > > >
> > > > > > I don't think its a good idea to move TomEE code into Geronimo.
> > > > > >
> > > > > > On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > If there is no other comment, any objection to move it to
> > > > > > > geronimo-jwt-auth? (let say if not we do it on monday european
> > > time)
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau  |  Blog
> > > > > > >  | Old Blog
> > > > > > >  | Github
> > > > > > >  | LinkedIn
> > > > > > >  | Book
> > > > > > >  > > > > > ee-8-high-performance>
> > > > > > >
> > > > > > > 2018-03-06 11:11 GMT+01:00 Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >:
> > > > > > >
> > > > > > >>
> > > > > > >> 2018-03-06 10:24 GMT+01:00 Jean-Louis Monteiro <
> > > > > > jlmonte...@tomitribe.com>
> > > > > > >> :
> > > > > > >>
> > > > > > >>> Hi community,
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> So we now have something close in terms of MP-JWT
> > implementation.
> > > > > > >>>
> > > > > > >>> With the playground branch I've been working on (Thanks
> Romain
> > > for
> > > > > the
> > > > > > >>> help), we now pass 100% of the TCK (including a missing part
> in
> > > > > MP-JWT
> > > > > > >>> TCK
> > > > > > >>> I have eagerly added - see ticket on MP-JWT).
> > > > > > >>>
> > > > > > >>> Now the question is how do we proceed?
> > > > > > >>> Knowing that most of the code is not TomEE specific.
> > > > > > >>>
> > > > > > >>
> > > > > > >> I'd move it to G to a new git repo keeping only the tck exec
> - a
> > > bit
> > > > > > like
> > > > > > >> Roberto started with config.