Re: "Umbrella" discussion

[Romain Manni-Bucau]

Le 12 avr. 2018 23:24, "gilbertoca"  a écrit :

Guys, just a user here.

>From my experience, no one knows the Geronimo project[1] (for me it appears
a retired/dead one).
Everyone I talk with thinks everything is in TomEE (I thought like this
before).
Now, after read about the project in the mail-list (several discussion by
the way) I understand why the Geronimo project still exists. But it doesn't
change the general understanding, TomEE is the official Java EE
implementation on Apache Fundation.
I think the Geronimo site should be deactivated and the TomEE site, even
though is not official umbrella, should be changed to incorporate all
projects/sub-projects - like the spring portal[2]. It would show that the
Geronimo sub-projects are stronger and are empowering the TomEE engine.


If you do you kill subproject as not ee ones (we tried). We need to work on
the new geronimo identity but importing it in tomee is a known end for me.
Tomee users will not notice any diff (tomee is less than 5% of the apache
projects it uses and way less than geronimo code it includes).

I understand your point of view but this is also what killed geronimo as a
server.

Hope we can avoid to do it again ;)


Regards,

Gilberto

[1] http://geronimo.apache.org/
[2] https://spring.io/projects


agumbrecht wrote
> I agree with Roberto, that we can create a distinct area under the TomEE
> PMC. Now we have a firm name 'Jakarta EE', I think we should grab that
> by the horns in some way and run with it!
>
> I feel that 'anything' EE should not land in 'commons', but should be
> actively promoted as an EE component or library, even jakarta-[lib].
>
> As I mentioned in the TomEE MP thread already - We should act quickly.
> Yes, that may mean we cause ripples or waves in an unforeseen way, but
> we also need to keep the 'Apache' noise loud. Especially because Eclipse
> is on the leader board here. Anyway, nothing we do is cast in concrete.
>
> "We gave each other a lot of free space, which is why we stayed
> motivated to keep adding code there instead of keeping it in our
> projects" - It 'used' to be this way in TomEE, and it was fun. Between
> releases, what goes on in the repo is a playground - Kids should have
> fun in the playground until the bell rings.
>
> In fact, I'm feeling like getting in the playground again with MP and I
> think I will just get on with it, get some thick skin, and have fun. I
> will of course try and get more fun kids in the playground too, and if
> that gets me detention so be it :-P.
>
> Andy.
>
> On 27/02/18 15:33, Roberto Cortez wrote:
>>
>> Hi,
>> I'll +1 on:
>> 5.) Move the usable components to a disctinct area under the TomEE PMC,
>> but with a separate brand name. It should _not_ be TomEE components, but
>> something catchy
>>
>> Cheers,RobertoOn Sunday, February 25, 2018, 11:50:43 PM GMT, David
>> Blevins 

> david.blevins@

>  wrote:
>>
>>   Huge email, so if I don't respond to a point you were particularly
>> interested in, do let me know.  Adding some thoughts.
>>
>>> Again my argument:
>>>
>>>
>>> *) There should be a go-to place for such reusable enterprise parts at
>>> Apache. Like javamail, the tx-mgr, the specs, config, xbean, etc.
>>>
>>> *) We should keep the o.a.geronimo.specs groupId (would be tons of work
>>> for downstream projects to change it) and we cannot have multiple PMCs
>>> using this groupId and package name.
>>>
>>> *) Those reusable parts should have an own marketing name. We could
>>> reuse XBean or find a better one.
>>> Why? Geronimo is associated with a big and dead EE server, TomEE is
>>> associated with an alive EE server. Better, but not much.
>>> It should be clear that those reusable components are actually
>>> independent of each of the 3 projects.
>>>
>>> *) The reusablel parts each also have a separate livecycle.
>>>
>>> *) If we really shutdown Geronimo then all the active components should
>>> be moved to another project, the rest goes to the attic.
>>>
>>> *) I totally don't care which PMC does the organisatorial thing as long
>>> as it is active. That would be a plus for the TomEE PMC as it is
>>> reasonably more active. We did not even get enough +1 for the last votes
>>> over here. That's not making me happy.
>> I agree with the community perspective that having us all split into a
>> couple weak PMCs is not ideal.  I think we'd be stronger together.
>>
>> More reusable components released separately is a good way to keep build
>> times down.  There's a cost to that, so pragmatism is definitely
>> required.
>>
>> Some things are a couple lines of code.  Some things are a library in a
>> git repo.  Some things are their own repo, but not big enough for a PMC.
>> Some things need to be their own standalone project.
>>
>> The above said, they are all very subjective so what's really important
>> to me is that freedom still exist.
>>
>>   - I'm not a fan of seeing "you can't do x because y project owns it"
>>
>>   - I'm not a fan of 

Re: "Umbrella" discussion

[gilbertoca]

Guys, just a user here.

>From my experience, no one knows the Geronimo project[1] (for me it appears
a retired/dead one).
Everyone I talk with thinks everything is in TomEE (I thought like this
before). 
Now, after read about the project in the mail-list (several discussion by
the way) I understand why the Geronimo project still exists. But it doesn't
change the general understanding, TomEE is the official Java EE
implementation on Apache Fundation.
I think the Geronimo site should be deactivated and the TomEE site, even
though is not official umbrella, should be changed to incorporate all
projects/sub-projects - like the spring portal[2]. It would show that the
Geronimo sub-projects are stronger and are empowering the TomEE engine.

Regards,

Gilberto

[1] http://geronimo.apache.org/
[2] https://spring.io/projects


agumbrecht wrote
> I agree with Roberto, that we can create a distinct area under the TomEE 
> PMC. Now we have a firm name 'Jakarta EE', I think we should grab that 
> by the horns in some way and run with it!
> 
> I feel that 'anything' EE should not land in 'commons', but should be 
> actively promoted as an EE component or library, even jakarta-[lib].
> 
> As I mentioned in the TomEE MP thread already - We should act quickly. 
> Yes, that may mean we cause ripples or waves in an unforeseen way, but 
> we also need to keep the 'Apache' noise loud. Especially because Eclipse 
> is on the leader board here. Anyway, nothing we do is cast in concrete.
> 
> "We gave each other a lot of free space, which is why we stayed 
> motivated to keep adding code there instead of keeping it in our 
> projects" - It 'used' to be this way in TomEE, and it was fun. Between 
> releases, what goes on in the repo is a playground - Kids should have 
> fun in the playground until the bell rings.
> 
> In fact, I'm feeling like getting in the playground again with MP and I 
> think I will just get on with it, get some thick skin, and have fun. I 
> will of course try and get more fun kids in the playground too, and if 
> that gets me detention so be it :-P.
> 
> Andy.
> 
> On 27/02/18 15:33, Roberto Cortez wrote:
>>   
>> Hi,
>> I'll +1 on:
>> 5.) Move the usable components to a disctinct area under the TomEE PMC,
>> but with a separate brand name. It should _not_ be TomEE components, but
>> something catchy
>>
>> Cheers,RobertoOn Sunday, February 25, 2018, 11:50:43 PM GMT, David
>> Blevins 

> david.blevins@

>  wrote:
>>   
>>   Huge email, so if I don't respond to a point you were particularly
>> interested in, do let me know.  Adding some thoughts.
>>
>>> Again my argument:
>>>
>>>
>>> *) There should be a go-to place for such reusable enterprise parts at
>>> Apache. Like javamail, the tx-mgr, the specs, config, xbean, etc.
>>>
>>> *) We should keep the o.a.geronimo.specs groupId (would be tons of work
>>> for downstream projects to change it) and we cannot have multiple PMCs
>>> using this groupId and package name.
>>>
>>> *) Those reusable parts should have an own marketing name. We could
>>> reuse XBean or find a better one.
>>> Why? Geronimo is associated with a big and dead EE server, TomEE is
>>> associated with an alive EE server. Better, but not much.
>>> It should be clear that those reusable components are actually
>>> independent of each of the 3 projects.
>>>
>>> *) The reusablel parts each also have a separate livecycle.
>>>
>>> *) If we really shutdown Geronimo then all the active components should
>>> be moved to another project, the rest goes to the attic.
>>>
>>> *) I totally don't care which PMC does the organisatorial thing as long
>>> as it is active. That would be a plus for the TomEE PMC as it is
>>> reasonably more active. We did not even get enough +1 for the last votes
>>> over here. That's not making me happy.
>> I agree with the community perspective that having us all split into a
>> couple weak PMCs is not ideal.  I think we'd be stronger together.
>>
>> More reusable components released separately is a good way to keep build
>> times down.  There's a cost to that, so pragmatism is definitely
>> required.
>>
>> Some things are a couple lines of code.  Some things are a library in a
>> git repo.  Some things are their own repo, but not big enough for a PMC. 
>> Some things need to be their own standalone project.
>>
>> The above said, they are all very subjective so what's really important
>> to me is that freedom still exist.
>>
>>   - I'm not a fan of seeing "you can't do x because y project owns it"
>>
>>   - I'm not a fan of abstracting code before I've written it as flat as
>> possible first
>>
>>   - We would need an exceptionally positive environment that favors
>> creativity and tolerates bending the rules
>>
>> As an example of reuse, I wrote xbean-finder in OpenEJB first as a few
>> classes right in openejb-core module.  I was just trying to get my head
>> around annotation processing and all the new requirements for EJB 3.0. 
>> Once things were working and it was 

Re: [RESULT] Explore creating a reusable JWT Library

[Romain Manni-Bucau]

why -> for consistency accross our coupled communities
why does it matter if it is in G for T? -> it doesn't

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


2018-04-12 15:56 GMT+02:00 Matthew Broadhead :
> we already include libraries from geronimo, e.g. javamail, so why does it
> matter where the library resides as long as it can be included in the
> package
>
>
> On 11/04/2018 15:05, Romain Manni-Bucau wrote:
>>
>> Hi Matthew,
>>
>> No, technicall there are a lot of small things to do before it can be
>> "included" but the main blocker for me is that the exact same project
>> is created at geronimo (actually this code was designed to be owned by
>> geronimo and the artifact imported in tomee).
>> Since G will have it I would like to avoid to have to maintain 2
>> versions of the "same" code, it already proved being a failure promise
>> multiple times so it is more a management reason than a technical one
>> since the spec is pretty trivial.
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>
>>
>> 2018-04-11 14:54 GMT+02:00 Matthew Broadhead
>> :
>>>
>>> Hi David,
>>>
>>> Thanks for the invitation to vote.  I don't want to vote because I am not
>>> sure I have enough knowledge to be able to do so.
>>>
>>> My gut feeling would probably be to side with Mark and Romain as they
>>> have
>>> been very supportive with my queries about TomEE and they have shown
>>> deep
>>> technical knowledge about the inner workings.
>>>
>>> On the other hand I don't want to dismiss the excellent effort others are
>>> making on the JWT issue.  However as long as the code is reusable and
>>> finds
>>> a home it will not be wasted.
>>>
>>> I am still interested to know what Mark and Romain are looking for before
>>> they accept it into the project.  Does it need to have proven track
>>> record
>>> and reliability?  It is a security plugin after all...
>>>
>>> Matthew
>>>
>>>
>>> On 10/04/2018 05:23, David Blevins wrote:

 Officially closing the vote.  Thanks for the patience everyone.  As
 mentioned in the other vote, this one needed some good discussion and a
 bit
 of extra time.

 +1s
 Andy Gumbrecht
 David Blevins
 Ivan Junckes Filho
 Jean-Louis Monteiro
 Jonathan Gallimore
 Thiago Veronezi

 +0
 Rudy De Busscher

 -1s
 Mark Struberg
 Romain Manni-Bucau

 This was intended as a non-technical vote, so I've registered Mark's -1
 as
 he intended it.  Thanks, Mark, for the clarification.  Matthew, you
 didn't
 vote, your participation was quite high -- thank you!  You're more then
 welcome to vote, sir :)

 This was a consensus vote to see if there was will keep working on the
 JWT
 code here and see if it could be made reusable.  We didn't really need
 this
 vote to accomplish anything other than to see where people's heads are
 at
 and make sure we're communicating with each other clearly.

 It does seem over all that the desire is to take a couple more steps.
 This vote did not address where the code should live in its final state.
 We
 don't really know how reusable anything will be.

 I'd probably expect us to take a few more steps, see how things look and
 come back to the "where" topic.


 -David


> On Mar 18, 2018, at 5:02 PM, David Blevins 
> wrote:
>
> The vote for merging PR 123 does not address community will on what to
> do
> with the code beyond merging it.  One can realistically vote +1 to
> merge the
> code, but then desire to see the code cleaned up and moved elsewhere.
> One
> can realistically desire seeing an attempt to clean up the code to find
> what
> is reusable and may wish to withhold a final decision until we see how
> fruitful such a module would be.
>
> Out of respect for people who may not know exactly how they feel (TomEE
> or Geronimo), this is a vote for the latter.
>
> Vote: Should we attempt to extract code from the JWT PR to see what is
> reusable and how successful such a jar would be?
>
> +1 Let's give it a shot here
> +-0
> -1 Let's do this elsewhere
>
> If the vote is +1 to attempt an extraction of reusable code here, final
> conclusion of if that extraction is worth it or where it should live is
> not
> being voted on.  People are welcome to decide differently based on the
> results of the exercise.
>
>
> -David
>
>

Re: [RESULT] Explore creating a reusable JWT Library

[Matthew Broadhead]

we already include libraries from geronimo, e.g. javamail, so why does 
it matter where the library resides as long as it can be included in the 
package


On 11/04/2018 15:05, Romain Manni-Bucau wrote:

Hi Matthew,

No, technicall there are a lot of small things to do before it can be
"included" but the main blocker for me is that the exact same project
is created at geronimo (actually this code was designed to be owned by
geronimo and the artifact imported in tomee).
Since G will have it I would like to avoid to have to maintain 2
versions of the "same" code, it already proved being a failure promise
multiple times so it is more a management reason than a technical one
since the spec is pretty trivial.

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


2018-04-11 14:54 GMT+02:00 Matthew Broadhead :

Hi David,

Thanks for the invitation to vote.  I don't want to vote because I am not
sure I have enough knowledge to be able to do so.

My gut feeling would probably be to side with Mark and Romain as they have
been very supportive with my queries about TomEE and they have shown  deep
technical knowledge about the inner workings.

On the other hand I don't want to dismiss the excellent effort others are
making on the JWT issue.  However as long as the code is reusable and finds
a home it will not be wasted.

I am still interested to know what Mark and Romain are looking for before
they accept it into the project.  Does it need to have proven track record
and reliability?  It is a security plugin after all...

Matthew


On 10/04/2018 05:23, David Blevins wrote:

Officially closing the vote.  Thanks for the patience everyone.  As
mentioned in the other vote, this one needed some good discussion and a bit
of extra time.

+1s
Andy Gumbrecht
David Blevins
Ivan Junckes Filho
Jean-Louis Monteiro
Jonathan Gallimore
Thiago Veronezi

+0
Rudy De Busscher

-1s
Mark Struberg
Romain Manni-Bucau

This was intended as a non-technical vote, so I've registered Mark's -1 as
he intended it.  Thanks, Mark, for the clarification.  Matthew, you didn't
vote, your participation was quite high -- thank you!  You're more then
welcome to vote, sir :)

This was a consensus vote to see if there was will keep working on the JWT
code here and see if it could be made reusable.  We didn't really need this
vote to accomplish anything other than to see where people's heads are at
and make sure we're communicating with each other clearly.

It does seem over all that the desire is to take a couple more steps.
This vote did not address where the code should live in its final state.  We
don't really know how reusable anything will be.

I'd probably expect us to take a few more steps, see how things look and
come back to the "where" topic.


-David



On Mar 18, 2018, at 5:02 PM, David Blevins 
wrote:

The vote for merging PR 123 does not address community will on what to do
with the code beyond merging it.  One can realistically vote +1 to merge the
code, but then desire to see the code cleaned up and moved elsewhere.  One
can realistically desire seeing an attempt to clean up the code to find what
is reusable and may wish to withhold a final decision until we see how
fruitful such a module would be.

Out of respect for people who may not know exactly how they feel (TomEE
or Geronimo), this is a vote for the latter.

Vote: Should we attempt to extract code from the JWT PR to see what is
reusable and how successful such a jar would be?

+1 Let's give it a shot here
+-0
-1 Let's do this elsewhere

If the vote is +1 to attempt an extraction of reusable code here, final
conclusion of if that extraction is worth it or where it should live is not
being voted on.  People are welcome to decide differently based on the
results of the exercise.


-David