[VOTE] Move ahead with creating a reusable JWT module

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Move ahead with creating a reusable JWT module

David Blevins-2
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

Reply | Threaded
Open this post in threaded view
|

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

John D. Ament


On Sun, Mar 18, 2018 at 8:05 PM David Blevins <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

David Blevins-2
In reply to this post by David Blevins-2
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

David Blevins-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>

Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
+1 to host jwt-auth @G whatever tomee does.


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

2018-03-19 4:09 GMT+01:00 David Blevins <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>


Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
Hi guys,

seems there is no -1 so any objection to create the repo next week?


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

2018-03-19 8:29 GMT+01:00 Romain Manni-Bucau <[hidden email]>:
+1 to host jwt-auth @G whatever tomee does.


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

2018-03-19 4:09 GMT+01:00 David Blevins <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>



Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau
Ok, let's do it then.


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

2018-03-23 21:22 GMT+01:00 Romain Manni-Bucau <[hidden email]>:
Hi guys,

seems there is no -1 so any objection to create the repo next week?


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

2018-03-19 8:29 GMT+01:00 Romain Manni-Bucau <[hidden email]>:
+1 to host jwt-auth @G whatever tomee does.


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

2018-03-19 4:09 GMT+01:00 David Blevins <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>




Reply | Threaded
Open this post in threaded view
|

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

Romain Manni-Bucau


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

2018-03-26 11:53 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
Ok, let's do it then.


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

2018-03-23 21:22 GMT+01:00 Romain Manni-Bucau <[hidden email]>:
Hi guys,

seems there is no -1 so any objection to create the repo next week?


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

2018-03-19 8:29 GMT+01:00 Romain Manni-Bucau <[hidden email]>:
+1 to host jwt-auth @G whatever tomee does.


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

2018-03-19 4:09 GMT+01:00 David Blevins <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >
>