from:"Andy"


+1 go for it!


On 19/03/18 13:19, Jonathan Gallimore wrote:

Hi

As discussed here:
http://tomee-openejb.979440.n4.nabble.com/MP-JWT-progress-tp4683480p4683612.html

I'd like migrate our old SVN sandbox to a git repository.

I've also had someone ping me (not on the mailing list) asking for the
OpenEJB Eclipse Plugin - I'd therefore like to bring it up to date and have
a Git repository for that too.

Does anyone object? If not, I'll create tomee-sandbox and
tomee-eclipse-plugin and migrate those over.

Thanks

Jon



--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: MP-JWT progress

I don't see TomEE as the center of the world, but somewhere where people
should be free to work without constantly being told it's not OK to do so.

On 19/03/18 10:45, Mark Struberg wrote:

@Anydy and @David
Let's face it TomEE is mostly an aggregator. A great one, I really love it -
but still.

For example: apart from verifying and excluding all the broken TCKs I had probably 30 committs for TomEE8 which are really due to upgrades for EE8. Most of them have been CDI-2.0 adoptions and adopting to Tomcat behaviour changes.

But apart from that Romain I had about 4000 commits in all the other projects,
all for TomEE8. And there are many more people and projects involved which just
get consumed by TomEE:
* Tomcat* OpenWebBeans* MyFaces
* Johnzon* OpenJPA* BVal* log4j* commons* BatchEE
* various geronimo libs like * xbean, * geronimo-jta, * geronimo-javamail, tons
of * geronimo-specs
Folks, you have to stop thinking as TomEE as being the center of the world. I
love TomEE and it's a great aggregator and a great community.
But building TomEE is literally just the tip of the iceberg. All the work on
the parts under the water - which is the vast majority - is done FOR TomEE but
*not* AT TomEE!So don't fight those communities but embrace them.

This is not a one way street.
We (TomEE) should be really much more active in pointing that out TomEE
contributors are perfectly welcome to tinker around in all the downstream
projects as well. And the other way around.
We need EACH OTHER! TomEE as kind of end-user projects which adds a huge
adoption factor. And of course the components underneath as a rock solid base.

LieGrue,strub

On Monday, 19 March 2018, 09:37:36 CET, Andy Gumbrecht
wrote:

I think that if anyone feels like contributing to TomEE then we should

allow and encourage that as soon as possible. The politics of where
things should 'eventually' reside is a huge distraction and just serves
to block any progress at the moment - The enthusiasm dies quickly after
a week of back and forth. The first choice for anything should be TomEE,
as that is the community we serve. The first response should be thank
you, and we should accept the help offered. Then those that want to
worry about extraction and reuse should feel free to go ahead and do
that if they feel strongly enough about it. It should not be the
priority for TomEE.

The goal should be to get TomEE on the MP board as soon as possible. If
that initially means TomEE 8, Java 8, and accepting a few PRs then we
should press ahead with that now. Anything that might need back-porting
can be addressed later.

Andy.

On 19/03/18 01:02, David Blevins wrote:

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

--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Ubique

Re: MP-JWT progress

I think that if anyone feels like contributing to TomEE then we should 
allow and encourage that as soon as possible. The politics of where 
things should 'eventually' reside is a huge distraction and just serves 
to block any progress at the moment - The enthusiasm dies quickly after 
a week of back and forth. The first choice for anything should be TomEE, 
as that is the community we serve. The first response should be thank 
you, and we should accept the help offered. Then those that want to 
worry about extraction and reuse should feel free to go ahead and do 
that if they feel strongly enough about it. It should not be the 
priority for TomEE.


The goal should be to get TomEE on the MP board as soon as possible. If 
that initially means TomEE 8, Java 8, and accepting a few PRs then we 
should press ahead with that now. Anything that might need back-porting 
can be addressed later.


Andy.


On 19/03/18 01:02, David Blevins wrote:

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




--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: [VOTE] Explore creating a reusable JWT Library


+1.

I'd like to see the code merged and evolve a little within the the TomEE 
context. It's relatively easy to discuss/extract reuse later, but I'd 
like to see TomEE move forward first.


The same goes for the config PR from Roberto.

Andy.


On 19/03/18 01:02, 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




--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: [VOTE] Merge Pull Request 123 - MicroProfile JWT support


+1 Andy.


On 19/03/18 01:02, David Blevins wrote:

Jean-Louis has put a PR up for discussion for JWT Support in TomEE.

  - https://github.com/apache/tomee/pull/123

There are 35 commits spanning 27 days of work.  It's been reviewed by Andy and 
Rudy.  One a committer and one a contributor, which is great for us.

There's an open question as to where the code should live in its final state: 
TomEE or Geronimo.  This conversation doesn't seem conclusive after 12 days.  
It's ok for us not to agree, but we should have more votes so there is a clear 
outcome and we are acting as a community to our best ability.

Vote: Merge Pull Request 123?

  +1  Yes, let's do it
  +-0 Abstain
  -1  No, don't put this code in TomEE


Out of respect for the conversation, this is not a vote of where the code will 
live in its final state.  This is just a decision to merge or not.  It would 
give the users something they can try, which can be updated by a future PR if 
the code does eventually move.


-David




--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: TomEE MicroProfile Dist with Config

2018-03-06 Thread Andy Gumbrecht


+1, nice work Roberto

Thank you very much for taking the time to work on this.

I'd like to see this work merged asap if the build is good, as it is 
really easy to continue to work on and improve on the code over time.


Andy.


On 05/03/18 13:40, Roberto Cortez wrote:

Hi all,
I've submitted a PR:https://github.com/apache/tomee/pull/122

With some initial work to build a MicroProfile dist of TomEE, starting with the 
MicroProfile Config.
Please let me know if this is alright. I plan to add some of the other 
implementations into it as well.
Thanks!
Cheers,Roberto


--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: [DISCUSS] switching TomEE8 to master

2018-03-02 Thread Andy Gumbrecht


+1


On 02/03/18 14:56, Mark Struberg wrote:

hi folks!

We discussed this quite some times and we got good feedback so far. So it's 
finally time to make this reality.

Over the weekend I'd like to switch TomEE to master and create a maintenance 
branch for Tomee7.

After that I'd love to roll a first TomEE8 version in say one month from now.

Any objection?


LieGrue,
strub




--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: "Umbrella" discussion

2018-02-28 Thread Andy Gumbrecht

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
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 clear I was on the right path, I cleaned it up and
split it out as a module in xbean. I wrote xbean-telnet like that as well as
xbean-classpath. James Strachan and Hiram Chirino wrote xbean-spring in
ActiveMQ first then moved it over.

Dain Sundstrom wrote xbean-reflect and xbean-naming there first, from the
get-go. That's the way he worked. His brain works differently than mine or
James'. We all achieved amazing reusable results, just each in our different
ways.

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. I didn't get a
chance to work with James and Hiram much otherwise, for example.

The flexible and "creativity over rules" spirit kept it fun. When hard lines
are taken, it becomes not fun very quickly.

I'd want to see tolerance that it is ok to not aim for reuse on the first line
of code. I wouldn't want

Re: TomEE and MicroProfile

2018-02-28 Thread Andy Gumbrecht


Hi All,

Good to see talk on moving TomEE into the MP scene.

The MP landing page of interest is this one: 
https://wiki.eclipse.org/MicroProfile/Implementation


As we can see, TomEE is a long way behind here.

I feel that we need to act 'really fast' to get TomEE on that board as 
soon as possible, even if it is 'just' a distribution with mp-config 
enabled - That would give us two hits on that board with little effort, 
mp 1.0 and config 1.2.


I don't think we should be waiting to get as much in as possible before 
releasing something, it should be our priority to release something now. 
That could easily be TomEE 7, and 8 soon after. In fact, the longer we 
wait, the less significant TomEE will become to MP.


I don't think it would be too hard to maintain the 7 and 8 versions by 
adding mp-impls as soon as we have them available.


As you know, all I wanted to do recently was to open up mp modules space 
for this work to begin on getting TomEE up to spec - Again, not to 
create implementations or libraries. I still believe this is a logical 
approach, to have a module per spec in TomEE. These modules should be 
focusing on getting the current impls of choice (Wherever they come 
from!) integrated into TomEE, and passing the corresponding TCKs 
provided by MP. I'd personally like to see TomEE MP modules high up in 
the project hierarchy and not buried, but I will leave that up to you 
guys for obvious reasons. I'd just ask that any one of you guys to get 
the ball rolling on this so that we can maybe divide the work?


Andy.


On 27/02/18 16:02, Roberto Cortez wrote:
  
Thanks Romain,

I'll have a look into JL work.
Cheers,RobertoOn Tuesday, February 27, 2018, 2:53:50 PM GMT, Romain Manni-Bucau 
 wrote:
  
  Hi Roberto,


JL already has some work which is close to be imported in Geronimo
dedicated project so maybe ensure you don't duplicate the effort here.
Also we'll need to have a tomee MP module (which can compiles or assemble
modules) on Java 8 otherwise we can't support any MP spec since they all
require java 8 quite hardly in their API so probably time to add to
apache-tomee module a mp assembly which would import java 8 modules (vs wp
and fp will not).




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>

2018-02-27 15:38 GMT+01:00 Roberto Cortez :


Hi,
Thank you for the discussion.
I do believe that we should provide a MP 1.3 implementation under TomEE 7.
As we know, moving from major versions is sometimes slow in a lot of
organizations, even if the upgrade only requires a zip file.
So, I'll look into integrating some of the work under TomEE 7 and then 8.
Cheers,Roberto    On Thursday, February 22, 2018, 9:02:44 AM GMT, Romain
Manni-Bucau  wrote:

   2018-02-22 9:45 GMT+01:00 Gurkan Erdogdu :


   Even if we use IRC or similar tools, we need to get all of these
discussion to our mailing lists. ASF main idea is to use the mailing

lists

for these discussions. I think such decisions taken from other places
really kills the projects and community


You read it wrong, the decisions have been done on the list the asf way.
The community and user activity doesn't always go through the list since it
requires steps to enter whereas twitter and irc are no step - guess it is
why we miss activities on the list.



CheersGurkan

     On Thursday, February 22, 2018, 11:38:02 AM GMT+3, Romain Manni-Bucau

<

rmannibu...@gmail.com> wrote:

   2018-02-22 9:35 GMT+01:00 Gurkan Erdogdu :


After all the same (active!) people are involved in most of those

projects anyway. When you have lots of similar projects, it is not easy

to

create and maintain the healthy community , only couple of active
developers works on these projects without general community consensus

.

I

prefer to have one project which covers all of these similar

technologies.
Except it doesn't work in practise I think - we tried and failed - cause
communities are actually different. Sadly it goes through IRC/twitter a

lot

and seems mails are no more mainstream but core dev are the same, users

are

not.
If we see a cost we can't pay we'll probably merge them but it is clearly
not the case today so no real point merging them and loosing users.



CheersGurkan
     On Thursday, February 22, 2018, 11:10:57 AM GMT+3, Mark Struberg
 wrote:

   > 4. Hammock: real MP server based on cdi (tomee cant be that)
Well, MP defines just a _minimal_ requirement and a set of additional
technologies.TomEE can easily implement these and call itself a
MicroProfile server.
BUT: it will be really hard to trim down TomEE to this bare minimum

Re: JMS examples are really not intuitive

2018-02-27 Thread Andy Gumbrecht


Just to get you started, all the examples are maven projects.

Open a console, cd into the directory of the example you want to run, 
and run:


mvn clean install

Sometimes setting up eclipse is tricky.

Andy.


On 27/02/18 03:16, Rodolfo Forte wrote:

Hi!

I was trying to run some JMS examples on Tomcat and I felt really lost with
the available (or lack thereof) material.

I found no simple, direct way to do it with Tomcat server (I'm using 9), so
I tried TomEE, but all the examples under
http://tomee.apache.org/examples-trunk/ do not work by themselves.

There must be important configuration steps that are missing. I've
downloaded the latest TomEE server, created the server within Eclipse and
ran the examples, which pop up error:
javax.ejb.EJBException: No EJBContainer provider available: no provider
names had been found.

Sorry if I'm missing something, but really there is no help whatsoever
easily available.



--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: surefire nofork

2018-02-18 Thread Andy Gumbrecht

I think this was done in the past more due to all the port conflicts on 
the buildbot. But yes, there is also a lot of test code that is not 
particularly good at cleaning up.



On 17/02/18 14:59, Mark Struberg wrote:

Hi!
Just figured master uses false
That is usually an indicator that we do not properly isolate between tests or 
do not properly clean up. Which is not that good.Could we probably go back and 
investigate what is really broken?Gut feeling is that this just removes the 
message but leaves the problem in the code.

LieGrue,strub



--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: tomee git commit: Revert "Upgrade HSQLDB to 2.3.5"

2018-02-16 Thread Andy Gumbrecht

What broke? I'd be extremely rare that even a major version change on 
HSQLDB broke anything.



On 15/02/18 22:41, Jonathan Gallimore wrote:

Reverting this temporarily. I created a local buildbot setup that should
fairly closely match the ASF one, and was able to reproduce the build
issue. Reverting this to see if it actually fixes the issue on the CI. If
it doesn't I'll revert the revert, if it does, we'll need to figure out how
to fix things so we can update this dependency and keep the tests working.

Jon

On Thu, Feb 15, 2018 at 9:39 PM,  wrote:


Repository: tomee
Updated Branches:
   refs/heads/master eb8199f1d -> 613c847e4


Revert "Upgrade HSQLDB to 2.3.5"

This reverts commit 7b1ad5f0aedcc2cad68b67604f0ec33acd3b511d.


Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/613c847e
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/613c847e
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/613c847e

Branch: refs/heads/master
Commit: 613c847e436d8658db45e4013a0c699560a81579
Parents: eb8199f
Author: Jonathan Gallimore 
Authored: Thu Feb 15 18:25:54 2018 +
Committer: Jonathan Gallimore 
Committed: Thu Feb 15 18:25:54 2018 +

--
  pom.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/tomee/blob/613c847e/pom.xml
--
diff --git a/pom.xml b/pom.xml
index 6fc6360..58581b8 100644
--- a/pom.xml
+++ b/pom.xml
@@ -183,7 +183,7 @@
  1.2.17
  2.0.1
  4.2.0
-2.3.5
+2.3.2
  1.2.20
  2.7.2
  4.2.18.Final




--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Re: Let's do better

2018-02-13 Thread Andy Gumbrecht

Totally agree with you Mark. My initial response was polite as usual, I 
acknowledged my mistake and reverted quickly and explained my intention. 
Then comes the all too familiar b... slap, another one - Jean-Louis 
response is the best one, but that also can misfire - "What are you 
'f'ing doing with my car?", will instantly change the tone and you end 
up resenting the fact you even considered washing it. My problem is I 
never slap first, but I really don't respond well when I get one - It's 
the old soldier in me I guess.


I take the premise, you're standing in a bar. I'm an extremely happy 
drinker, but don't ask me "What you lookin at?" or spill my beer - In 
fact, if you do, my first response is "Excuse me?" (Diplomacy), it's the 
"I said, what are you looking at?" that tips the balance for me. I make 
an equal effort to be courteous and not spill anyone else's beer in a 
bar. If I keep getting my beer spilt then as Mark points out, find 
another pub. Only one choice for me, as I really don't want to fight. 
That doesn't mean I can't.


Andy.


On 13/02/18 10:25, Mark Struberg wrote:

It's our duty as PMC members to review committs. And of course a commit with 
the comment 'starting a thing which was decided not to be done' should spark 
EVERYONES curiosity.

All the PMC members at TomEE and Geronimo have been aware of the discussions 
and nobody said anything against putting the reusable parts at Geronimo. Au 
contraire it was widely agreed. Both the Geronimo PMC and also the TomEE PMC 
have been discussing this for months.

Romain and I spent lots of time to find a viable compromise which is in the 
best interest of the broader communities. This included the option of moving 
the existing Geronimo parts to TomEE. Actually whether those parts are hosted 
at TomEE or Geronimo is really a minor point. After all the _active_ people are 
the same in both projects anyway.

Andy made his intent clear now, I applogized. And I don't feel bad for it. 
Because it was very important to clarify the situation.

LieGrue,
strub



Am 13.02.2018 um 09:52 schrieb Jean-Louis Monteiro :

Morning Mark,

I appreciate the feedback, but I disagree.

Adding an @Ignore on a test failing does not fix the issue (either the test
or the code)
Putting a napkin over some c... does not clean it up.

This is not the first time it happens, so I'd rather prefer the community
to vent, put the problems on the table so we can tackle them, instead of
pretending the problem is solved and in one month from now, we are in the
same position.

I do not plan to put fuel on the fire.

I'm suggesting that instead of shooting at the daughter and therefor not
getting any chance to know it was a present, one should first ask
questions.
"My sweet heart, why do you have the keys of the car?"
"What do you plan to do with them?"

I was trying to add some guidance to your good example of the daughter and
her father.

You are a father, so am I.

Hope it helps.



--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Feb 13, 2018 at 9:05 AM, Mark Struberg 
wrote:


Please all stop putting fuel into the fire.

LieGrue,
strub



Am 13.02.2018 um 08:48 schrieb Jean-Louis Monteiro <

jlmonte...@tomitribe.com>:

Instead of shooting to someone or start arguing. Simply asking would take
all misunderstand off and avoid this disgusting mess.

Le 13 févr. 2018 08:33, "Mark Struberg"  a
écrit :


+1  words - and especially brief once as emails - are just a mapping

from

the reality to some 'transport mechanism' (Claude Shannon sender

theoreme

anyone?).
And of course each 'map' is a huge simplification from the reality and
thus prone to be misinterpreted.

The important part here is that those clashes bring up some difference

in

view.
And yes, I also think this has nothing to do with immature or childish.

We

are all just passionate.
So the first very important step is to identify the pain point.

For Romain and me, etc is to avoid duplication of work which already got
done in other ASF projects.
And to not have those modules hardcoded bound to the TomEE Application
Server but to be reusable for other projects.
Please note that I'm talking about the Appliation Server only and not
about the TomEE project as governance body.

I also had an important lesson in the 90s:

If you have a problem
1.) solve it
2.) if you cannot solve it, live with it
3.) if you cannot live with it, leave it.

More generally:
There are some points which totally doesn't matter to someone.
There are other points which we would love to see a certain outcome, but
we would also perfectly accept a compromise.
And is also a category of points where we simply cannot live with a
compromise. Or where we would simply stop being part of it.

In the current situatio

Re: Fwd: [2/4] tomee git commit: Preparation for Microprofile


No worries Mark - I'll just work off the grid for now.


On 12/02/18 21:52, Mark Struberg wrote:

Oki, that was totally not obvious - sorry for getting this wrong ;)

Well but my other points are still valid: how do we like to continue with that 
stuff?With sheldon, etc getting donated we HAVE to solve those issues.Except if 
we say that those parts will become heavily TomEE centric and would not run 
anywhere else.
But alone from a maintenance aspect I would prefer to have those things modular.
LieGrue,strub
 On Monday, 12 February 2018, 21:25:56 CET, Romain Manni-Bucau 
 wrote:
  
  You can PR it @geronimo if it is to add test coverage or to contribute

samples. We are on github normally.

Let me know if you need some help/pointers.

Le 12 févr. 2018 21:21, "Andy Gumbrecht"  a
écrit :


There is no implementation here at all, it is just the current spec
modules to start writing tests. I wanted to start writing a test for
geronimo config without interfering with anything else. No worries. I'll
revert it and start a private branch.


On 12/02/18 20:45, Mark Struberg wrote:


Well the last discussion was about finding a way to unify the efforts.I
totally don't care whether this will be over at Geronimo or at TomEE.
If it is at TomEE, then this effort clearly has to be done in a way which
doesn't confuse users.Which means it must be totally clear which parts are
reusable components, and which parts are just working in TomEE.
LieGrue,strub

       On Monday, 12 February 2018, 19:39:24 CET, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:
     Hi

Is it a commit/push error? Discussion didnt outcome to that if I got it
right. Discussion led to put it outside tomee.git at least then preference
was more about to concentrate a single effort under Geronimo umbrella for
tomee and asf benefit.

How did we end up here? Did I miss a discussion?

-- Message transféré --
De : 
Date : 12 févr. 2018 19:06
Objet : [2/4] tomee git commit: Preparation for Microprofile
À : 
Cc :

Preparation for Microprofile



Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/36c9c47e
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/36c9c47e
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/36c9c47e

Branch: refs/heads/master
Commit: 36c9c47eda2ecb2bdd7f5a4ff78b8610d83589df
Parents: 118060d
Author: Andy Gumbrecht 
Authored: Mon Feb 12 18:40:12 2018 +0100
Committer: Andy Gumbrecht 
Committed: Mon Feb 12 18:40:12 2018 +0100

--
   arquillian/arquillian-common/pom.xml            |  2 +-
   arquillian/arquillian-openejb-embedded/pom.xml  |  2 +-
   .../pom.xml                                    |  2 +-
   arquillian/arquillian-tck/pom.xml              |  2 +-
   arquillian/arquillian-tomee-common/pom.xml      |  2 +-
   arquillian/arquillian-tomee-embedded/pom.xml    |  2 +-
   .../arquillian-tomee-moviefun-example/pom.xml  |  2 +-
   arquillian/arquillian-tomee-remote/pom.xml      |  2 +-
   .../arquillian-tomee-codi-tests/pom.xml        |  2 +-
   .../arquillian-tomee-config-tests/pom.xml      |  2 +-
   .../arquillian-tomee-jaxrs-tests/pom.xml        |  2 +-
   .../arquillian-tomee-jaxws-tests/pom.xml        |  2 +-
   .../arquillian-tomee-jms-tests/pom.xml          |  2 +-
   .../arquillian-tomee-webprofile-tests/pom.xml  |  2 +-
   arquillian/arquillian-tomee-tests/pom.xml      |  2 +-
   .../arquillian-tomee-webapp-remote/pom.xml      |  2 +-
   arquillian/pom.xml                              |  2 +-
   arquillian/ziplock/pom.xml                      |  2 +-
   examples/access-timeout-meta/pom.xml            |  2 +-
   examples/access-timeout/pom.xml                |  2 +-
   examples/alternate-descriptors/pom.xml          |  2 +-
   examples/applet/pom.xml                        |  2 +-
   examples/application-composer/pom.xml          |  2 +-
   examples/applicationcomposer-jaxws-cdi/pom.xml  |  2 +-
   examples/applicationexception/pom.xml          |  2 +-
   examples/arquillian-jpa/pom.xml                |  2 +-
   examples/async-methods/pom.xml                  |  2 +-
   examples/async-postconstruct/pom.xml            |  2 +-
   .../bean-validation-design-by-contract/pom.xml  |  2 +-
   .../cdi-alternative-and-stereotypes/pom.xml    |  2 +-
   examples/cdi-application-scope/pom.xml          |  2 +-
   examples/cdi-basic/pom.xml                      |  2 +-
   examples/cdi-ejbcontext-jaas/pom.xml            |  2 +-
   examples/cdi-events/pom.xml                    |  2 +-
   examples/cdi-interceptors/pom.xml              |  2 +-
   examples/cdi-produces-disposes/pom.xml          |  2 +-
   examples/cdi-produces-field/pom.xml            |  2 +-
   examples/cdi-realm/pom.xml                      |  2 +-
   examples/cdi-request-scope/pom.xml              |  2 +-
   examples/cdi-session-scope/pom.xml              |  2 +-

Re: Implementing Microprofile JWT

I find the discussions and working on TomEE have become tedious, 
contentious, unrewarding and fruitless in order to continue working on 
the project in my free time. That'd be why I've not contributed 
recently, but not speaking for others of course. I wasn't actually 
trying to start any implementations there, rather integration modules 
(I'd started to test geronimo config for example). And yes, I guess I 
avoided the conversation at my own fault. It'll not happen again, I'm 
done with it. So please feel free to carry on. Me personally, I only get 
annoyed when something gets trashed. Nothing was done in any Tomitribe 
capacity this evening, but those accusations are pretty commonplace now. 
I would point the 'killing' and 'ownership' finger in another direction. 
I see efforts have obviously been directed away from TomEE to the 
benefit of other projects and detriment of TomEE, and you know I'm not 
talking about geronimo. Anyways, no problem. Not going to get stressed 
about it. Have fun.


Andy.


On 12/02/18 21:44, Mark Struberg wrote:

Well, let's be a bit more specific.
a.)
No, Geronimo of course does not have have a monopoly on creating microprofile 
implementations at the ASF. Nor does TomEE.
Geronimo a good place for reusable JavaEE parts though. And G started to 
implement Microprofile specifications 2 years ago already. There is already 
quite a lot in existence over there. You really should take a look over the 
fence.

Instead of duplicating the work which is already done I would prefer if some 
folks would help with more important tasks. E.g. finally finishing TomEE8. 
Romain and I have so far been the ONLY ones working on that effort for the 
whole last year.
b.) > I understand it is not the most convenient for tomitribe which probably

perfers to own the full project(s) Tomitribe itself does not own TomEE nor 
created it, etc.The actual core part of TomEE (OpenEJB) is acually only a 
fraction of what the whole project is.It's an excellent aggregator project. But 
if you count in all the other parts which were needed to create TomEE7 and 8, 
then the whole sum is about 20 times the size of openejb: tomcat, openwebbeans, 
bval, johnzon, geronimo-tx, geronimo-javamail, geronimo-specs, cxf, activemq, 
openjpa, MyFaces, etc etc Each of those projects has at


c.) There have been a lot of talks about moving the reusable parts of Geronimo 
under the umbrella of the TomEE project. That would be perfectly fine. But I 
iterate it once again. There are 2 tasks to do before we can go on:
1.) TomEE needs to become an umbrella project2.) the name of the reusable 
components must be clearly separated from the TomEE Application 
Server.Otherwise TomEE will hit the same problems like Geronimo and MyFaces had 
- that people would not identify those components as being totally independent 
of the TomEE application server and separately usable.


LieGrue,strub
  



 On Monday, 12 February 2018, 21:20:57 CET, Romain Manni-Bucau 
 wrote:
  
  No Andy, as mentionned in the discussion Geronimo hosts the microprofile

@asf. This is why jwt should probably be done in geronimo which is the asf
ee related project umbrella.

I understand it is not the most convenient for tomitribe which probably
perfers to own the full project(s) but as a foundation member I d really
like to not let company details pollute projects.

Also the discussion made clear to not do it in current repo whatever
project is used as umbrella so we should revert that and finish the
discussion before any action to not kill tomee project by a hard company
driven management making it no more in the OSS spirit.

Le 12 févr. 2018 21:14, "Andy Gumbrecht"  a
écrit :


"Parts of the components skeletons you just created"

They're just logically named empty modules for pending work?


On 12/02/18 20:42, Mark Struberg wrote:


And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we
finally get back to discussing such things on the Apache lists?

Before we go on I'd would first finish the discussion how we want to turn
TomEE into an umbrella project or how the structure would be. And
whether/how we want to integrate the modular Geronimo parts into one
project or not.

Parts of the components skeletons you just created do already exist at
the ASF.

LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht <
agumbre...@tomitribe.com> wrote:


Added project stubs:
https://github.com/apache/tomee/tree/master/microprofile

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:

Hi,

Ok thanks guys.
@Rudy, you are most welcome :)

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher <

rdebussc...@gmail.com <mailto:rdebussc...@gmail.com>>

wrote:


I think it is a very important spec, also for non-microprofi

Re: Implementing Microprofile JWT

Any issues let me know and I'll fix tomorrow - not staying up for the 
buildbot.



On 12/02/18 21:14, Andy Gumbrecht wrote:


"Parts of the components skeletons you just created"

They're just logically named empty modules for pending work?


On 12/02/18 20:42, Mark Struberg wrote:

And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we 
finally get back to discussing such things on the Apache lists?


Before we go on I'd would first finish the discussion how we want to 
turn TomEE into an umbrella project or how the structure would be. 
And whether/how we want to integrate the modular Geronimo parts into 
one project or not.


Parts of the components skeletons you just created do already exist 
at the ASF.


LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
 wrote:



Added project stubs:
https://github.com/apache/tomee/tree/master/microprofile

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
mailto:rdebussc...@gmail.com>>

> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a 
bit with

>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
mailto:strub...@yahoo.de.invalid>>

>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few 
modular

>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects 
together,

>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to 
fulfil:
>>> If we move those portable parts to TomEE, then this would mean 
that TomEE

>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community 
(which has a

>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within 
TomEE -

>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts 
Department' :)

>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to 
ease

>>> backward compatibility.
>>>
>>>
>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>
>>>> :
>>>>
>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>> osant...@tomitribe.com <mailto:osant...@tomitribe.com>>:
>>>>
>>>>> Guys, I have a question:
>>>>>
>>>>> Why not a project to each implementation?
>>>>>
>>>> this is the case but geronimo is used as an umbrella project.
>>>>
>>>>
>>>>> This way I can use just a specific if I want also.
>>>>>
>>>> exactly the goal and user usage AFAIK ;)
>>>>
>>>> long story short: we learnt from the past errors and since 
always the

>>> same
>>>> people work on these projects it is better to not split it accross N
>>>> communities since
>>>> it leads to a lot of efforts for these people. Having a single 
umbrella

>>>> project with N subprojects reduces the administrative work etc and
>>> enhance
>>>> the projects productivity.
>>>>
>>>>
>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> Hi JL,
>>>>>>
>>>>>> Microprofile apa

Re: Implementing Microprofile JWT


Reverted.


On 12/02/18 21:14, Andy Gumbrecht wrote:


"Parts of the components skeletons you just created"

They're just logically named empty modules for pending work?


On 12/02/18 20:42, Mark Struberg wrote:

And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we 
finally get back to discussing such things on the Apache lists?


Before we go on I'd would first finish the discussion how we want to 
turn TomEE into an umbrella project or how the structure would be. 
And whether/how we want to integrate the modular Geronimo parts into 
one project or not.


Parts of the components skeletons you just created do already exist 
at the ASF.


LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
 wrote:



Added project stubs:
https://github.com/apache/tomee/tree/master/microprofile

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
mailto:rdebussc...@gmail.com>>

> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a 
bit with

>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
mailto:strub...@yahoo.de.invalid>>

>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few 
modular

>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects 
together,

>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to 
fulfil:
>>> If we move those portable parts to TomEE, then this would mean 
that TomEE

>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community 
(which has a

>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within 
TomEE -

>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts 
Department' :)

>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to 
ease

>>> backward compatibility.
>>>
>>>
>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>
>>>> :
>>>>
>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>> osant...@tomitribe.com <mailto:osant...@tomitribe.com>>:
>>>>
>>>>> Guys, I have a question:
>>>>>
>>>>> Why not a project to each implementation?
>>>>>
>>>> this is the case but geronimo is used as an umbrella project.
>>>>
>>>>
>>>>> This way I can use just a specific if I want also.
>>>>>
>>>> exactly the goal and user usage AFAIK ;)
>>>>
>>>> long story short: we learnt from the past errors and since 
always the

>>> same
>>>> people work on these projects it is better to not split it accross N
>>>> communities since
>>>> it leads to a lot of efforts for these people. Having a single 
umbrella

>>>> project with N subprojects reduces the administrative work etc and
>>> enhance
>>>> the projects productivity.
>>>>
>>>>
>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> Hi JL,
>>>>>>
>>>>>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>>>&g

Re: Fwd: [2/4] tomee git commit: Preparation for Microprofile

There is no implementation here at all, it is just the current spec 
modules to start writing tests. I wanted to start writing a test for 
geronimo config without interfering with anything else. No worries. I'll 
revert it and start a private branch.



On 12/02/18 20:45, Mark Struberg wrote:

Well the last discussion was about finding a way to unify the efforts.I totally 
don't care whether this will be over at Geronimo or at TomEE.
If it is at TomEE, then this effort clearly has to be done in a way which 
doesn't confuse users.Which means it must be totally clear which parts are 
reusable components, and which parts are just working in TomEE.
LieGrue,strub
  


 On Monday, 12 February 2018, 19:39:24 CET, Romain Manni-Bucau 
 wrote:
  
  Hi


Is it a commit/push error? Discussion didnt outcome to that if I got it
right. Discussion led to put it outside tomee.git at least then preference
was more about to concentrate a single effort under Geronimo umbrella for
tomee and asf benefit.

How did we end up here? Did I miss a discussion?

-- Message transféré --
De : 
Date : 12 févr. 2018 19:06
Objet : [2/4] tomee git commit: Preparation for Microprofile
À : 
Cc :

Preparation for Microprofile



Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/36c9c47e
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/36c9c47e
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/36c9c47e

Branch: refs/heads/master
Commit: 36c9c47eda2ecb2bdd7f5a4ff78b8610d83589df
Parents: 118060d
Author: Andy Gumbrecht 
Authored: Mon Feb 12 18:40:12 2018 +0100
Committer: Andy Gumbrecht 
Committed: Mon Feb 12 18:40:12 2018 +0100

--
  arquillian/arquillian-common/pom.xml            |  2 +-
  arquillian/arquillian-openejb-embedded/pom.xml  |  2 +-
  .../pom.xml                                    |  2 +-
  arquillian/arquillian-tck/pom.xml              |  2 +-
  arquillian/arquillian-tomee-common/pom.xml      |  2 +-
  arquillian/arquillian-tomee-embedded/pom.xml    |  2 +-
  .../arquillian-tomee-moviefun-example/pom.xml  |  2 +-
  arquillian/arquillian-tomee-remote/pom.xml      |  2 +-
  .../arquillian-tomee-codi-tests/pom.xml        |  2 +-
  .../arquillian-tomee-config-tests/pom.xml      |  2 +-
  .../arquillian-tomee-jaxrs-tests/pom.xml        |  2 +-
  .../arquillian-tomee-jaxws-tests/pom.xml        |  2 +-
  .../arquillian-tomee-jms-tests/pom.xml          |  2 +-
  .../arquillian-tomee-webprofile-tests/pom.xml  |  2 +-
  arquillian/arquillian-tomee-tests/pom.xml      |  2 +-
  .../arquillian-tomee-webapp-remote/pom.xml      |  2 +-
  arquillian/pom.xml                              |  2 +-
  arquillian/ziplock/pom.xml                      |  2 +-
  examples/access-timeout-meta/pom.xml            |  2 +-
  examples/access-timeout/pom.xml                |  2 +-
  examples/alternate-descriptors/pom.xml          |  2 +-
  examples/applet/pom.xml                        |  2 +-
  examples/application-composer/pom.xml          |  2 +-
  examples/applicationcomposer-jaxws-cdi/pom.xml  |  2 +-
  examples/applicationexception/pom.xml          |  2 +-
  examples/arquillian-jpa/pom.xml                |  2 +-
  examples/async-methods/pom.xml                  |  2 +-
  examples/async-postconstruct/pom.xml            |  2 +-
  .../bean-validation-design-by-contract/pom.xml  |  2 +-
  .../cdi-alternative-and-stereotypes/pom.xml    |  2 +-
  examples/cdi-application-scope/pom.xml          |  2 +-
  examples/cdi-basic/pom.xml                      |  2 +-
  examples/cdi-ejbcontext-jaas/pom.xml            |  2 +-
  examples/cdi-events/pom.xml                    |  2 +-
  examples/cdi-interceptors/pom.xml              |  2 +-
  examples/cdi-produces-disposes/pom.xml          |  2 +-
  examples/cdi-produces-field/pom.xml            |  2 +-
  examples/cdi-realm/pom.xml                      |  2 +-
  examples/cdi-request-scope/pom.xml              |  2 +-
  examples/cdi-session-scope/pom.xml              |  2 +-
  examples/change-jaxws-url/pom.xml              |  2 +-
  examples/client-resource-lookup-preview/pom.xml |  2 +-
  examples/component-interfaces/pom.xml          |  2 +-
  examples/cucumber-jvm/pom.xml                  |  2 +-
  examples/custom-injection/pom.xml              |  2 +-
  examples/datasource-ciphered-password/pom.xml  |  2 +-
  examples/datasource-definition/pom.xml          |  2 +-
  examples/datasource-versioning/pom.xml          |  2 +-
  examples/decorators/pom.xml                    |  2 +-
  examples/deltaspike-configproperty/pom.xml      |  2 +-
  examples/deltaspike-exception-handling/pom.xml  |  2 +-
  examples/deltaspike-fullstack/pom.xml          |  2 +-
  examples/deltaspike-i18n/pom.xml                |  2 +-
  examples/dynamic-dao-implementation/pom.xml    |  2 +-
  examples/dynamic-datasource-routing/pom.xml    |  2 +-
  examples/dynamic-impleme

Re: Implementing Microprofile JWT


"Parts of the components skeletons you just created"

They're just logically named empty modules for pending work?


On 12/02/18 20:42, Mark Struberg wrote:

And what's that for?

Is there any behind the scene stuff going on at Tomitribe or can we 
finally get back to discussing such things on the Apache lists?


Before we go on I'd would first finish the discussion how we want to 
turn TomEE into an umbrella project or how the structure would be. And 
whether/how we want to integrate the modular Geronimo parts into one 
project or not.


Parts of the components skeletons you just created do already exist at 
the ASF.


LieGrue,
strub



On Monday, 12 February 2018, 20:22:53 CET, Andy Gumbrecht 
 wrote:



Added project stubs:
https://github.com/apache/tomee/tree/master/microprofile

Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:
> Hi,
>
> Ok thanks guys.
> @Rudy, you are most welcome :)
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
mailto:rdebussc...@gmail.com>>

> wrote:
>
>> I think it is a very important spec, also for non-microprofile
>> implementations as it can enhance the interoperability of all servers.
>>
>> I'm also very interested in the implementation (and want to help a 
bit with

>> it also :) )
>>
>> regards
>> Rudy
>>
>>
>>
>> On 2 February 2018 at 11:23, Mark Struberg 
mailto:strub...@yahoo.de.invalid>>

>> wrote:
>>
>>> To clarify this even further:
>>> The Geronimo Server is now officially dead.
>>> But the Geronimo project is not. It alredy contains quite a few 
modular

>>> parts which are reused in many ASF projects and also outside.
>>> Examples is the geronimo-transaction-manager, geronimo-javamail,
>>> geronimo-config, xbean-finder, etc
>>>
>>> Of course it would probably make sense to fold those 2 projects 
together,

>>> as already discussed in the past.
>>> I'm still all open to it, but I have an important criterium to fulfil:
>>> If we move those portable parts to TomEE, then this would mean 
that TomEE

>>> would become an 'Umbrella project'.
>>> And further that we would need a new name for those portable parts.
>>> They would effectively be mainatained by the TomEE community 
(which has a

>>> big overlap with Geronimo anyway) but those parts must clearly be
>>> recognized separately from TomEE.
>>>
>>> Otherwise people will assume that those parts only work within TomEE -
>>> where in reality they would even work on WildFly or Liberty, etc. or
>> even a
>>> naked Tomcat.
>>> Got me?
>>>
>>> We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I'd also love to keep the org.apache.geronimo package name to ease
>>> backward compatibility.
>>>
>>>
>>>> Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>
>>>> :
>>>>
>>>> 2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
>>>> osant...@tomitribe.com <mailto:osant...@tomitribe.com>>:
>>>>
>>>>> Guys, I have a question:
>>>>>
>>>>> Why not a project to each implementation?
>>>>>
>>>> this is the case but geronimo is used as an umbrella project.
>>>>
>>>>
>>>>> This way I can use just a specific if I want also.
>>>>>
>>>> exactly the goal and user usage AFAIK ;)
>>>>
>>>> long story short: we learnt from the past errors and since always the
>>> same
>>>> people work on these projects it is better to not split it accross N
>>>> communities since
>>>> it leads to a lot of efforts for these people. Having a single 
umbrella

>>>> project with N subprojects reduces the administrative work etc and
>>> enhance
>>>> the projects productivity.
>>>>
>>>>
>>>>> On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> Hi JL,
>>>>>>
>>>>>> Microprofile apache effort is hosted in geronimo and John already
>> spoke
>>>>>> about it I think. Would probably sane

Re: Implementing Microprofile JWT

Added project stubs: 
https://github.com/apache/tomee/tree/master/microprofile


Andy.


On 05/02/18 11:17, Jean-Louis Monteiro wrote:

Hi,

Ok thanks guys.
@Rudy, you are most welcome :)

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Fri, Feb 2, 2018 at 11:39 AM, Rudy De Busscher 
wrote:


I think it is a very important spec, also for non-microprofile
implementations as it can enhance the interoperability of all servers.

I'm also very interested in the implementation (and want to help a bit with
it also :) )

regards
Rudy



On 2 February 2018 at 11:23, Mark Struberg 
wrote:


To clarify this even further:
The Geronimo Server is now officially dead.
But the Geronimo project is not. It alredy contains quite a few modular
parts which are reused in many ASF projects and also outside.
Examples is the geronimo-transaction-manager, geronimo-javamail,
geronimo-config, xbean-finder, etc

Of course it would probably make sense to fold those 2 projects together,
as already discussed in the past.
I'm still all open to it, but I have an important criterium to fulfil:
If we move those portable parts to TomEE, then this would mean that TomEE
would become an 'Umbrella project'.
And further that we would need a new name for those portable parts.
They would effectively be mainatained by the TomEE community (which has a
big overlap with Geronimo anyway) but those parts must clearly be
recognized separately from TomEE.

Otherwise people will assume that those parts only work within TomEE -
where in reality they would even work on WildFly or Liberty, etc. or

even a

naked Tomcat.
Got me?

We might e.g. brand them as 'TomEE Geronimo Spare Parts Department' :)

LieGrue,
strub

PS: I'd also love to keep the org.apache.geronimo package name to ease
backward compatibility.



Am 02.02.2018 um 11:08 schrieb Romain Manni-Bucau <

rmannibu...@gmail.com

:

2018-02-02 11:05 GMT+01:00 Otávio Gonçalves de Santana <
osant...@tomitribe.com>:


Guys, I have a question:

Why not a project to each implementation?


this is the case but geronimo is used as an umbrella project.



This way I can use just a specific if I want also.


exactly the goal and user usage AFAIK ;)

long story short: we learnt from the past errors and since always the

same

people work on these projects it is better to not split it accross N
communities since
it leads to a lot of efforts for these people. Having a single umbrella
project with N subprojects reduces the administrative work etc and

enhance

the projects productivity.



On Fri, Feb 2, 2018 at 7:44 AM, Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Hi JL,

Microprofile apache effort is hosted in geronimo and John already

spoke

about it I think. Would probably saner to keep it all at the same

place

for

the foundation.


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>

2018-02-02 9:39 GMT+01:00 Jean-Louis Monteiro <

jlmonte...@tomitribe.com

:


Hi all,

I was wondering if we could have the Microprofile JWT implemented in

TomEE.

What do you think?

I was reading the spec and I'd like to contribute that in.

Jean-Louis

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com





--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io


Ubique

Your comment on the TomEE blog page

2017-12-28 Thread Andy Gumbrecht

Ref: It would be nice if you can provide a page with list of all the 
implementations and their versions. e.g. OpenJPA, JSF, etc.



HI tomeefan,

I'm posting/moving this to our dev list for visibility.

I totally agree that it would be nice to have such a list. There is 
always the OSS pom.xml in the root of the project to give a better idea:


7.0.x - https://github.com/apache/tomee/blob/master/pom.xml

1.7.x - https://github.com/apache/tomee/blob/tomee-1.7.x/pom.xml

I know that's not a perfect solution, but it's finding the time to make 
a list or automate that is the issue.


The website is a simple JBake project you can find at 
https://git-wip-us.apache.org/repos/asf/tomee-site-generator.git


If you fancy taking a dig at it that would be cool.

Andy.

--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: Logging bean creation and removal

2017-11-02 Thread Andy Gumbrecht

Thanks Thiago, good to know ;-)

On 2017-11-01 20:13, Thiago Veronezi  wrote: 
> Following the lead from Jonathan, this is just a quick email for visibility.
> 
> I've added new logs for the beans creation and removal. Users can have
> those logs by activating the logger 'OpenEJB.monitoring.level' to 'FINE'.
> 
> []s,
> Thiago.
>

New Apache TomEE committers Svetlin Zarev & Jonathan S. Fisher

2017-11-02 Thread Andy Gumbrecht


Hi Everyone,

The Project Management Committee (PMC) for Apache TomEE has invited 
Svetlin Zarev & Jonathan S. Fisher to become committers and we are 
pleased to announce that they have accepted.


Being a committer enables easier contribution to the project since there 
is no need to go via the patch submission process. This should enable 
better productivity.
Being a PMC member enables assistance with the management and to guide 
the direction of the project.


I'd therefore like to take this opportunity to welcome both new 
committers Svetlin Zarev & Jonathan S. Fisher to the Apache TomEE team.


It's really nice to have you guys aboard!

Andy.

--
Andy Gumbrecht
https://twitter.com/AndyGeeDe

Re: SQL insert taking too much time in TomEE-7.0.1

2017-11-02 Thread Andy Gumbrecht


Hi Prasenjit Mahato,

Could you possibly create and share a github project so that we can 
debug this use case?


I've used Hibernate & TomEE in production for many years, so I'm very 
sure that we can find out what is wrong. It's just very hard to know 
without all the information.


Also, please 'create' a ticket on the TomEE JIRA here: 
https://issues.apache.org/jira/projects/TOMEE


Thanks,

Andy.


On 02/11/17 06:32, pmo_tomee wrote:

Hi Team,

  I am using JPA and Hibernate-5.2.8 (as persistence provider) in TomEE.
Using Oracle 10g DB.
  
I tested to insert 400 rows in TomEE and JONAS server. TomEE taking 20 sec

but jonas taking only 4 sec.

I have tested in TomEE with batch insert by  but taking 20 sec aslo.

I have checked the log in Oracle for both server given below.

*JONAS server*

call count   cpuelapsed   disk  querycurrent
rows
--- --   -- -- -- --
--
Parse1  0.00   0.00  0  0  0
0
Execute 26  0.11   0.16 10 20   7331
380
Fetch0  0.00   0.00  0  0  0
0
--- --   -- -- -- --
--
total   27  0.11   0.16 10 20   7331
380

*Here JONAS inserting 380 rows by 26 Executions*


TomEE server
-
call count   cpuelapsed   disk  querycurrent
rows
--- --   -- -- -- --
--
Parse  380  0.01   0.01  0  0  0
0
Execute380  1.26   1.28  9393   6218
380
Fetch0  0.00   0.00  0  0  0
0
--- --   -- -- -- --
--
total  760  1.27   1.30  9393   6218
380

*Here TomEE inserting 380 rows by 380 executions*

Could you help me why TomEE taking 20 sec to insert.

Is there any way to fixed it ?

Thanks & Regards
Prasenjit Mahato
mahato1...@gmail.com




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html



--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

[RESULT][VOTE] Apache TomEE 1.7.5

2017-10-24 Thread Andy Gumbrecht


The vote has now closed. The results are:

Binding Votes:

+1 [4]
 0 [1]
-1 [0]

The vote is ***successful***

--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: [VOTE] Apache TomEE 1.7.5

2017-10-24 Thread Andy Gumbrecht


Awesome Mark! I'll close the vote and promote.

Andy.


On 23/10/17 17:29, Mark Struberg wrote:

Yikes, took a bit longer.

Was only able to run a few smaller older projects, which run fine.
Rest already got moved to TomEE-7.0.x

+1

LieGrue,
strub



Am 16.10.2017 um 18:16 schrieb Andy Gumbrecht :

That would be great Mark, kinda holding off for your response.

Andy.


On 15/10/17 11:28, Mark Struberg wrote:

Hope to be able to check it tomorrow at a customer.

LieGrue,
strub


Am 12.10.2017 um 17:42 schrieb Jean-Louis Monteiro :

+1

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Oct 10, 2017 at 5:17 PM, Andy Gumbrecht  wrote:


Thanks Jon! Anyone else managed to test this yet?

Appreciate your time ;-)

Andy.



On 10/10/17 03:18, Jonathan Gallimore wrote:


+1

On Wed, Sep 27, 2017 at 12:27 PM, Andy Gumbrecht <
agumbre...@tomitribe.com>
wrote:

Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place
your
votes for a 1.7.5 release.
This version includes org.apache.tomee.patch CXF 2.6.17-TomEE, a backport
fix for CVE-2017-3156 made by Jonathan Gallimore.

Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-/
https://repository.apache.org/content/repositories/orgapachetomee-1109/
-
CXF 2.6.17-TomEE

Source:
https://repository.apache.org/content/repositories/orgapache
tomee-/org/apache/tomee/tomee-project/1.7.5/tomee-
project-1.7.5-source-release.zip
https://github.com/AndyGee/cxf/tree/tomee-2.6.17-TomEE

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-/tomee-1.7.5/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-/to
mee-1.7.5/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12312320&version=12335485

Green buildbot:
https://ci.apache.org/builders/tomee-1.7.x-ubuntu/builds/217

The RAT report indicates 0 Unknown Licenses.

Please vote:
  +1: Release
  -1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you
very
much for your time.

Andy Gumbrecht.




--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io





--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: Tomcat 8.5.23 on 7.0.4?

2017-10-16 Thread Andy Gumbrecht


Hi Sathwik,

The 7.0.4 binaries are available and passed the vote, so they're 
official - In that regard please feel free to continue your tests and 
upgrade if you are happy that your apps are working as expected.


The release notes are always available on the public TomEE JIRA: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12339959


I've held off the public release announcement until the current vote on 
TomEE 1.7.5 is final, either positive or negative (that will be today, 
16 Oct). This means I may be able to announce both at the same time and 
avoid confusion.


Andy.


On 16/10/17 05:34, Sathwik B P wrote:

Hi Guys,

Is it safe to upgrade to Tomcat 8.5.23 on 7.0.4?

I did follow this commit on master and there seems not much changes apart
from one fix to the failing testcase.
https://github.com/apache/tomee/commit/bdd41eb48076b370c07386c801
049b17fca2

I believe an @announcement has not been made yet for 7.0.4

Apache ODE is waiting to upgrade to Tomee 7.0.4. I have done a sanity test
on ODE after upgrading 7.0.4 with tomcat 8.5.23 and nothing is failing so
far on the local build.

Kindly let us know.

regards,
sathwik



--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Private voting

2017-10-16 Thread Andy Gumbrecht


Hi All,

I'm a bit concerned that things are not moving along too well on the 
private channel, so just making sure you are aware there are some 
important responses required.


Could those of you with karma please visit and ensure you are subscribed to:

https://lists.apache.org/list.html?priv...@tomee.apache.org

It will only take a few minutes of your time, but I'd like to get things 
finalized by the end of the week if possible.


Thank you for your understanding,

Andy.


--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: [VOTE] Apache TomEE 1.7.5

2017-10-16 Thread Andy Gumbrecht


That would be great Mark, kinda holding off for your response.

Andy.


On 15/10/17 11:28, Mark Struberg wrote:

Hope to be able to check it tomorrow at a customer.

LieGrue,
strub


Am 12.10.2017 um 17:42 schrieb Jean-Louis Monteiro :

+1

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Tue, Oct 10, 2017 at 5:17 PM, Andy Gumbrecht  wrote:


Thanks Jon! Anyone else managed to test this yet?

Appreciate your time ;-)

Andy.



On 10/10/17 03:18, Jonathan Gallimore wrote:


+1

On Wed, Sep 27, 2017 at 12:27 PM, Andy Gumbrecht <
agumbre...@tomitribe.com>
wrote:

Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place
your
votes for a 1.7.5 release.
This version includes org.apache.tomee.patch CXF 2.6.17-TomEE, a backport
fix for CVE-2017-3156 made by Jonathan Gallimore.

Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-/
https://repository.apache.org/content/repositories/orgapachetomee-1109/
-
CXF 2.6.17-TomEE

Source:
https://repository.apache.org/content/repositories/orgapache
tomee-/org/apache/tomee/tomee-project/1.7.5/tomee-
project-1.7.5-source-release.zip
https://github.com/AndyGee/cxf/tree/tomee-2.6.17-TomEE

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-/tomee-1.7.5/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-/to
mee-1.7.5/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12312320&version=12335485

Green buildbot:
https://ci.apache.org/builders/tomee-1.7.x-ubuntu/builds/217

The RAT report indicates 0 Unknown Licenses.

Please vote:
  +1: Release
  -1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you
very
much for your time.

Andy Gumbrecht.







--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: "How to test latest TomEE 7.0.5 snapshots (w or without Arquilian) ?"

2017-10-12 Thread Andy Gumbrecht


Sure Alex,

That sounds awesome. Create a directory for the article containing all 
images etc. The main document should be a simple text file in asciidoc 
format: http://asciidoc.org/


Ivan Junckes Filho created a cool video on how to contribute to the 
site: https://www.youtube.com/watch?v=P6IM0LDevVU


We can of course help you get anything you produce online.

Andy.


On 12/10/17 09:03, Alex The Rocker wrote:

Hi Andy,

Yes I can try to do this, because you took time to help me and this
will potentially save newcomers's & your time to have an article.

Please tell me how's the most efficient way to submit such article
(ideally I'd like to submit a few screenshots & sample files).

Best regards,
Alexandre

2017-10-12 17:38 GMT+02:00 Andy Gumbrecht :

Thanks Alex,

Really appreciate all your feedback though. It helps us get better and
better.

It would be great if you could summarize your thoughts on learning to hack
on and around TomEE. Maybe a small "Getting Started by Alex" kind of
article?

We could add it to the site and help others.

Andy.



On 12/10/17 00:45, Alex The Rocker wrote:

Hello Andy,

I got it, thank you very much for the clarification,I'm going to stick
to your recommandations!

Best regards,
Alexandre


2017-10-12 1:08 GMT+02:00 agumbrecht :

Hi Alex,

Running a git pull and then mvn install ensures you have the latest
version
available to your local machine.

The maven central repo is *never ever* going to be up to date - *Never*
rely
on a snapshot from any other source than your own local machine.

The buildbot takes many hours, and the deploy bot may take as long - no
guarantees that it will run at all or when. This a job TomEE devs have to
keep on top of - it is just a tool.

Please stop trying to use maven central as a production and or reliable
source for a snapshot - you can deploy to your own local nexus repository
if
you want to make it available to others. It's the only way.

Andy.





-
  --
  Andy Gumbrecht

  http://www.tomitribe.com
  agumbre...@tomitribe.com
  https://twitter.com/AndyGeeDe

  TomEE treibt Tomitribe ! | http://tomee.apache.org
--
Sent from:
http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html


--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io



--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: "How to test latest TomEE 7.0.5 snapshots (w or without Arquilian) ?"

2017-10-12 Thread Andy Gumbrecht


Thanks Alex,

Really appreciate all your feedback though. It helps us get better and 
better.


It would be great if you could summarize your thoughts on learning to 
hack on and around TomEE. Maybe a small "Getting Started by Alex" kind 
of article?


We could add it to the site and help others.

Andy.


On 12/10/17 00:45, Alex The Rocker wrote:

Hello Andy,

I got it, thank you very much for the clarification,I'm going to stick
to your recommandations!

Best regards,
Alexandre


2017-10-12 1:08 GMT+02:00 agumbrecht :

Hi Alex,

Running a git pull and then mvn install ensures you have the latest version
available to your local machine.

The maven central repo is *never ever* going to be up to date - *Never* rely
on a snapshot from any other source than your own local machine.

The buildbot takes many hours, and the deploy bot may take as long - no
guarantees that it will run at all or when. This a job TomEE devs have to
keep on top of - it is just a tool.

Please stop trying to use maven central as a production and or reliable
source for a snapshot - you can deploy to your own local nexus repository if
you want to make it available to others. It's the only way.

Andy.





-----
 --
 Andy Gumbrecht

 http://www.tomitribe.com
 agumbre...@tomitribe.com
 https://twitter.com/AndyGeeDe

 TomEE treibt Tomitribe ! | http://tomee.apache.org
--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html


--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
https://www.tomitribe.io

Re: [VOTE] Apache TomEE 1.7.5

2017-10-10 Thread Andy Gumbrecht


Thanks Jon! Anyone else managed to test this yet?

Appreciate your time ;-)

Andy.


On 10/10/17 03:18, Jonathan Gallimore wrote:

+1

On Wed, Sep 27, 2017 at 12:27 PM, Andy Gumbrecht 
wrote:


Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place your
votes for a 1.7.5 release.
This version includes org.apache.tomee.patch CXF 2.6.17-TomEE, a backport
fix for CVE-2017-3156 made by Jonathan Gallimore.

Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-/
https://repository.apache.org/content/repositories/orgapachetomee-1109/ -
CXF 2.6.17-TomEE

Source:
https://repository.apache.org/content/repositories/orgapache
tomee-/org/apache/tomee/tomee-project/1.7.5/tomee-
project-1.7.5-source-release.zip
https://github.com/AndyGee/cxf/tree/tomee-2.6.17-TomEE

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-/tomee-1.7.5/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-/to
mee-1.7.5/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12312320&version=12335485

Green buildbot:
https://ci.apache.org/builders/tomee-1.7.x-ubuntu/builds/217

The RAT report indicates 0 Unknown Licenses.

Please vote:
  +1: Release
  -1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you very
much for your time.

Andy Gumbrecht.

[VOTE] Apache TomEE 7.0.4 - Roll 2 [RESULT][PASSED]

2017-10-09 Thread Andy Gumbrecht

For the list...

On 28/09/17 01:01, Matthew Broadhead wrote:

This has just reminded me that i am currently stuck on
java-1.8.0-openjdk-1.8.0.131-11.b12.el7.x86_64
on CentOS 7 with TomEE 7.0.3
updating to
Version : 1.8.0.144
Release : 0.b01.el7_4
results in random freezes with no error in catalina.out

On 27/09/2017 20:10, Alex The Rocker wrote:

Hello,

+1 (non binding)

Tested this TomEE+ 7.0.4 RC with our various web apps on Linux Redhat
6.5 with Java 8 update 144.
Using JAX-RS (with Johnzon specifics), JAX-WS, JMS

Thanks,
Alexandre

2017-09-26 23:24 GMT+02:00 Andy Gumbrecht :

Hi Everyone,

I'd kindly like to ask you all to take a look at this build and
place your

votes for a 7.0.4 release.

The re-roll updates to CXF 3.1.13 and JAXB 2.3.0 (Provided).

I added comments in the previous vote that relate to Java 9, which is
experimental and requires the following (corrected) flag:

--add-module java.xml.bind

Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1107/

Source zip:
https://repository.apache.org/content/repositories/orgapachetomee-1107/org/apache/tomee/tomee-project/7.0.4/tomee-project-7.0.4-source-release.zip

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12339959

Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
+1: Release
-1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information

as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At
least 3

binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank
you very

much for your time.

Andy Gumbrecht.

[VOTE] Apache TomEE 7.0.4 - Roll 2 [PASSED]

2017-10-09 Thread Andy Gumbrecht

OK folks, that's a wrap. Three binding votes close this one and we'll 
release.


Any issues will now go out in the next release.

Thanks guys.

+1

Alexandre (Alex The Rocker)
Felipe Jaekel
Andy Gumbrecht *
Jean-Louis Monteiro *
Jonathan Gallimore *

+0

Svetlin Zarev

-1

None


On 09/10/17 12:49, Jonathan Gallimore wrote:

+1

Jon

On Tue, Sep 26, 2017 at 10:24 PM, Andy Gumbrecht 
wrote:


Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place your
votes for a 7.0.4 release.

The re-roll updates to CXF 3.1.13 and JAXB 2.3.0 (Provided).

I added comments in the previous vote that relate to Java 9, which is
experimental and requires the following (corrected) flag:

--add-module java.xml.bind


Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1107/

Source zip:
https://repository.apache.org/content/repositories/orgapache
tomee-1107/org/apache/tomee/tomee-project/7.0.4/tomee-
project-7.0.4-source-release.zip

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/to
mee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12312320&version=12339959

Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
  +1: Release
  -1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you very
much for your time.

Andy Gumbrecht.

Re: [VOTE] Apache TomEE 7.0.4 - Roll 2

2017-10-09 Thread Andy Gumbrecht


Hi Mark, how did your tests go?

Thanks, Andy.


On 09/10/17 05:58, Mark Struberg wrote:

Hi folks!

Sorry for the delay!
Running the new 7.0.4 attempt with a few customer projects now.
Will ping back once I know more.

txs and LieGrue,
strub


Am 08.10.2017 um 16:43 schrieb Romain Manni-Bucau :

It is http://repository.apache.org/snapshots/
(openejb.deployer.snapshot.repository
system property) but there is not yet a 8 snapshot


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>

2017-10-08 16:26 GMT+02:00 Alex The Rocker :


Hi Romain,

But how to find the repo for TomEE 8.0.0 based testing?

Best regards,
Alexandre


2017-10-08 16:20 GMT+02:00 Romain Manni-Bucau :

Hi Alex,

you can set as system property (through surefire)
openejb.deployer.repository=


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>

2017-10-08 14:07 GMT+02:00 Alex The Rocker :


Hi Romain,

Thank you very much for your answer:I  was able to run my Arquilian
test by adding the following line into my projet's pom.xml:



my-tomee704repo
TomEE704 repo
https://repository.apache.org/content/
repositories/orgapachetomee-1107/



(and by the way my feedback on TomEE 7.0.4 is still +1)

Question: in the general case, how one can tell which is the
appropriate repository URL to use Arquilian which a TomEE+ version
which isn't yet officialized?

For example, if I want to try TomEE+ 8.0.0, the above repository
does't allow to resolve dependencies on:

org.apache.tomee
arquillian-tomee-embedded
8.0.0 


So what's the "rule of thumb"? (and can it be documented somewhere on
tomee.apache.org?)

Best regards,
Alexandre



2017-10-08 10:51 GMT+02:00 Romain Manni-Bucau :

@Alex: did you add this repo https://repository.apache.org/
content/repositories/orgapachetomee-1107/ ?


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>

2017-10-08 10:48 GMT+02:00 Alex The Rocker :


Hello,

I am starting to use Arquilian, in particular in order to check the
impact of TomEE+ version changes on our REST services (annotations
sometimes change, such as the introduction of @JohnzonIgnore in TomEE
+ 7.x).

I naively tried changing my dependency from 7.0.3 to 7.0.4, but it's
not being resolved:

org.apache.tomee
arquillian-tomee-

embedded

7.0.4 


I guess that this is because TomEE 7.0.4 isn't yet officialized.

But yet, I fell that it would be great if I could use the current
TomEE+ 7.0.4 release candidate with Arqulian in order to give

feedback

on this RC before it's final.

What would be the simplest way to setup my pom.xml in order to run my
Arquilan tests using latest TomEE+ 7.0.4 release candidate, *using

the

embedded adapter* ?

(I guess that using the remote adapter with the RC I downloaded is an
alternative, but yet I want also the use embedded version).

Best regards,
Alexandre


2017-10-05 19:29 GMT+02:00 Alex The Rocker :

Hello Andy,

And thank you very much for your answer. I already voted a +1

based on

my applicative tests which showed no regressions of this TomEE+

7.0.4

vs. TomEE+ 7.0.3.

I can wait for a week for the "final freeze" :)

Best regards,
Alexandre


2017-10-05 19:25 GMT+02:00 Andy Gumbrecht :

The vote is open for 'at least' 72 hours, or until we get 3+

binding

votes.

I know that many of the guys are ultra busy with JavaOne at the

moment,

so I

don't expect to get a response until next week.

The review process is basically downloading the binaries and

checking

them

for complete functionality. That includes running apps and testing
everything possible, including the legal headers etc. This always

takes

time, but we do it to ensure you get a good distribution.

Thanks for your understanding. We still really appreciate your

help

and

votes, which should mean that you have just as thoroughly tested

all

your

environments. The more eyes on, the better!

Andy Gumbrecht.

I'm adding my binding vote, as I have not found any issues:

+1



On 04/10/17 00:42, Alex The Rocker wrote:

Hello Andy

Would you please speci

Re: [VOTE] Apache TomEE 7.0.4 - Roll 2

2017-10-05 Thread Andy Gumbrecht

The vote is open for 'at least' 72 hours, or until we get 3+ binding 
votes. I know that many of the guys are ultra busy with JavaOne at the 
moment, so I don't expect to get a response until next week.


The review process is basically downloading the binaries and checking 
them for complete functionality. That includes running apps and testing 
everything possible, including the legal headers etc. This always takes 
time, but we do it to ensure you get a good distribution.


Thanks for your understanding. We still really appreciate your help and 
votes, which should mean that you have just as thoroughly tested all 
your environments. The more eyes on, the better!


Andy Gumbrecht.

I'm adding my binding vote, as I have not found any issues:

+1


On 04/10/17 00:42, Alex The Rocker wrote:

Hello Andy

Would you please specific until when this vote for TomEE+ 7.0.4 is
supposed to last?

Best regards,
Alex

2017-09-28 13:37 GMT+02:00 Felipe Jaekel :

+1

2017-09-26 18:24 GMT-03:00 Andy Gumbrecht :


Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place your
votes for a 7.0.4 release.

The re-roll updates to CXF 3.1.13 and JAXB 2.3.0 (Provided).

I added comments in the previous vote that relate to Java 9, which is
experimental and requires the following (corrected) flag:

--add-module java.xml.bind


Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1107/

Source zip:
https://repository.apache.org/content/repositories/orgapache
tomee-1107/org/apache/tomee/tomee-project/7.0.4/tomee-
project-7.0.4-source-release.zip

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/to
mee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12312320&version=12339959

Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
  +1: Release
  -1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you very
much for your time.

Andy Gumbrecht.

[VOTE] Apache TomEE 1.7.5

2017-09-27 Thread Andy Gumbrecht

Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place
your votes for a 1.7.5 release.
This version includes org.apache.tomee.patch CXF 2.6.17-TomEE, a
backport fix for CVE-2017-3156 made by Jonathan Gallimore.

Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-/
https://repository.apache.org/content/repositories/orgapachetomee-1109/
- CXF 2.6.17-TomEE

Source:
https://repository.apache.org/content/repositories/orgapachetomee-/org/apache/tomee/tomee-project/1.7.5/tomee-project-1.7.5-source-release.zip
https://github.com/AndyGee/cxf/tree/tomee-2.6.17-TomEE

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-/tomee-1.7.5/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-/tomee-1.7.5/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12335485

Green buildbot:
https://ci.apache.org/builders/tomee-1.7.x-ubuntu/builds/217

The RAT report indicates 0 Unknown Licenses.

Please vote:
+1: Release
-1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you
very much for your time.

Andy Gumbrecht.

Re: [VOTE] Apache TomEE 7.0.4 - Roll 2

2017-09-27 Thread Andy Gumbrecht

It's not even dry off the press yet, so it's a little early. We'll see 
it in the next release of TomEE.


Andy


On 26/09/17 22:48, Svetlin Zarev wrote:

+0

It would be great if the tomcat dependency is updated to 8.5.21 because of
the fixed regressions with the SSL configuration

Kind regadrs,
Svetlin

2017-09-27 0:24 GMT+03:00 Andy Gumbrecht :


Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place your
votes for a 7.0.4 release.

The re-roll updates to CXF 3.1.13 and JAXB 2.3.0 (Provided).

I added comments in the previous vote that relate to Java 9, which is
experimental and requires the following (corrected) flag:

--add-module java.xml.bind


Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1107/

Source zip:
https://repository.apache.org/content/repositories/orgapache
tomee-1107/org/apache/tomee/tomee-project/7.0.4/tomee-
project-7.0.4-source-release.zip

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/to
mee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
ctId=12312320&version=12339959

Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
  +1: Release
  -1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you very
much for your time.

Andy Gumbrecht.

[VOTE] Apache TomEE 7.0.4 - Roll 2

2017-09-26 Thread Andy Gumbrecht

Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place
your votes for a 7.0.4 release.

The re-roll updates to CXF 3.1.13 and JAXB 2.3.0 (Provided).

I added comments in the previous vote that relate to Java 9, which is
experimental and requires the following (corrected) flag:

--add-module java.xml.bind

Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1107/

Source zip:
https://repository.apache.org/content/repositories/orgapachetomee-1107/org/apache/tomee/tomee-project/7.0.4/tomee-project-7.0.4-source-release.zip

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/

Legal:
https://dist.apache.org/repos/dist/dev/tomee/staging-1107/tomee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12339959

Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
+1: Release
-1 Do not release because ... See below.

If you vote -1 then please create a JIRA ticket here:
https://issues.apache.org/jira/projects/TOMEE - Include as much
information as possible and, if applicable, a unit test.

The vote will be open for 3 days or the consensus is binding (At least 3
binding votes).

Everyone, committer or not, is encouraged to test and vote. Thank you
very much for your time.

Andy Gumbrecht.

[VOTE][CANCELED] Apache TomEE 7.0.4

2017-09-26 Thread Andy Gumbrecht


 [VOTE][CANCELED] Apache TomEE 7.0.4


On 21/09/17 19:06, Andy Gumbrecht wrote:

Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place 
your votes for a 7.0.4 release.


Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1106/

Source zip:
https://repository.apache.org/content/repositories/orgapachetomee-1106/org/apache/tomee/tomee-project/7.0.4/tomee-project-7.0.4-source-release.zip 



Dist area:
https://dist.apache.org/repos/dist/dev/tomee/tomee-7.0.4/

Legal report:
https://dist.apache.org/repos/dist/dev/tomee/tomee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12339959 



Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
 +1: Release
 -1 Do not release because ...

The vote will be open for 3 days or the consensus is binding (At least 
3 binding votes).


Everyone, committer or not, is encouraged to vote. Thank you very much 
for your time, and have a nice weekend.


Andy Gumbrecht.

Re: [VOTE] Apache TomEE 7.0.4

2017-09-26 Thread Andy Gumbrecht


So, after speaking with Romain and doing a little research.

Based on this : 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html : 
The JAXB jars had been added to TomEE so that it would run out of the 
box on Java 9 prior to that information being available.


However, now we know there is a flag to switch the inclusion on in Java 9:

-addmods java.xml.bind

Therefor I am going to flag the JAXB libraries in TomEE as 'provided' (I 
have also updated the version to 2.3.0, and CXF 3.1.13) and re-roll.


We could add the above flag in the TomEE startup scripts for the next 
release (7.0.5).


If you still want to provide your own version of JAXB then you can 
always add the jars as endorsed.


I'll include this information in the release notes.

This vote is canceled.

Andy.


On 25/09/17 01:59, Mark Struberg wrote:

Additional info.

Happens if I use openejb-core to run tests on modules which have a jax-ws 
client generated via CXF.

LieGrue,
strub


Am 25.09.2017 um 09:32 schrieb Mark Struberg :

Oki, I did some extensive testing with a few customer project over the weekend.
2 of them now blow up with an Exception (used to work fine with 7.0.3).

Re: [VOTE] Apache TomEE 7.0.4


Mark,

Please try the 7.0.5-SNAPSHOT.


On 25/09/17 01:59, Mark Struberg wrote:

Additional info.

Happens if I use openejb-core to run tests on modules which have a jax-ws 
client generated via CXF.

LieGrue,
strub


Am 25.09.2017 um 09:32 schrieb Mark Struberg :

Oki, I did some extensive testing with a few customer project over the weekend.
2 of them now blow up with an Exception (used to work fine with 7.0.3).

Re: [VOTE] Apache TomEE 7.0.4


Mark,

If you remove those transient libs from the distro do you still get the 
error?


Andy.


On 25/09/17 10:59, Mark Struberg wrote:

Additional info.

Happens if I use openejb-core to run tests on modules which have a jax-ws 
client generated via CXF.

LieGrue,
strub


Am 25.09.2017 um 09:32 schrieb Mark Struberg :

Oki, I did some extensive testing with a few customer project over the weekend.
2 of them now blow up with an Exception (used to work fine with 7.0.3).

Re: Potentially having some part of documentation in the main repo


+1 for asciidoc

Andy Gumbrecht.


On 19/09/17 10:15, Jean-Louis Monteiro wrote:

I totally agree that our documentation is a pain and does not help us first
to right it and contributors to help.
Each time I have to do a fix or add something it's a pain.

So +1 to simplify it.
JBake, plain asciidoc, whatever. Just something simple.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

On Sun, Sep 17, 2017 at 8:09 AM, Romain Manni-Bucau 
wrote:


+0 to have it all and sync somehow in the site build process - i like
having it with the code since it enables some more stuff to happen but it
increases contribution cost
-0 to have it partially to ensure we dont loose contributors

Side note: if you import it, ensure to update all the contributor docs and
github proxies please

Side note 2: we can still generate doc in another project depending on main
artifacts ;)

Le 17 sept. 2017 05:26, "David Blevins"  a écrit
:


Just wrote a long description on the definition of InvocationTime and
MonitoredMethods in the JMX `@Monitor` functionality and I'm reminded on
how much of a pain it is to contribute to the documentation.  It would be
so much easier if some part of it was in the build.

I'm wondering if we want some sort of docs/ directory in our main repo.
Not thinking we add jbake to the main build, just the asciidoc.  The

fancy

processing can still happen elsewhere.

Docs like "how to contribute to the website" would stay where they are,
but things like "configuring datasources" would definitely come in.  We'd
then follow the Tomcat approach of:

  - https://tomcat.apache.org/tomcat-8.5-doc/index.html <
https://tomcat.apache.org/tomcat-8.5-doc/index.html>
  - https://tomcat.apache.org/tomcat-8.0-doc/index.html <
https://tomcat.apache.org/tomcat-8.0-doc/index.html>

etc.

I don't think we'd need to get too fancy and do one doc base per Web
Profile, Plume, etc.  just this would be enough:

  - https://tomee.apache.org/tomee-8.0-doc/index.html <
https://tomee.apache.org/tomee-8.0-doc/index.html>
  - https://tomee.apache.org/tomee-7.0-doc/index.html <
https://tomee.apache.org/tomee-7.0-doc/index.html>
  - https://tomee.apache.org/tomee-1.7-doc/index.html <
https://tomee.apache.org/tomee-1.7-doc/index.html>

When sheldon/chatterbox come in, they'd go:

  - https://tomee.apache.org/sheldon-3.0-doc/index.html <
https://tomee.apache.org/sheldon-3.0-doc/index.html>
  - https://tomee.apache.org/chatterbox-2.1-doc/index.html <
https://tomee.apache.org/chatterbox-2.1-doc/index.html>

I totally made up those version numbers for illustrative purposes.  You
get the idea.

Related note, we actually have some documentation generated from the

build

and not regenerated.  This page for example was entirely generated from

the

default service-jar.xml:

  - http://tomee.apache.org/containers-and-resources.html <
http://tomee.apache.org/containers-and-resources.html>

I remember doing that ages ago, like 2008-2011 range.  Aside from being
likely out of date, it definitely highlights the awkward relationship
between the docs and the source we currently have.


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

Re: [VOTE] Apache TomEE 7.0.4


Hi cocorossello ,

thanks for your response. I think you are right. Mark also seems to have 
an issue with this. I will be looking into and fixing it today.


Andy.


On 22/09/17 16:04, cocorossello wrote:

agumbrecht wrote

I'd kindly like to ask you all to take a look at this build and place
your votes for a 7.0.4 release.


Hi,

We've been using 7.0.4 snapshot for some time in production, so everything
works fine.

Just one quick question:
Jaxb jars (jaxb-api, jaxb-core and jaxb-impl) are included in lib folder. Is
this intended? Shouldn't they be  "provided" dependencies?


Thanks for your work




--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: [VOTE] Apache TomEE 7.0.4


Hi Mark,

Sure, let's get this pinned down before we proceed.

Are you able to provide a unit test to reproduce the issue? I'll still 
be looking at it today, but would be really appreciated if you have 
something already.


Andy.

On 25/09/17 10:59, Mark Struberg wrote:

Additional info.

Happens if I use openejb-core to run tests on modules which have a jax-ws 
client generated via CXF.

LieGrue,
strub


Am 25.09.2017 um 09:32 schrieb Mark Struberg :

Oki, I did some extensive testing with a few customer project over the weekend.
2 of them now blow up with an Exception (used to work fine with 7.0.3).

[VOTE] Apache TomEE 7.0.4


Hi Everyone,

I'd kindly like to ask you all to take a look at this build and place 
your votes for a 7.0.4 release.


Staging repo:
https://repository.apache.org/content/repositories/orgapachetomee-1106/

Source zip:
https://repository.apache.org/content/repositories/orgapachetomee-1106/org/apache/tomee/tomee-project/7.0.4/tomee-project-7.0.4-source-release.zip

Dist area:
https://dist.apache.org/repos/dist/dev/tomee/tomee-7.0.4/

Legal report:
https://dist.apache.org/repos/dist/dev/tomee/tomee-7.0.4/legal.zip

Keys:
https://dist.apache.org/repos/dist/release/tomee/KEYS

Changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12339959

Green buildbot:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/725
https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/839

The RAT report indicates 0 Unknown Licenses.

Please vote:
 +1: Release
 -1 Do not release because ...

The vote will be open for 3 days or the consensus is binding (At least 3 
binding votes).


Everyone, committer or not, is encouraged to vote. Thank you very much 
for your time, and have a nice weekend.


Andy Gumbrecht.

Re: Deploy to apache


-pl '!examples'


On 22/09/17 02:28, Andy Gumbrecht wrote:

I'm using:

mvn -V 
-DaltDeploymentRepository=repository.apache.org::default::https://repository.apache.org/service/local/staging/deploy/maven2 
-Dmaven.javadoc.opts='-Xdoclint:none -Xdoclint:-html' 
-Dmaven.javadoc.failOnError=false -DretryFailedDeploymentCount=10 
-Dsurefire.useFile=false -DdisableXmlReport=true -DuniqueVersion=false 
-ff -Dassemble -DskipTests -DfailIfNoTests=false -P 
apache-release,apache clean deploy


This always fails when it gets to the examples.

I seem to recall there was some magic required to get past this?

Anyone have a wand?

Andy.

Deploy to apache


I'm using:

mvn -V 
-DaltDeploymentRepository=repository.apache.org::default::https://repository.apache.org/service/local/staging/deploy/maven2 
-Dmaven.javadoc.opts='-Xdoclint:none -Xdoclint:-html' 
-Dmaven.javadoc.failOnError=false -DretryFailedDeploymentCount=10 
-Dsurefire.useFile=false -DdisableXmlReport=true -DuniqueVersion=false 
-ff -Dassemble -DskipTests -DfailIfNoTests=false -P 
apache-release,apache clean deploy


This always fails when it gets to the examples.

I seem to recall there was some magic required to get past this?

Anyone have a wand?

Andy.

Re: [VOTE] Accept Code donations: Sheldon and Chatterbox

+1, Andy Gumbrecht - 3rd attempt, could someone confirm they can see 
this response?



On 09/09/17 23:17, Elder Moraes wrote:

+1

+999,999,999 for a Sheldon Cooper class! ;-)

Elder

Twitter: @elderjava <https://twitter.com/elderjava>
Blog: http://eldermoraes.com




2017-09-09 16:02 GMT-03:00 David Blevins :


On Sep 9, 2017, at 1:15 AM, Mark Struberg 

wrote:

But we should not forget to check the IP.

Answers below, but I recall the Incubator IP checks being a little more
formal.  At least there used to be a document to fill out.


Is this a clean room implementation? Have there been substantial

contributions from others or does Tomitribe at least have a CLA for them?

Clean room.


* As far as I've seen all of the committers are ASF TomEE committers,

right? check!

Minus one, Daniel Cunha.


* Just checked a few files, all of them are "Licensed to the Apache

Software Foundation (ASF) under one or more..." ALv2, so this is fine from
the beginning, even while not hosted at the ASF. David, are all files that
way? Just checked a few and they have all been fine. check!

Correct.  As Jean-Louis notes we have a checkstyle to enforce the header,
so we’re good.


PS: Shedon Cooper might cause come trademark issues ;)

We can maybe have a “cooper" command in there :)  Or make people submit
their passwords three times before they can come in.


-David

Re: [VOTE] Accept Code donations: Sheldon and Chatterbox

2017-09-19 Thread Andy Gumbrecht

+1, Actually voted a while ago via nabble, but that seems to be 
swallowing messages?


Andy Gumbrecht

Re: JSTL

2017-09-14 Thread Andy Gumbrecht

Yes it's just xalan-2.7.2, and this solution seems to be/is painless 
regarding the build and TCK. The Apache Standard Taglib requires it, 
along with serializer-2.7.2. What makes adding this a breaking issue 
Mark? If it helps get a release out now to resolve a known CVE then it's 
+1 from me (hmm that rhymes). Once it is out then we can spend several 
weeks working on a better solution.


Andy.


On 14/09/17 21:00, Jonathan Gallimore wrote:

I believe its only xalan required, and not xerces as well.

What's the rationale for the -1?

We'd like to release 7.0.4, and the community appears to want a release
based on feedback we have seen on the users list.

Changing the jstlel library appears to be not-entirely-trivial (unless
someone better than me wants to give some pointers). I'd like to try it,
but I don't want it to drag on for ages and hold up a release.

We already established that we'd like this to work out the box without
requiring the user to add anything earlier in this thread.

So, how do we want to proceed? The other option appears to be picking up an
updated version of the glassfish library we had before.

Jon

On 14 Sep 2017 13:26, "Mark Struberg"  wrote:


+1 to NOT have a hard xalan and xerces dependency.
Usually we don't need it but use the version which is packaged within the
JRE.
It should really remain optional pretty please.

LieGrue,
strub



Am 31.08.2017 um 16:25 schrieb Romain Manni-Bucau https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/

rmannibucau> |

LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 15:41 GMT+02:00 Jonathan Gallimore <

jonathan.gallim...@gmail.com>

:


Thanks Romain. That is definitely the simplest path - xalan is already
marked as an optional dependency, so we wouldn't need to do anything.

From

a compliance perspective, where would this leave us? Wouldn't we need

this

to work out of the box without adding libraries to be compliant? If it
doesn't affect us in that respect, then I think we're probably good to

go.

Jon

On Thu, Aug 31, 2017 at 1:57 PM, Romain Manni-Bucau <

rmannibu...@gmail.com

wrote:


Hi Jon

there is another thread on it (probably on user@)

I think we should just make xalan optional in the lib and upgrade.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/
rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 13:19 GMT+02:00 Jonathan Gallimore <
jonathan.gallim...@gmail.com>
:


Correction - that should be: "CDDL or GPL with classpath exception".

On Thu, Aug 31, 2017 at 12:16 PM, Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:


Great question. CDDL _or_ GPL, by the look of it.
https://github.com/javaee/jstl-api/blob/master/LICENSE - same as

JAXB

I

believe.

Jon



On Thu, Aug 31, 2017 at 11:55 AM, Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:


What is the licence for GlassFish one?

Le 31 août 2017 12:38, "Jonathan Gallimore" <

jonathan.gallim...@gmail.com

a écrit :


Hi

On master we shifted from openejb-jstl to

taglibs-standard-jstlel. I

have

done the same on the 1.7.x branch, specifically to move on from

the

old

openejb-jstl (looking at
https://nvd.nist.gov/vuln/detail/CVE-2015-0254). The
taglibs-standard-jstlel
library does seem to depend on xalan, which we currently do not

include

in

TomEE.

The impact is that some XML functions in JSP code does not work,

for

example:

<%@ taglib prefix="x" uri="http://java.sun.com/jstl/xml"; %>



  
Dobkin"

genre="Comedy" rating="7" year="2005" />
  
Phillips"

genre="Action" rating="6" year="2004" />
  
Dobkin"

genre="Action" rating="6" year="2003" />
  
genre="Adventure"

rating="5" year="2002" />
  
Anderson"

genre="Comedy" rating="8" year="2001" />
  
genre="Comedy"

rating="6" year="2001" />
  
genre="Comedy"

rating="7" year="2000" />



Movie 1 Genre: 
/>
/>

fails with java.lang.NoClassDefFoundError: org/apache/xpath/XPath

(this on

both 1.7.x and master)

Including Xalan does fix this, but its a 3MB dependency.

The alternative is to use org.glassfish.web:javax.

servlet.jsp.jstl

instead,
which I have tested and seems to work. Anyone have any thoughts?

Jon





.

Re: JSTL

2017-09-14 Thread Andy Gumbrecht


I think it is best to move quickly and use method 1 and release asap.

This will buy us time to implement the better method 3.


Andy.


On 01/09/17 11:10, Jonathan Gallimore wrote:

Awesome, thanks!

Jon

On Fri, Sep 1, 2017 at 6:34 AM, Svetlin Zarev <
svetlin.angelov.za...@gmail.com> wrote:


Here it is: https://issues.apache.org/jira/browse/TOMEE-2113

2017-08-31 19:05 GMT+03:00 Jonathan Gallimore <
jonathan.gallim...@gmail.com>
:


I'll do a search and see if I can dig that out. Good shout - thank you.

Jon

On Thu, Aug 31, 2017 at 5:00 PM, Romain Manni-Bucau <

rmannibu...@gmail.com

wrote:


+1

side note: we should pby link this to the user thread, can try to find

it

back later this week if needed


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/
rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 17:54 GMT+02:00 Jonathan Gallimore <
jonathan.gallim...@gmail.com>
:


Just to make sure I understand - (3) would be your preference, but if
that's difficult you'd live with (1) if it came to it, with (2) being

your

least favorite.

We should only need to pick one - I can confirm that option (1) on

its

own

works, as does option (2) on its own. I'm definitely happy to have a

crack

at option (3) and present a PR for each and let the community decide

which

it likes the best.

Thanks for your input, I appreciate it.

Jon

On Thu, Aug 31, 2017 at 4:42 PM, Romain Manni-Bucau <

rmannibu...@gmail.com

wrote:


yep, 3, 1, 2 for the complete order (a mix of compatibility and
influence/asf consistence).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/
rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE

Factory

<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 16:53 GMT+02:00 Jonathan Gallimore <
jonathan.gallim...@gmail.com>
:


Uh, yeah, I think I misunderstood. I think we agree that the

code I

attached should work out of the box, requiring no changes to

TomEE.

That

leaves us with a few options:

1. Use the taglibs-standard-jstlel jars as we are now, and add

the

dependency for Xalan -> trivial change, but adds 3MB to our

binaries.

2. Switch to org.glassfish.web:javax.servlet.jsp.jstl which

uses a

CDDL/GPL
+ CP exception licence. Does not require Xalan -> easy change to

make

and

appears to work (I believe the license is ok for us to use it).

Not

sure

if

there are other restrictions or issues with us using that.
3. Patch the Tomcat taglibs libraries to use the XPath support

built

into

the JVM as opposed to Xalan. I did have a look at this yesterday,

and

it

didn't look like a straightforward change at the time. I'm happy

to

look

at

it again though if we feel that's the way forward.

I think you're stating a preference for (3) - is that correct?

Cheers

Jon

On Thu, Aug 31, 2017 at 3:25 PM, Romain Manni-Bucau <

rmannibu...@gmail.com

wrote:


Hmm, shout if wrong but think you misunderstood the "optional"

in

my

sentence. I meant we patch trunk to remove the adherence to

xalan.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <

https://github.com/

rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE

Factory

<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 15:41 GMT+02:00 Jonathan Gallimore <
jonathan.gallim...@gmail.com>
:


Thanks Romain. That is definitely the simplest path - xalan

is

already

marked as an optional dependency, so we wouldn't need to do

anything.

From

a compliance perspective, where would this leave us? Wouldn't

we

need

this

to work out of the box without adding libraries to be

compliant?

If

it

doesn't affect us in that respect, then I think we're

probably

good

to

go.

Jon

On Thu, Aug 31, 2017 at 1:57 PM, Romain Manni-Bucau <

rmannibu...@gmail.com

wrote:


Hi Jon

there is another thread on it (probably on user@)

I think we should just make xalan optional in the lib and

upgrade.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <

https://github.com/

rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> |

JavaEE

Factory

<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 13:19 G

Re: TomEE8 wip update

2017-08-17 Thread Andy Gumbrecht

Looks good. I'm off services as of next week. This should mean a little
more free time to work on issues.

Andy.

On 16 August 2017 at 07:16, Mark Struberg  wrote:

> fixed the last compile glitches and pushed it to our ASF repo as fb_tomee8
>
> $> git fetch
> $> git checkout -b fb_tomee8 origin/fb_tomee8
>
> Status: it now compiles at least.
> javaee-api:8.0-SNAPSHOT is deployed to the ASF snapshots repo
>
> Attention: requires Java8!
>
> Next steps: update the CDI TCK and fix broken tests.
>
> LieGrue,
> strub
>
>
> > Am 16.08.2017 um 00:25 schrieb Mark Struberg  >:
> >
> >
> > https://github.com/struberg/tomee/tree/fb_tomee8
> >
> > contains an intermediate version.
> > More to come.
> > LieGrue,strub
> >
> >
> >
> >
> > On Tuesday, 15 August 2017, 16:08:07 GMT+2, Mark Struberg
>  wrote:
> >
> >
> > Hi!
> >
> > I've now updated the javaee-api for EE8.
> > Next I'll create a fb-tomee8 branch and will update the CDI and JSON
> parts.
> >
> > All that stuff is tracked via TOMEE-2115 and sub-tasks.
> >
> > Plz ping me on IRC if you want to help. I'd like to avoid doing
> conflicting changes.
> >
> > txs and LieGrue,
> > strub
>
>


-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: NullPointerException when making rest request in TomEE 1.7.4

2017-07-20 Thread Andy Gumbrecht

Hi "jmp",

Check/Compare your application WEB-INF/lib directory against the
[TomEE]/lib directory and make sure you are not including any TomEE
provided libraries in your application.

Also, shutdown and clean out the [TomEE]/temp directory before a restart.

If you are not sure about the libs then post a list of your app libs here.

Andy.

On 20 July 2017 at 19:02, jmp  wrote:

> We recently upgraded from TomEE 1.7.3 to 1.7.4.
>
> Using the same rest servie that runs fine in 1.7.3 without issues now
> causes
> the following error message to be logged everytime a rest request is made.
>
> Jul 20, 2017 1:14:50 PM org.apache.coyote.http11.AbstractHttp11Processor
> process
> SEVERE: Error processing request
> java.lang.NullPointerException
> at
> org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:473)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(
> AbstractHttp11Processor.java:1078)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
> process(AbstractProtocol.java:625)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.
> run(JIoEndpoint.java:316)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> The rest request actually works but the log file fills up with these errors
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.n4.nabble.com/
> NullPointerException-when-making-rest-request-in-TomEE-
> 1-7-4-tp4682304.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: Contribute to this Website PR

2017-07-14 Thread Andy Gumbrecht

Watched it this morning - It's awesome Ivan! None of us are professional
video personalities, so you're already ahead.

Thank you so much for this.

Andy.

On 14 July 2017 at 01:29, Ivan Junckes Filho  wrote:

> This is the video to help people to contribute to the website. I know it is
> not perfect, but it is my first tutorial video ever and the only edition I
> did was to remove a bit of buzzing behind.
>
> If you are expert editing videos let me know...
> https://youtu.be/P6IM0LDevVU
>
> Any feedback is welcome, if you like it I can add it to the PR.
>
> Thanks.
>
>
>
> On Wed, Jul 12, 2017 at 9:30 PM, Ivan Junckes Filho  >
> wrote:
>
> > Hi TomEE devs, did a small improvement on the "Contribute to this
> Website"
> > section of "Community". It was small as it was the example I used in the
> > video I recorded teaching how to contribute to the website.
> >
> > I will try to edit the video a little bit and send for you to evaluate
> > soon.
> >
> > PR: https://github.com/apache/tomee-site-generator/pull/3
> > Live here: https://ivanjunckes.github.io/community/index.html
> >
> > Thanks.
> >
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: old openejb site is still top ranked in google!

2017-07-14 Thread Andy Gumbrecht

Sure, I'll try and follow up at the weekend, but busy. So might be next
week before I could action it.

Andy.

On 13 July 2017 at 12:56, Mark Struberg  wrote:

> That sounds like a plan!
> Can you take over this task?
>
> txs and LieGrue,
> strub
>
>
> > Am 13.07.2017 um 11:22 schrieb Andy Gumbrecht  >:
> >
> > +1 for redirect, but maybe worth using the google advice?
> > https://support.google.com/webmasters/answer/83106?hl=en
> >
> > On 13 July 2017 at 11:18, Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> > wrote:
> >
> >> On Thu, Jul 13, 2017 at 10:05 AM, Mark Struberg
>  >>>
> >> wrote:
> >>
> >>> Hi!
> >>>
> >>> I just wanted to show my colleague how to install TomEE locally.
> >>> When searching for "tomee" the old openejb site still pops up on top
> >>> http://openejb.apache.org/apache-tomee.html
> >>>
> >>> And this download section only has a 7.0.2 version and misses 7.0.3...
> >>>
> >>> We should shut down openejb.apache.org and replace it with a redirect
> to
> >>> https://tomee.apache.org.
> >>> Wdyt?
> >>>
> >>
> >> I agree. Perhaps a redirect with a delay, so we can show a message
> showing
> >> the new URL, although I'm not sure how that would affect search
> engines...
> >>
> >> Jon
> >>
> >
> >
> >
> > --
> >  Andy Gumbrecht
> >  https://twitter.com/AndyGeeDe
> >  http://www.tomitribe.com
>
>


-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: old openejb site is still top ranked in google!

2017-07-13 Thread Andy Gumbrecht

+1 for redirect, but maybe worth using the google advice?
https://support.google.com/webmasters/answer/83106?hl=en

On 13 July 2017 at 11:18, Jonathan Gallimore 
wrote:

> On Thu, Jul 13, 2017 at 10:05 AM, Mark Struberg  >
> wrote:
>
> > Hi!
> >
> > I just wanted to show my colleague how to install TomEE locally.
> > When searching for "tomee" the old openejb site still pops up on top
> > http://openejb.apache.org/apache-tomee.html
> >
> > And this download section only has a 7.0.2 version and misses 7.0.3...
> >
> > We should shut down openejb.apache.org and replace it with a redirect to
> > https://tomee.apache.org.
> > Wdyt?
> >
>
> I agree. Perhaps a redirect with a delay, so we can show a message showing
> the new URL, although I'm not sure how that would affect search engines...
>
> Jon
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: Site and "documentation" usage

Build and copy content to svn site. Then stage it for publishing.

On 11 July 2017 at 16:06, Jonathan Gallimore 
wrote:

> Someone feel free to give me a pointer to deploy it so its live :-)
>
> Jon
>
> On Tue, Jul 11, 2017 at 3:05 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Merged, thanks Ivan!
> >
> > Jon
> >
> > On Tue, Jul 11, 2017 at 2:51 PM, Ivan Junckes Filho <
> ivanjunc...@gmail.com
> > > wrote:
> >
> >> I counted +1's from Jonathan, Andy and Romain (Commiters).
> >>
> >> And also +1's for Thomas and Daniel (Contributors).
> >>
> >> Looks like a win :)
> >>
> >> On Tue, Jul 11, 2017 at 10:19 AM, Andy Gumbrecht <
> >> agumbre...@tomitribe.com>
> >> wrote:
> >>
> >> > But if everyone is happy then I'd be happy for it to be pushed. Tested
> >> on
> >> > my local box last night and it looks great.
> >> >
> >> > On 11 July 2017 at 15:18, Andy Gumbrecht 
> >> wrote:
> >> >
> >> > > I was going to put it up for a vote tonight.
> >> > >
> >> > > On 11 July 2017 at 14:40, Jonathan Gallimore <
> >> > jonathan.gallim...@gmail.com
> >> > > > wrote:
> >> > >
> >> > >> I'm happy to merge it if there are no objections.
> >> > >>
> >> > >> Jon
> >> > >>
> >> > >> On Tue, Jul 11, 2017 at 1:36 PM, Ivan Junckes Filho <
> >> > >> ivanjunc...@gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >> > Do we have any objections to this change? If no, can somebody
> merge
> >> > it?
> >> > >> >
> >> > >> > On Sat, Jul 8, 2017 at 5:19 PM, Romain Manni-Bucau <
> >> > >> rmannibu...@gmail.com>
> >> > >> > wrote:
> >> > >> >
> >> > >> > > +1
> >> > >> > >
> >> > >> > > Le 8 juil. 2017 19:53, "Ivan Junckes Filho" <
> >> ivanjunc...@gmail.com>
> >> > a
> >> > >> > > écrit :
> >> > >> > >
> >> > >> > > > Hello TomEE devs, I fixed the 404 issue.
> >> > >> > > >
> >> > >> > > > https://ivanjunckes.github.io/admin
> >> > >> > > > https://ivanjunckes.github.io/developers
> >> > >> > > > https://ivanjunckes.github.io/advanced
> >> > >> > > >
> >> > >> > > > How can we proceed from here? Can we get this change merged?
> >> > >> > > >
> >> > >> > > > On Thu, Jul 6, 2017 at 12:39 PM, Romain Manni-Bucau <
> >> > >> > > rmannibu...@gmail.com
> >> > >> > > > >
> >> > >> > > > wrote:
> >> > >> > > >
> >> > >> > > > > Not a big fan of "list sites" cause basically you dont find
> >> > >> anything
> >> > >> > > (or
> >> > >> > > > it
> >> > >> > > > > is faster to find it in code). Arquillian one is way better
> >> IMO.
> >> > >> > > > >
> >> > >> > > > > Le 6 juil. 2017 17:15, "Andy Gumbrecht" <
> >> > agumbre...@tomitribe.com>
> >> > >> a
> >> > >> > > > > écrit :
> >> > >> > > > >
> >> > >> > > > > > Just out of interest, what is everyone's favourite OSS
> >> > website?
> >> > >> I
> >> > >> > > > really
> >> > >> > > > > > like http://projects.spring.io/spring-boot/ and
> >> > >> > https://fabric8.io/
> >> > >> > > > > >
> >> > >> > > > > > On 6 July 2017 at 15:58, Andy Gumbrecht <
> >> > >> agumbre...@tomitribe.com>
> >> > >> > > > > wrote:
> >> > >> > > > > >
> >> > >> > > > > > > +1 to go to the user list and maybe get some feedback
> >> before
> >> > >> > > pushing,
> >>

Re: Site and "documentation" usage

But if everyone is happy then I'd be happy for it to be pushed. Tested on
my local box last night and it looks great.

On 11 July 2017 at 15:18, Andy Gumbrecht  wrote:

> I was going to put it up for a vote tonight.
>
> On 11 July 2017 at 14:40, Jonathan Gallimore  > wrote:
>
>> I'm happy to merge it if there are no objections.
>>
>> Jon
>>
>> On Tue, Jul 11, 2017 at 1:36 PM, Ivan Junckes Filho <
>> ivanjunc...@gmail.com>
>> wrote:
>>
>> > Do we have any objections to this change? If no, can somebody merge it?
>> >
>> > On Sat, Jul 8, 2017 at 5:19 PM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > +1
>> > >
>> > > Le 8 juil. 2017 19:53, "Ivan Junckes Filho"  a
>> > > écrit :
>> > >
>> > > > Hello TomEE devs, I fixed the 404 issue.
>> > > >
>> > > > https://ivanjunckes.github.io/admin
>> > > > https://ivanjunckes.github.io/developers
>> > > > https://ivanjunckes.github.io/advanced
>> > > >
>> > > > How can we proceed from here? Can we get this change merged?
>> > > >
>> > > > On Thu, Jul 6, 2017 at 12:39 PM, Romain Manni-Bucau <
>> > > rmannibu...@gmail.com
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > Not a big fan of "list sites" cause basically you dont find
>> anything
>> > > (or
>> > > > it
>> > > > > is faster to find it in code). Arquillian one is way better IMO.
>> > > > >
>> > > > > Le 6 juil. 2017 17:15, "Andy Gumbrecht" 
>> a
>> > > > > écrit :
>> > > > >
>> > > > > > Just out of interest, what is everyone's favourite OSS website?
>> I
>> > > > really
>> > > > > > like http://projects.spring.io/spring-boot/ and
>> > https://fabric8.io/
>> > > > > >
>> > > > > > On 6 July 2017 at 15:58, Andy Gumbrecht <
>> agumbre...@tomitribe.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > > +1 to go to the user list and maybe get some feedback before
>> > > pushing,
>> > > > > but
>> > > > > > > also..
>> > > > > > >
>> > > > > > > +1 to push it as is - Looks really good Ivan, so thank you
>> very
>> > > much
>> > > > > for
>> > > > > > > the hard work, and working together on the hosting for review
>> > > issues.
>> > > > > > Thank
>> > > > > > > you Romain for getting the code set up on GitHub. That makes
>> > > reviews
>> > > > > much
>> > > > > > > more transparent!
>> > > > > > >
>> > > > > > > +1 for continuing to improve the 404 issues over time.
>> > > > > > >
>> > > > > > > Andy.
>> > > > > > >
>> > > > > > > On 6 July 2017 at 14:46, Daniel Cunha 
>> > > wrote:
>> > > > > > >
>> > > > > > >> +1 to post it user@ list.
>> > > > > > >> The users are the real consumers of the website and their
>> > feedback
>> > > > is
>> > > > > > >> really important.
>> > > > > > >>
>> > > > > > >> On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
>> > > > > > >> jonathan.gallim...@gmail.com> wrote:
>> > > > > > >>
>> > > > > > >> > Hi Ivan!
>> > > > > > >> >
>> > > > > > >> > Thanks for the links. My personal view - I prefer the
>> > > > documentation
>> > > > > > >> link,
>> > > > > > >> > but I do like the split of the documentation page into
>> groups.
>> > > The
>> > > > > > >> > advantage here as I see it is all the documentation is
>> linked
>> > in
>> > > > one
>> > > > > > >> place
>> > > > > > >> > - no need to go into 'Developer' a

Re: Site and "documentation" usage

I was going to put it up for a vote tonight.

On 11 July 2017 at 14:40, Jonathan Gallimore 
wrote:

> I'm happy to merge it if there are no objections.
>
> Jon
>
> On Tue, Jul 11, 2017 at 1:36 PM, Ivan Junckes Filho  >
> wrote:
>
> > Do we have any objections to this change? If no, can somebody merge it?
> >
> > On Sat, Jul 8, 2017 at 5:19 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > Le 8 juil. 2017 19:53, "Ivan Junckes Filho"  a
> > > écrit :
> > >
> > > > Hello TomEE devs, I fixed the 404 issue.
> > > >
> > > > https://ivanjunckes.github.io/admin
> > > > https://ivanjunckes.github.io/developers
> > > > https://ivanjunckes.github.io/advanced
> > > >
> > > > How can we proceed from here? Can we get this change merged?
> > > >
> > > > On Thu, Jul 6, 2017 at 12:39 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Not a big fan of "list sites" cause basically you dont find
> anything
> > > (or
> > > > it
> > > > > is faster to find it in code). Arquillian one is way better IMO.
> > > > >
> > > > > Le 6 juil. 2017 17:15, "Andy Gumbrecht" 
> a
> > > > > écrit :
> > > > >
> > > > > > Just out of interest, what is everyone's favourite OSS website? I
> > > > really
> > > > > > like http://projects.spring.io/spring-boot/ and
> > https://fabric8.io/
> > > > > >
> > > > > > On 6 July 2017 at 15:58, Andy Gumbrecht <
> agumbre...@tomitribe.com>
> > > > > wrote:
> > > > > >
> > > > > > > +1 to go to the user list and maybe get some feedback before
> > > pushing,
> > > > > but
> > > > > > > also..
> > > > > > >
> > > > > > > +1 to push it as is - Looks really good Ivan, so thank you very
> > > much
> > > > > for
> > > > > > > the hard work, and working together on the hosting for review
> > > issues.
> > > > > > Thank
> > > > > > > you Romain for getting the code set up on GitHub. That makes
> > > reviews
> > > > > much
> > > > > > > more transparent!
> > > > > > >
> > > > > > > +1 for continuing to improve the 404 issues over time.
> > > > > > >
> > > > > > > Andy.
> > > > > > >
> > > > > > > On 6 July 2017 at 14:46, Daniel Cunha 
> > > wrote:
> > > > > > >
> > > > > > >> +1 to post it user@ list.
> > > > > > >> The users are the real consumers of the website and their
> > feedback
> > > > is
> > > > > > >> really important.
> > > > > > >>
> > > > > > >> On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
> > > > > > >> jonathan.gallim...@gmail.com> wrote:
> > > > > > >>
> > > > > > >> > Hi Ivan!
> > > > > > >> >
> > > > > > >> > Thanks for the links. My personal view - I prefer the
> > > > documentation
> > > > > > >> link,
> > > > > > >> > but I do like the split of the documentation page into
> groups.
> > > The
> > > > > > >> > advantage here as I see it is all the documentation is
> linked
> > in
> > > > one
> > > > > > >> place
> > > > > > >> > - no need to go into 'Developer' and realize its not there,
> > and
> > > > then
> > > > > > >> check
> > > > > > >> > 'Admin'.
> > > > > > >> >
> > > > > > >> > I also wonder if we should also post this to the users@
> list
> > to
> > > > see
> > > > > > if
> > > > > > >> > there are any preferences there?
> > > > > > >> >
> > > > > > >> > I understand Romain's points about the 404 (see the PR
> > co

Re: Building a Static Discovery Cluster

That's a really cool idea Ivan - How about proposing a 'Getting Started'
webinar and inviting the user and dev list?

Andy.

On 11 July 2017 at 13:19, Ivan Junckes Filho  wrote:

> Hi Elder, If you need a google hangout to get started on the website let me
> know.
>
> I have been touching it lately and will be happy to help.
>
>
>
> On Tue, Jul 11, 2017 at 3:30 AM, Romain Manni-Bucau  >
> wrote:
>
> > Hi Elder,
> >
> > site was not yet updated (any volonteer welcomed ;)) but you can do it on
> > github through a PR:
> >
> > 1. fork https://github.com/apache/tomee-site-generator
> > 2. add a page in
> > https://github.com/apache/tomee-site-generator/tree/
> > master/src/main/jbake/content
> > 3. add a link to this page
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-11 1:07 GMT+02:00 Daniel Cunha :
> >
> > > Hi Elder,
> > >
> > > Look the section Contribute the this site.
> > > http://tomee.apache.org/community/index.html
> > >
> > > Thank you.
> > >
> > > Daniel Cunha
> > > https://twitter.com/dvlc_
> > >
> > > On Jul 10, 2017 6:59 PM, "Elder Moraes" 
> wrote:
> > >
> > > Hello David, Romain and others,
> > >
> > > I've just figured it out! Now I have a real static cluster, with
> session
> > > being shared between nodes and avoiding unexpected members to joining
> in.
> > >
> > > There are 3 key points:
> > >
> > >1. channelStartOptions="3" (to avoid using multicast);
> > >2. Receiver and Member using the same port;
> > >3. Turn one of the members into a LocalMember (instead of Member).
> It
> > >will work as the Replication Listener and Receiver Server.
> > >
> > > By doing this you'll be able to see, after all the nodes are up and
> > > running, the Group Channel showing confirmation of each node added. And
> > > once you try to add another with unexpected IP, it is solemnly
> ignored...
> > > ;-)
> > >
> > > How can I turn it into some documentation for Tomee? I have all the
> > > details...
> > >
> > >
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > >
> > > 2017-07-10 14:40 GMT-03:00 Elder Moraes :
> > >
> > > > Hey David!
> > > >
> > > > I've sent to the Tomcat list, but still didn't get any reply.
> > > >
> > > > Anyway I'm still trying to figure it out by myself and will be a
> > pleasure
> > > > to contribute with some docs once I do it.
> > > >
> > > >
> > > > Tks!
> > > >
> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > Blog: http://eldermoraes.com
> > > >
> > > >
> > > >
> > > >
> > > > 2017-07-09 2:50 GMT-03:00 David Blevins :
> > > >
> > > >>  Hi Elder! just checking to see if you got the help you were looking
> > > for.
> > > >>
> > > >>  When you get it figured out any new docs would be amazing.
> > > >>
> > > >> On Fri, Jul 7, 2017 at 9:57 AM Elder Moraes  >
> > > >> wrote:
> > > >>
> > > >> > Ok, will try them.
> > > >> >
> > > >> > Thanks!
> > > >> >
> > > >> >
> > > >> > Twitter: @elderjava <https://twitter.com/elderjava>
> > > >> > Blog: http://eldermoraes.com
> > > >> >
> > > >> >
> > > >> >
> > > >> > 2017-07-06 18:02 GMT-03:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >> >
> > > >> > > outch, no more, didnt resetup a cluster since 2 years. But if
> you
> > > >> push a
> > > >> > > tomee-maven-plugin sample it would be quick to help.
> > > >> &g

Re: [Discuss] Review-than-commit 3 month trial

2017-07-10 Thread Andy Gumbrecht

+1 for option 1 - I feel rtc should be little more than the 'PR with peer
review' option, which is the goal (don't merge your own commits without
several eyes on, etc.).

-1 for any defined waiting period for the +1s. I'd not want to see rtc
stopping anyone from getting things done quickly, just not autonomously.

If there is a veto 'after' a commit (but within 72h of the commit) then the
revert must happen as defined by the rules. This would then be reworked so
the the veto issue is addressed, or (if no rtc agreement can be achieved)
put to a majority vote.

If a veto is not performed within 24h, then the commit is final and only a
counter PR should attempt to address the veto issue.

Andy.

On 10 July 2017 at 04:12, David Blevins  wrote:

> We’d encourage everyone to vote, but it would be only committers who have
> binding votes.
>
> On your offline feedback about the “Immediate 3 +1s and no -1s” option, I
> had added that in hopes that would “sell” the idea and make RTC more
> palatable.  It would addresses the “it will slow us down” issue.
>
> What could we do to refine the idea?  Throwing out some options, but let
> me know if you see others:
>
> Option 1: reduce the votes required
>
>  - Immediate 2 +1 votes from committers on the project with no
>outstanding -1 votes and no ongoing discussion.  No 72 hour vote
>period is required to intentionally to encourage obtaining speed
>throught active list participation.
>
> Option 2: add a slight delay
>
>  - 3 +1 votes from committers on the project with no outstanding -1
>votes and no ongoing discussion.  24 hour vote period is required
>to ensure space for minimum participation.
>
> Option 3: both option 1 and 2
>
>  - 2 +1 votes from committers on the project with no outstanding -1
>votes and no ongoing discussion.  24 hour vote period is required
>to ensure space for minimum participation.
>
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jul 9, 2017, at 1:40 AM, Mark Struberg 
> wrote:
> >
> > Who would have a vote? PMCs only? Active Committers only? Everyone?
> >
> >
> > LieGrue,
> > strub
> >
> >> Am 09.07.2017 um 03:11 schrieb David Blevins :
> >>
> >> Ok, how would this look as a proposal?  Note this is not a vote, we are
> still in discussion.  Do suggest changes.
> >>
> >> Whatever we come up with, I’ll swing it by the Board before we vote so
> we don’t feel we need to argue the rules.
> >>
> >> Let’s focus primarily on what we want to do.
> >>
> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >>
> >> # Discussion Before Action
> >>
> >> - New features
> >> - Significant changes
> >> - Backwards incompatable changes
> >>
> >> To avoid excessive vetos in the RTC process, discussion prior to
> >> coding is encouraged for the above situations.
> >>
> >> # RTC with Lazy Consensus
> >>
> >> Changes should occur in a fork on Github.  A Github Pull Requests (PR)
> >> should be submitted to the dev list for review.  The email to the dev
> >> list should stand on its own and use a descriptive subject and contain
> >> a complete description in the body.  The body must contain a link to
> >> the PR.  The following is an example of an acceptable dev list PR
> >> submission:
> >>
> >> Subject: [PR] AutoConfig::firstMatching sorting issue with java 8
> >>
> >> Fix the sorting issue, by removing the sorting operation. We are not
> >> interested in the order of the elements, but only in the smallest
> >> element.
> >>
> >> Two improvements:
> >>
> >> 1. Do not unnecessary allocate a new array list
> >>
> >> 2. Collections.min() is O(n) vs O(nLog(n) for sort() (well without
> >> counting indexOf() in the comparator)
> >>
> >> https://github.com/apache/tomee/pull/84
> >>
> >> The following email subjects should be discouraged as they drive
> >> discussion off of the list from the very start.
> >>
> >> Subject: [PR] https://github.com/apache/tomee/pull/84
> >> Subject: [PR] #84
> >> Subject: [PR] https://issues.apache.org/jira/browse/TOMEE-2085
> >> Subject: [PR] TOMEE-2085
> >> Subject: [PR] Fixed TOMEE-2085
> >>
> >> PR numbers and JIRA ids are allowed in the subject, but cannot be the
> >> subject exclussively. PR number

Re: [Discuss] Review-than-commit 3 month trial

2017-07-08 Thread Andy Gumbrecht

At the end of the day it is up to everyone on a project to decide on what
form RTC would be managed and applied if we chose to adopt it. It's open to
interpretation through the set of guidelines.

Interpreting a rigid and unworkable set of rules based on those guidelines
would make it impossible to follow.

Applying the guidelines from the perspective of a Pull Request peer review
does not make it impossible.

Andy.

On 8 July 2017 at 09:59, Andy Gumbrecht  wrote:

> Vote <https://www.apache.org/foundation/glossary.html#Vote>1. The process
> of making a formal decision. ('The vote for foo will close in three days.')
> 2. The expression of a positive or negative opinion, or a veto, as part
> of a formal decision. ('My vote is -1 because foo smells bad.')
> The brackets denote 'implied', not a rule.
>
> On 8 July 2017 at 09:37, agumbre...@tomitribe.com <
> agumbre...@tomitribe.com> wrote:
>
>> You are apply the majority vote to a consensus vote.
>>
>> agumbre...@tomitribe.com
>> http://www.tomitribe.com
>>
>> Sent from my mobile device.
>>
>> - Reply message -
>> From: "Mark Struberg" 
>> To: 
>> Subject: [Discuss] Review-than-commit 3 month trial
>> Date: Sat, Jul 8, 2017 09:23
>>
>> Andy, please read the documentation!
>>
>> The definition of 'RTC' 
>> https://www.apache.org/foundation/glossary.html#ReviewThenCommit
>>
>> points to 'Consensus 
>> Approval'https://www.apache.org/foundation/glossary.html#ConsensusApproval
>>
>> Which in turn points to 
>> 'Vote'https://www.apache.org/foundation/glossary.html#Vote
>>
>> which of course has a time parameter.
>> It defaults to 3 days, but of course can be defined different. Otoh a period 
>> of below 1 day contradicts the ASF around-the-globe policy.
>>
>> Btw, RTC also implies that everyone who voted also did fully test the 
>> patch!https://www.apache.org/foundation/voting.html
>>
>> That means that everyone who votes will run the full 30 minutes build for 
>> each and every commit candidate.
>> Now tell me when you did run ALL tests locally the last time?
>>
>> Sadly I was not able to run all the tests locally in one go. Not on my 
>> MacBook, nor on my Linux Workstation.
>> I already reported this quite a few times and we finally need to improve 
>> this.
>> Once we make our test suite reliably working again and bring committers to 
>> run it before they commit, then we might also not need such a review anymore.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 08.07.2017 um 00:51 schrieb Andy Gumbrecht :
>> >
>> > That's *not* how a consensus vote works. An RTC commit does not need a
>> > majority at all - That would be a 'Majority Approval', and of course *that*
>> > is not any use at all for RTC.
>> >
>> > No one here is suggesting it that way, and it would be stupid to make
>> > anyone wait 72h for a simple review. It is not stupid to say create a PR
>> > and have someone else review it - That's the workflow on just about every
>> > community git project out there - Don't merge your own PR is a really
>> > common process.
>> >
>> > If David comes on 9 hrs later and doesn't like it then he'd need to submit
>> > a counter PR, and that would also need 3+1. That's the whole point.
>> >
>> > It's about teamwork and eyes on by more than just one person, not about
>> > making it impossible to work. If you do a PR and JL *and* Romain ack it
>> > then where is the issue with that?
>> >
>> > You're seeing it, or making it sound, way more complicated than it is.
>> > Right now there is *no* consensus. Right now anyone can commit at any time
>> > without eyes on by anyone else. Right now if David doesn't like it 9 hours
>> > later, then he can just *trash* it as he sees fit.
>> >
>> > So, a 3+1 commit with no time frame makes a lot of sense imo. It's little
>> > more than a PR with peer review.
>> >
>> > Andy.
>> >
>> > On 8 July 2017 at 00:17, Mark Struberg  wrote:
>> >
>> >> Just for sake of clarifying the procedural stuff. A consensus vote
>> >> requires that the majority of PMC members did vote.
>> >> Consider I commit something and ping lt's say JL and Romain via IRC to ack
>> >> it. They send their +1 in the frame 1 minute after my PR. Then I go on and
>> >> push it. Now 9 hours l

Re: [Discuss] Review-than-commit 3 month trial

2017-07-08 Thread Andy Gumbrecht

Vote <https://www.apache.org/foundation/glossary.html#Vote>1. The process
of making a formal decision. ('The vote for foo will close in three days.')
2. The expression of a positive or negative opinion, or a veto, as part of
a formal decision. ('My vote is -1 because foo smells bad.')
The brackets denote 'implied', not a rule.

On 8 July 2017 at 09:37, agumbre...@tomitribe.com 
wrote:

> You are apply the majority vote to a consensus vote.
>
> agumbre...@tomitribe.com
> http://www.tomitribe.com
>
> Sent from my mobile device.
>
> - Reply message -
> From: "Mark Struberg" 
> To: 
> Subject: [Discuss] Review-than-commit 3 month trial
> Date: Sat, Jul 8, 2017 09:23
>
> Andy, please read the documentation!
>
> The definition of 'RTC' 
> https://www.apache.org/foundation/glossary.html#ReviewThenCommit
>
> points to 'Consensus 
> Approval'https://www.apache.org/foundation/glossary.html#ConsensusApproval
>
> Which in turn points to 
> 'Vote'https://www.apache.org/foundation/glossary.html#Vote
>
> which of course has a time parameter.
> It defaults to 3 days, but of course can be defined different. Otoh a period 
> of below 1 day contradicts the ASF around-the-globe policy.
>
> Btw, RTC also implies that everyone who voted also did fully test the 
> patch!https://www.apache.org/foundation/voting.html
>
> That means that everyone who votes will run the full 30 minutes build for 
> each and every commit candidate.
> Now tell me when you did run ALL tests locally the last time?
>
> Sadly I was not able to run all the tests locally in one go. Not on my 
> MacBook, nor on my Linux Workstation.
> I already reported this quite a few times and we finally need to improve this.
> Once we make our test suite reliably working again and bring committers to 
> run it before they commit, then we might also not need such a review anymore.
>
> LieGrue,
> strub
>
>
> > Am 08.07.2017 um 00:51 schrieb Andy Gumbrecht :
> >
> > That's *not* how a consensus vote works. An RTC commit does not need a
> > majority at all - That would be a 'Majority Approval', and of course *that*
> > is not any use at all for RTC.
> >
> > No one here is suggesting it that way, and it would be stupid to make
> > anyone wait 72h for a simple review. It is not stupid to say create a PR
> > and have someone else review it - That's the workflow on just about every
> > community git project out there - Don't merge your own PR is a really
> > common process.
> >
> > If David comes on 9 hrs later and doesn't like it then he'd need to submit
> > a counter PR, and that would also need 3+1. That's the whole point.
> >
> > It's about teamwork and eyes on by more than just one person, not about
> > making it impossible to work. If you do a PR and JL *and* Romain ack it
> > then where is the issue with that?
> >
> > You're seeing it, or making it sound, way more complicated than it is.
> > Right now there is *no* consensus. Right now anyone can commit at any time
> > without eyes on by anyone else. Right now if David doesn't like it 9 hours
> > later, then he can just *trash* it as he sees fit.
> >
> > So, a 3+1 commit with no time frame makes a lot of sense imo. It's little
> > more than a PR with peer review.
> >
> > Andy.
> >
> > On 8 July 2017 at 00:17, Mark Struberg  wrote:
> >
> >> Just for sake of clarifying the procedural stuff. A consensus vote
> >> requires that the majority of PMC members did vote.
> >> Consider I commit something and ping lt's say JL and Romain via IRC to ack
> >> it. They send their +1 in the frame 1 minute after my PR. Then I go on and
> >> push it. Now 9 hours later David awakes over in US and he doesn't like it.
> >> He might vote -1, but it's already committed. Not what's intended, isn't?
> >>
> >> A VOTE without any time frame or a quorum does make little sense imo.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht  >>> :
> >>>
> >>> This is not a vote for a release, if you get 3+1s within a minute then
> >> you
> >>> don't have to wait 72h. It is 'Consensus Approval'.
> >>>
> >>> Consensus Approval
> >>> 'Consensus approval' refers to a vote (sense 1) which has *completed
> >> *with
> >>> at least three binding +1 votes and no vetos
> >>>
> >>

Re: [Discuss] Review-than-commit 3 month trial

That's *not* how a consensus vote works. An RTC commit does not need a
majority at all - That would be a 'Majority Approval', and of course *that*
is not any use at all for RTC.

No one here is suggesting it that way, and it would be stupid to make
anyone wait 72h for a simple review. It is not stupid to say create a PR
and have someone else review it - That's the workflow on just about every
community git project out there - Don't merge your own PR is a really
common process.

If David comes on 9 hrs later and doesn't like it then he'd need to submit
a counter PR, and that would also need 3+1. That's the whole point.

It's about teamwork and eyes on by more than just one person, not about
making it impossible to work. If you do a PR and JL *and* Romain ack it
then where is the issue with that?

You're seeing it, or making it sound, way more complicated than it is.
Right now there is *no* consensus. Right now anyone can commit at any time
without eyes on by anyone else. Right now if David doesn't like it 9 hours
later, then he can just *trash* it as he sees fit.

So, a 3+1 commit with no time frame makes a lot of sense imo. It's little
more than a PR with peer review.

Andy.

On 8 July 2017 at 00:17, Mark Struberg  wrote:

> Just for sake of clarifying the procedural stuff. A consensus vote
> requires that the majority of PMC members did vote.
> Consider I commit something and ping lt's say JL and Romain via IRC to ack
> it. They send their +1 in the frame 1 minute after my PR. Then I go on and
> push it. Now 9 hours later David awakes over in US and he doesn't like it.
> He might vote -1, but it's already committed. Not what's intended, isn't?
>
> A VOTE without any time frame or a quorum does make little sense imo.
>
> LieGrue,
> strub
>
> > Am 07.07.2017 um 16:25 schrieb Andy Gumbrecht  >:
> >
> > This is not a vote for a release, if you get 3+1s within a minute then
> you
> > don't have to wait 72h. It is 'Consensus Approval'.
> >
> > Consensus Approval
> > 'Consensus approval' refers to a vote (sense 1) which has *completed
> *with
> > at least three binding +1 votes and no vetos
> >
> > On 7 July 2017 at 16:19, Mark Struberg 
> wrote:
> >
> >> You know how voting works at the ASF? ;)
> >>
> >> Either have a VOTE - with all it's implciations - or not.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <
> agumbre...@tomitribe.com
> >>> :
> >>>
> >>> There's no 72h waiting period? Just 3+1 to commit. I'd even be for a
> 2+1.
> >>>
> >>> As soon as whatever is decided is counted then the commit occurs. That
> >>> could be within a few minutes.
> >>>
> >>> Andy.
> >>>
> >>> On 7 July 2017 at 14:59, Mark Struberg 
> >> wrote:
> >>>
> >>>> +1 well said, Jeff!
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 06.07.2017 um 18:37 schrieb Jeff Genender :
> >>>>>
> >>>>> Lurking on this, I have to underscore what Mark said.
> >>>>>
> >>>>> Andy, you are pretty correct on nearly every point that you made.
> But
> >>>> the things stated are more of refining your current process rather
> than
> >>>> taking RTC for current committers.  You already had RTC with PRs from
> >>>> outsiders.  If that slipped in, it just means that a trusted committer
> >>>> didn’t do their job.  It happens.   Breaking a trunk build for a day
> (or
> >>>> even a week) is ok.  Thats why its trunk.  I cannot tell you how many
> >> times
> >>>> I have downloaded a project’s trunk and things weren’t quite right.
> >>>>>
> >>>>> Relative to what prompted this RTC discussion again, I think things
> got
> >>>> emotional and people slipped up afterwards.  The beauty of all this is
> >> all
> >>>> parties shook hands and made up.  Problem was more-or-less solved and
> >> the
> >>>> project was back on track.
> >>>>>
> >>>>> IMHO, taking on RTC is punitive.  It means that you need to reset the
> >>>> way you do things because you cannot do it yourselves.  Do you think
> you
> >>>> are at that point?  It didn’t look that way to me… but its certainly
> >>>> possible based on what i

Re: [Discuss] Review-than-commit 3 month trial

@Jonathan +1

On 7 July 2017 at 16:48, Jonathan Gallimore 
wrote:

> Some discussion as to what the process might be is probably pretty
> fundamental to help decide whether its beneficial to project or not. If the
> proposal was to have 20 +1s and a three week minimum voting period, you
> might have a different opinion to a process that requires 3 +1s with no
> minimum voting period (even if your thoughts were 'heck no' and 'no'
> respectively).
>
> Jon
>
> On Fri, Jul 7, 2017 at 3:43 PM, Romain Manni-Bucau 
> wrote:
>
> > @Andy: discussion is not if the process is easy or not but if it would be
> > beneficial to the project.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-07 16:40 GMT+02:00 Andy Gumbrecht :
> >
> > > If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
> > > they must submit a counter PR, that must also pass the RTC.
> > >
> > > It's pretty straight forward.
> > >
> > > On 7 July 2017 at 16:36, Andy Gumbrecht 
> > wrote:
> > >
> > > > ;-)
> > > >
> > > > On 7 July 2017 at 16:34, Andy Gumbrecht 
> > > wrote:
> > > >
> > > >> RTC is Consensus Approval and does not need 72h, just 3+1 in any
> > amount
> > > >> of time.
> > > >>
> > > >> On 7 July 2017 at 16:33, Andy Gumbrecht 
> > > wrote:
> > > >>
> > > >>> Those quotes are from Apache.
> > > >>>
> > > >>> On 7 July 2017 at 16:30, Romain Manni-Bucau  >
> > > >>> wrote:
> > > >>>
> > > >>>> What Mark meant is if we go through a "vote" then we need to
> comply
> > to
> > > >>>> ASF
> > > >>>> rules. Otherwise anything is up to the project and not a "vote".
> > > >>>> #semantic
> > > >>>> ;)
> > > >>>>
> > > >>>>
> > > >>>> Romain Manni-Bucau
> > > >>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > >>>> <http://rmannibucau.wordpress.com> | Github <
> > > >>>> https://github.com/rmannibucau> |
> > > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> Factory
> > > >>>> <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >>>>
> > > >>>> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht <
> agumbre...@tomitribe.com
> > >:
> > > >>>>
> > > >>>> > A release is:
> > > >>>> >
> > > >>>> > Majority Approval
> > > >>>> > Refers to a vote (sense 1) which has completed with at least
> three
> > > >>>> binding
> > > >>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> > > >>>> >
> > > >>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <
> agumbre...@tomitribe.com
> > >
> > > >>>> wrote:
> > > >>>> >
> > > >>>> > > This is not a vote for a release, if you get 3+1s within a
> > minute
> > > >>>> then
> > > >>>> > you
> > > >>>> > > don't have to wait 72h. It is 'Consensus Approval'.
> > > >>>> > >
> > > >>>> > > Consensus Approval
> > > >>>> > > 'Consensus approval' refers to a vote (sense 1) which has
> > > *completed
> > > >>>> > *with
> > > >>>> > > at least three binding +1 votes and no vetos
> > > >>>> > >
> > > >>>> > > On 7 July 2017 at 16:19, Mark Struberg
> >  > > >
> > > >>>> > wrote:
> > > >>>> > >
> > > >>>> > >

Re: [Discuss] Review-than-commit 3 month trial

If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
they must submit a counter PR, that must also pass the RTC.

It's pretty straight forward.

On 7 July 2017 at 16:36, Andy Gumbrecht  wrote:

> ;-)
>
> On 7 July 2017 at 16:34, Andy Gumbrecht  wrote:
>
>> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount
>> of time.
>>
>> On 7 July 2017 at 16:33, Andy Gumbrecht  wrote:
>>
>>> Those quotes are from Apache.
>>>
>>> On 7 July 2017 at 16:30, Romain Manni-Bucau 
>>> wrote:
>>>
>>>> What Mark meant is if we go through a "vote" then we need to comply to
>>>> ASF
>>>> rules. Otherwise anything is up to the project and not a "vote".
>>>> #semantic
>>>> ;)
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github <
>>>> https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>>
>>>> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht :
>>>>
>>>> > A release is:
>>>> >
>>>> > Majority Approval
>>>> > Refers to a vote (sense 1) which has completed with at least three
>>>> binding
>>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>>>> >
>>>> > On 7 July 2017 at 16:25, Andy Gumbrecht 
>>>> wrote:
>>>> >
>>>> > > This is not a vote for a release, if you get 3+1s within a minute
>>>> then
>>>> > you
>>>> > > don't have to wait 72h. It is 'Consensus Approval'.
>>>> > >
>>>> > > Consensus Approval
>>>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
>>>> > *with
>>>> > > at least three binding +1 votes and no vetos
>>>> > >
>>>> > > On 7 July 2017 at 16:19, Mark Struberg 
>>>> > wrote:
>>>> > >
>>>> > >> You know how voting works at the ASF? ;)
>>>> > >>
>>>> > >> Either have a VOTE - with all it's implciations - or not.
>>>> > >>
>>>> > >>
>>>> > >> LieGrue,
>>>> > >> strub
>>>> > >>
>>>> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <
>>>> > agumbre...@tomitribe.com
>>>> > >> >:
>>>> > >> >
>>>> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be
>>>> for a
>>>> > >> 2+1.
>>>> > >> >
>>>> > >> > As soon as whatever is decided is counted then the commit
>>>> occurs. That
>>>> > >> > could be within a few minutes.
>>>> > >> >
>>>> > >> > Andy.
>>>> > >> >
>>>> > >> > On 7 July 2017 at 14:59, Mark Struberg >>> >
>>>> > >> wrote:
>>>> > >> >
>>>> > >> >> +1 well said, Jeff!
>>>> > >> >>
>>>> > >> >> LieGrue,
>>>> > >> >> strub
>>>> > >> >>
>>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
>>>> jgenen...@apache.org
>>>> > >:
>>>> > >> >>>
>>>> > >> >>> Lurking on this, I have to underscore what Mark said.
>>>> > >> >>>
>>>> > >> >>> Andy, you are pretty correct on nearly every point that you
>>>> made.
>>>> > But
>>>> > >> >> the things stated are more of refining your current process
>>>> rather
>>>> > than
>>>> > >> >> taking RTC for current committers.  You already had RTC with
>>>> PRs from
>>>> > >> >> outsiders.  If that slipped in, it just means that a trusted
>>>> > committer
>>>> > >

Re: [Discuss] Review-than-commit 3 month trial

;-)

On 7 July 2017 at 16:34, Andy Gumbrecht  wrote:

> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount
> of time.
>
> On 7 July 2017 at 16:33, Andy Gumbrecht  wrote:
>
>> Those quotes are from Apache.
>>
>> On 7 July 2017 at 16:30, Romain Manni-Bucau 
>> wrote:
>>
>>> What Mark meant is if we go through a "vote" then we need to comply to
>>> ASF
>>> rules. Otherwise anything is up to the project and not a "vote".
>>> #semantic
>>> ;)
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>
>>> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht :
>>>
>>> > A release is:
>>> >
>>> > Majority Approval
>>> > Refers to a vote (sense 1) which has completed with at least three
>>> binding
>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>>> >
>>> > On 7 July 2017 at 16:25, Andy Gumbrecht 
>>> wrote:
>>> >
>>> > > This is not a vote for a release, if you get 3+1s within a minute
>>> then
>>> > you
>>> > > don't have to wait 72h. It is 'Consensus Approval'.
>>> > >
>>> > > Consensus Approval
>>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
>>> > *with
>>> > > at least three binding +1 votes and no vetos
>>> > >
>>> > > On 7 July 2017 at 16:19, Mark Struberg 
>>> > wrote:
>>> > >
>>> > >> You know how voting works at the ASF? ;)
>>> > >>
>>> > >> Either have a VOTE - with all it's implciations - or not.
>>> > >>
>>> > >>
>>> > >> LieGrue,
>>> > >> strub
>>> > >>
>>> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <
>>> > agumbre...@tomitribe.com
>>> > >> >:
>>> > >> >
>>> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be
>>> for a
>>> > >> 2+1.
>>> > >> >
>>> > >> > As soon as whatever is decided is counted then the commit occurs.
>>> That
>>> > >> > could be within a few minutes.
>>> > >> >
>>> > >> > Andy.
>>> > >> >
>>> > >> > On 7 July 2017 at 14:59, Mark Struberg >> >
>>> > >> wrote:
>>> > >> >
>>> > >> >> +1 well said, Jeff!
>>> > >> >>
>>> > >> >> LieGrue,
>>> > >> >> strub
>>> > >> >>
>>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
>>> jgenen...@apache.org
>>> > >:
>>> > >> >>>
>>> > >> >>> Lurking on this, I have to underscore what Mark said.
>>> > >> >>>
>>> > >> >>> Andy, you are pretty correct on nearly every point that you
>>> made.
>>> > But
>>> > >> >> the things stated are more of refining your current process
>>> rather
>>> > than
>>> > >> >> taking RTC for current committers.  You already had RTC with PRs
>>> from
>>> > >> >> outsiders.  If that slipped in, it just means that a trusted
>>> > committer
>>> > >> >> didn’t do their job.  It happens.   Breaking a trunk build for a
>>> day
>>> > >> (or
>>> > >> >> even a week) is ok.  Thats why its trunk.  I cannot tell you how
>>> many
>>> > >> times
>>> > >> >> I have downloaded a project’s trunk and things weren’t quite
>>> right.
>>> > >> >>>
>>> > >> >>> Relative to what prompted this RTC discussion again, I think
>>> things
>>> > >> got
>>> > >> >> emotional and

Re: [Discuss] Review-than-commit 3 month trial

RTC is Consensus Approval and does not need 72h, just 3+1 in any amount of
time.

On 7 July 2017 at 16:33, Andy Gumbrecht  wrote:

> Those quotes are from Apache.
>
> On 7 July 2017 at 16:30, Romain Manni-Bucau  wrote:
>
>> What Mark meant is if we go through a "vote" then we need to comply to ASF
>> rules. Otherwise anything is up to the project and not a "vote". #semantic
>> ;)
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht :
>>
>> > A release is:
>> >
>> > Majority Approval
>> > Refers to a vote (sense 1) which has completed with at least three
>> binding
>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
>> >
>> > On 7 July 2017 at 16:25, Andy Gumbrecht 
>> wrote:
>> >
>> > > This is not a vote for a release, if you get 3+1s within a minute then
>> > you
>> > > don't have to wait 72h. It is 'Consensus Approval'.
>> > >
>> > > Consensus Approval
>> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
>> > *with
>> > > at least three binding +1 votes and no vetos
>> > >
>> > > On 7 July 2017 at 16:19, Mark Struberg 
>> > wrote:
>> > >
>> > >> You know how voting works at the ASF? ;)
>> > >>
>> > >> Either have a VOTE - with all it's implciations - or not.
>> > >>
>> > >>
>> > >> LieGrue,
>> > >> strub
>> > >>
>> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <
>> > agumbre...@tomitribe.com
>> > >> >:
>> > >> >
>> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be for
>> a
>> > >> 2+1.
>> > >> >
>> > >> > As soon as whatever is decided is counted then the commit occurs.
>> That
>> > >> > could be within a few minutes.
>> > >> >
>> > >> > Andy.
>> > >> >
>> > >> > On 7 July 2017 at 14:59, Mark Struberg 
>> > >> wrote:
>> > >> >
>> > >> >> +1 well said, Jeff!
>> > >> >>
>> > >> >> LieGrue,
>> > >> >> strub
>> > >> >>
>> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
>> jgenen...@apache.org
>> > >:
>> > >> >>>
>> > >> >>> Lurking on this, I have to underscore what Mark said.
>> > >> >>>
>> > >> >>> Andy, you are pretty correct on nearly every point that you made.
>> > But
>> > >> >> the things stated are more of refining your current process rather
>> > than
>> > >> >> taking RTC for current committers.  You already had RTC with PRs
>> from
>> > >> >> outsiders.  If that slipped in, it just means that a trusted
>> > committer
>> > >> >> didn’t do their job.  It happens.   Breaking a trunk build for a
>> day
>> > >> (or
>> > >> >> even a week) is ok.  Thats why its trunk.  I cannot tell you how
>> many
>> > >> times
>> > >> >> I have downloaded a project’s trunk and things weren’t quite
>> right.
>> > >> >>>
>> > >> >>> Relative to what prompted this RTC discussion again, I think
>> things
>> > >> got
>> > >> >> emotional and people slipped up afterwards.  The beauty of all
>> this
>> > is
>> > >> all
>> > >> >> parties shook hands and made up.  Problem was more-or-less solved
>> and
>> > >> the
>> > >> >> project was back on track.
>> > >> >>>
>> > >> >>> IMHO, taking on RTC is punitive.  It means that you need to reset
>> > the
>> > >> >> way you do things because you cannot do it yourselves.  Do you

Re: [Discuss] Review-than-commit 3 month trial

Those quotes are from Apache.

On 7 July 2017 at 16:30, Romain Manni-Bucau  wrote:

> What Mark meant is if we go through a "vote" then we need to comply to ASF
> rules. Otherwise anything is up to the project and not a "vote". #semantic
> ;)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht :
>
> > A release is:
> >
> > Majority Approval
> > Refers to a vote (sense 1) which has completed with at least three
> binding
> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> >
> > On 7 July 2017 at 16:25, Andy Gumbrecht 
> wrote:
> >
> > > This is not a vote for a release, if you get 3+1s within a minute then
> > you
> > > don't have to wait 72h. It is 'Consensus Approval'.
> > >
> > > Consensus Approval
> > > 'Consensus approval' refers to a vote (sense 1) which has *completed
> > *with
> > > at least three binding +1 votes and no vetos
> > >
> > > On 7 July 2017 at 16:19, Mark Struberg 
> > wrote:
> > >
> > >> You know how voting works at the ASF? ;)
> > >>
> > >> Either have a VOTE - with all it's implciations - or not.
> > >>
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <
> > agumbre...@tomitribe.com
> > >> >:
> > >> >
> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be for a
> > >> 2+1.
> > >> >
> > >> > As soon as whatever is decided is counted then the commit occurs.
> That
> > >> > could be within a few minutes.
> > >> >
> > >> > Andy.
> > >> >
> > >> > On 7 July 2017 at 14:59, Mark Struberg 
> > >> wrote:
> > >> >
> > >> >> +1 well said, Jeff!
> > >> >>
> > >> >> LieGrue,
> > >> >> strub
> > >> >>
> > >> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <
> jgenen...@apache.org
> > >:
> > >> >>>
> > >> >>> Lurking on this, I have to underscore what Mark said.
> > >> >>>
> > >> >>> Andy, you are pretty correct on nearly every point that you made.
> > But
> > >> >> the things stated are more of refining your current process rather
> > than
> > >> >> taking RTC for current committers.  You already had RTC with PRs
> from
> > >> >> outsiders.  If that slipped in, it just means that a trusted
> > committer
> > >> >> didn’t do their job.  It happens.   Breaking a trunk build for a
> day
> > >> (or
> > >> >> even a week) is ok.  Thats why its trunk.  I cannot tell you how
> many
> > >> times
> > >> >> I have downloaded a project’s trunk and things weren’t quite right.
> > >> >>>
> > >> >>> Relative to what prompted this RTC discussion again, I think
> things
> > >> got
> > >> >> emotional and people slipped up afterwards.  The beauty of all this
> > is
> > >> all
> > >> >> parties shook hands and made up.  Problem was more-or-less solved
> and
> > >> the
> > >> >> project was back on track.
> > >> >>>
> > >> >>> IMHO, taking on RTC is punitive.  It means that you need to reset
> > the
> > >> >> way you do things because you cannot do it yourselves.  Do you
> think
> > >> you
> > >> >> are at that point?  It didn’t look that way to me… but its
> certainly
> > >> >> possible based on what is being done behind the scenes.
> > >> >>>
> > >> >>> Just some food for thought.
> > >> >>>
> > >> >>> Jeff
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht <
> > a

Re: [Discuss] Review-than-commit 3 month trial

A release is:

Majority Approval
Refers to a vote (sense 1) which has completed with at least three binding
+1 votes and more +1 votes than -1 votes - You have to wait 72h.

On 7 July 2017 at 16:25, Andy Gumbrecht  wrote:

> This is not a vote for a release, if you get 3+1s within a minute then you
> don't have to wait 72h. It is 'Consensus Approval'.
>
> Consensus Approval
> 'Consensus approval' refers to a vote (sense 1) which has *completed *with
> at least three binding +1 votes and no vetos
>
> On 7 July 2017 at 16:19, Mark Struberg  wrote:
>
>> You know how voting works at the ASF? ;)
>>
>> Either have a VOTE - with all it's implciations - or not.
>>
>>
>> LieGrue,
>> strub
>>
>> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht > >:
>> >
>> > There's no 72h waiting period? Just 3+1 to commit. I'd even be for a
>> 2+1.
>> >
>> > As soon as whatever is decided is counted then the commit occurs. That
>> > could be within a few minutes.
>> >
>> > Andy.
>> >
>> > On 7 July 2017 at 14:59, Mark Struberg 
>> wrote:
>> >
>> >> +1 well said, Jeff!
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender :
>> >>>
>> >>> Lurking on this, I have to underscore what Mark said.
>> >>>
>> >>> Andy, you are pretty correct on nearly every point that you made.  But
>> >> the things stated are more of refining your current process rather than
>> >> taking RTC for current committers.  You already had RTC with PRs from
>> >> outsiders.  If that slipped in, it just means that a trusted committer
>> >> didn’t do their job.  It happens.   Breaking a trunk build for a day
>> (or
>> >> even a week) is ok.  Thats why its trunk.  I cannot tell you how many
>> times
>> >> I have downloaded a project’s trunk and things weren’t quite right.
>> >>>
>> >>> Relative to what prompted this RTC discussion again, I think things
>> got
>> >> emotional and people slipped up afterwards.  The beauty of all this is
>> all
>> >> parties shook hands and made up.  Problem was more-or-less solved and
>> the
>> >> project was back on track.
>> >>>
>> >>> IMHO, taking on RTC is punitive.  It means that you need to reset the
>> >> way you do things because you cannot do it yourselves.  Do you think
>> you
>> >> are at that point?  It didn’t look that way to me… but its certainly
>> >> possible based on what is being done behind the scenes.
>> >>>
>> >>> Just some food for thought.
>> >>>
>> >>> Jeff
>> >>>
>> >>>
>> >>>
>> >>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht > >
>> >> wrote:
>> >>>>
>> >>>> The main issue here is that both new and existing developers on the
>> >> project
>> >>>> need breathing space in order to thrive and grow.
>> >>>>
>> >>>> The period between releases is for everyone and not just the few. It
>> is
>> >>>> only 99.99% OK for one or two individuals. Everyone else seems to be
>> >>>> suffering behind closed doors or in silence, or fighting constant
>> >> mobbing
>> >>>> to the point where 'our' fun project has become too tedious for many
>> >>>> people's free time.
>> >>>>
>> >>>> I'm not going to focus on the reasons behind the "Suffocating
>> >> development
>> >>>> environment" thread, only that it was the web 'staging' environment
>> used
>> >>>> for a review, but treated like it was North Korea production nuclear
>> >> bomb
>> >>>> code. It should have been handled better. We found a resolution the
>> long
>> >>>> way round (github web hosting).
>> >>>>
>> >>>> However, the situation has evolved where existing committers don't
>> >> discuss,
>> >>>> create or assign tickets because they are literally mobbed or
>> hijacked
>> >> by
>> >>>> another committer within minutes.
>> >>>> That is currently so predictable that it has become a kind of
>> un-funny

Re: [Discuss] Review-than-commit 3 month trial

This is not a vote for a release, if you get 3+1s within a minute then you
don't have to wait 72h. It is 'Consensus Approval'.

Consensus Approval
'Consensus approval' refers to a vote (sense 1) which has *completed *with
at least three binding +1 votes and no vetos

On 7 July 2017 at 16:19, Mark Struberg  wrote:

> You know how voting works at the ASF? ;)
>
> Either have a VOTE - with all it's implciations - or not.
>
>
> LieGrue,
> strub
>
> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht  >:
> >
> > There's no 72h waiting period? Just 3+1 to commit. I'd even be for a 2+1.
> >
> > As soon as whatever is decided is counted then the commit occurs. That
> > could be within a few minutes.
> >
> > Andy.
> >
> > On 7 July 2017 at 14:59, Mark Struberg 
> wrote:
> >
> >> +1 well said, Jeff!
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender :
> >>>
> >>> Lurking on this, I have to underscore what Mark said.
> >>>
> >>> Andy, you are pretty correct on nearly every point that you made.  But
> >> the things stated are more of refining your current process rather than
> >> taking RTC for current committers.  You already had RTC with PRs from
> >> outsiders.  If that slipped in, it just means that a trusted committer
> >> didn’t do their job.  It happens.   Breaking a trunk build for a day (or
> >> even a week) is ok.  Thats why its trunk.  I cannot tell you how many
> times
> >> I have downloaded a project’s trunk and things weren’t quite right.
> >>>
> >>> Relative to what prompted this RTC discussion again, I think things got
> >> emotional and people slipped up afterwards.  The beauty of all this is
> all
> >> parties shook hands and made up.  Problem was more-or-less solved and
> the
> >> project was back on track.
> >>>
> >>> IMHO, taking on RTC is punitive.  It means that you need to reset the
> >> way you do things because you cannot do it yourselves.  Do you think you
> >> are at that point?  It didn’t look that way to me… but its certainly
> >> possible based on what is being done behind the scenes.
> >>>
> >>> Just some food for thought.
> >>>
> >>> Jeff
> >>>
> >>>
> >>>
> >>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht 
> >> wrote:
> >>>>
> >>>> The main issue here is that both new and existing developers on the
> >> project
> >>>> need breathing space in order to thrive and grow.
> >>>>
> >>>> The period between releases is for everyone and not just the few. It
> is
> >>>> only 99.99% OK for one or two individuals. Everyone else seems to be
> >>>> suffering behind closed doors or in silence, or fighting constant
> >> mobbing
> >>>> to the point where 'our' fun project has become too tedious for many
> >>>> people's free time.
> >>>>
> >>>> I'm not going to focus on the reasons behind the "Suffocating
> >> development
> >>>> environment" thread, only that it was the web 'staging' environment
> used
> >>>> for a review, but treated like it was North Korea production nuclear
> >> bomb
> >>>> code. It should have been handled better. We found a resolution the
> long
> >>>> way round (github web hosting).
> >>>>
> >>>> However, the situation has evolved where existing committers don't
> >> discuss,
> >>>> create or assign tickets because they are literally mobbed or hijacked
> >> by
> >>>> another committer within minutes.
> >>>> That is currently so predictable that it has become a kind of un-funny
> >> joke
> >>>> even outside of our community. Tickets are often created 'after' a
> >> commit
> >>>> with a closed status.
> >>>>
> >>>> What needs to change is:
> >>>>
> >>>> Committers need to be able to take and work on a ticket in peace over
> >>>> several days or even weeks, without being trumped due to impatience or
> >> the
> >>>> notion of 'I know better'.
> >>>> Many can only dedicate a finite amount of time, but still need to push
> >>>> in-progress work regularly - Gi

Re: [Discuss] Review-than-commit 3 month trial

There's no 72h waiting period? Just 3+1 to commit. I'd even be for a 2+1.

As soon as whatever is decided is counted then the commit occurs. That
could be within a few minutes.

Andy.

On 7 July 2017 at 14:59, Mark Struberg  wrote:

> +1 well said, Jeff!
>
> LieGrue,
> strub
>
> > Am 06.07.2017 um 18:37 schrieb Jeff Genender :
> >
> > Lurking on this, I have to underscore what Mark said.
> >
> > Andy, you are pretty correct on nearly every point that you made.  But
> the things stated are more of refining your current process rather than
> taking RTC for current committers.  You already had RTC with PRs from
> outsiders.  If that slipped in, it just means that a trusted committer
> didn’t do their job.  It happens.   Breaking a trunk build for a day (or
> even a week) is ok.  Thats why its trunk.  I cannot tell you how many times
> I have downloaded a project’s trunk and things weren’t quite right.
> >
> > Relative to what prompted this RTC discussion again, I think things got
> emotional and people slipped up afterwards.  The beauty of all this is all
> parties shook hands and made up.  Problem was more-or-less solved and the
> project was back on track.
> >
> > IMHO, taking on RTC is punitive.  It means that you need to reset the
> way you do things because you cannot do it yourselves.  Do you think you
> are at that point?  It didn’t look that way to me… but its certainly
> possible based on what is being done behind the scenes.
> >
> > Just some food for thought.
> >
> > Jeff
> >
> >
> >
> >> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht 
> wrote:
> >>
> >> The main issue here is that both new and existing developers on the
> project
> >> need breathing space in order to thrive and grow.
> >>
> >> The period between releases is for everyone and not just the few. It is
> >> only 99.99% OK for one or two individuals. Everyone else seems to be
> >> suffering behind closed doors or in silence, or fighting constant
> mobbing
> >> to the point where 'our' fun project has become too tedious for many
> >> people's free time.
> >>
> >> I'm not going to focus on the reasons behind the "Suffocating
> development
> >> environment" thread, only that it was the web 'staging' environment used
> >> for a review, but treated like it was North Korea production nuclear
> bomb
> >> code. It should have been handled better. We found a resolution the long
> >> way round (github web hosting).
> >>
> >> However, the situation has evolved where existing committers don't
> discuss,
> >> create or assign tickets because they are literally mobbed or hijacked
> by
> >> another committer within minutes.
> >> That is currently so predictable that it has become a kind of un-funny
> joke
> >> even outside of our community. Tickets are often created 'after' a
> commit
> >> with a closed status.
> >>
> >> What needs to change is:
> >>
> >> Committers need to be able to take and work on a ticket in peace over
> >> several days or even weeks, without being trumped due to impatience or
> the
> >> notion of 'I know better'.
> >> Many can only dedicate a finite amount of time, but still need to push
> >> in-progress work regularly - Git makes that easier now. The review
> process
> >> should be a fun and helpful thing.
> >>
> >> Committers and new contributors should be encouraged to take tickets.
> >>
> >> At most, impatience should be directed towards discussion, motivation
> and
> >> encouragement - It's about team play on a global scale, not 'My way or
> the
> >> highway'.
> >>
> >> It is often not viable to test the whole project for a small change - It
> >> takes well over two hours. The buildbot is like our buzzer that says
> "fix
> >> me" - Not revert me, or trash me, or trump me.
> >>
> >> Note to self: Why does the word 'trump' feel like it's been hijacked by
> >> someone?...
> >>
> >> The 'buzzer' should be allowed to ring for a day or two, again not
> everyone
> >> stays up the whole night ready to trash a breaking commit. They go to
> >> sleep, get up, go to work, get home, eat... and then check the build if
> >> they have time the next day.
> >>
> >> It is OK to break the build. Everyone gets to have a go at that and
> learn
> >> from it. Ove

Re: Site and "documentation" usage

2017-07-06 Thread Andy Gumbrecht

Just out of interest, what is everyone's favourite OSS website? I really
like http://projects.spring.io/spring-boot/ and https://fabric8.io/

On 6 July 2017 at 15:58, Andy Gumbrecht  wrote:

> +1 to go to the user list and maybe get some feedback before pushing, but
> also..
>
> +1 to push it as is - Looks really good Ivan, so thank you very much for
> the hard work, and working together on the hosting for review issues. Thank
> you Romain for getting the code set up on GitHub. That makes reviews much
> more transparent!
>
> +1 for continuing to improve the 404 issues over time.
>
> Andy.
>
> On 6 July 2017 at 14:46, Daniel Cunha  wrote:
>
>> +1 to post it user@ list.
>> The users are the real consumers of the website and their feedback is
>> really important.
>>
>> On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>
>> > Hi Ivan!
>> >
>> > Thanks for the links. My personal view - I prefer the documentation
>> link,
>> > but I do like the split of the documentation page into groups. The
>> > advantage here as I see it is all the documentation is linked in one
>> place
>> > - no need to go into 'Developer' and realize its not there, and then
>> check
>> > 'Admin'.
>> >
>> > I also wonder if we should also post this to the users@ list to see if
>> > there are any preferences there?
>> >
>> > I understand Romain's points about the 404 (see the PR comments) - a
>> > potential compromise there is for the admin and developer links to
>> forward
>> > onto the documentation page with a note saying its moved and "please
>> update
>> > your bookmarks". We'll inevitably want to move content around and/or
>> change
>> > the structure over time. Some sort of graceful way of doing that like I
>> > described might be good pattern to follow.
>> >
>> > Thanks for taking the time to hack on this and present it to the
>> community!
>> >
>> > Jon
>> >
>> > On Thu, Jul 6, 2017 at 1:30 PM, Ivan Junckes Filho <
>> ivanjunc...@gmail.com>
>> > wrote:
>> >
>> > > (Please disregard the previous email, pressed enter by mistake)
>> > >
>> > > Hi guys, thank you for the feedback on this. The intention of the
>> > > "Documentation" was to let the user know exactly where what he is
>> looking
>> > > for is. The content inside is not perfect, but we are getting better.
>> > >
>> > > The links for the changes made are below, please give feedback on
>> them.
>> > >
>> > > Pull Request:
>> > > https://github.com/apache/tomee-site-generator/pull/1
>> > >
>> > > Website for review:
>> > > https://ivanjunckes.github.io/
>> > >
>> > > Thank you.
>> > >
>> > >
>> > > On Thu, Jul 6, 2017 at 9:27 AM, Ivan Junckes Filho <
>> > ivanjunc...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hi guys, thank you for the feedback on this. The intention of the
>> > > > "Documentation" was to let the user know exactly where what he is
>> > looking
>> > > > for is. The content inside is not perfect, but we are getting
>> better.
>> > > >
>> > > > Here are all the changes made
>> > > >
>> > > >
>> > > > On Wed, Jul 5, 2017 at 7:51 PM, Romain Manni-Bucau <
>> > > rmannibu...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Ok, saw Andy did a similar comment on github so probably let's
>> reverse
>> > > the
>> > > >> question.
>> > > >>
>> > > >> Anyone feeling like me it is a passthrough? (if not under 1 day
>> think
>> > we
>> > > >> can "close it" and just push it in prod)
>> > > >>
>> > > >>
>> > > >> Romain Manni-Bucau
>> > > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > > >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> > > >> <http://rmannibucau.wordpress.com> | Github <
>> > > >> https://github.com/rmannibucau> |
>> > > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
>> Factory
>> > > >

Re: Site and "documentation" usage

2017-07-06 Thread Andy Gumbrecht

+1 to go to the user list and maybe get some feedback before pushing, but
also..

+1 to push it as is - Looks really good Ivan, so thank you very much for
the hard work, and working together on the hosting for review issues. Thank
you Romain for getting the code set up on GitHub. That makes reviews much
more transparent!

+1 for continuing to improve the 404 issues over time.

Andy.

On 6 July 2017 at 14:46, Daniel Cunha  wrote:

> +1 to post it user@ list.
> The users are the real consumers of the website and their feedback is
> really important.
>
> On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Hi Ivan!
> >
> > Thanks for the links. My personal view - I prefer the documentation link,
> > but I do like the split of the documentation page into groups. The
> > advantage here as I see it is all the documentation is linked in one
> place
> > - no need to go into 'Developer' and realize its not there, and then
> check
> > 'Admin'.
> >
> > I also wonder if we should also post this to the users@ list to see if
> > there are any preferences there?
> >
> > I understand Romain's points about the 404 (see the PR comments) - a
> > potential compromise there is for the admin and developer links to
> forward
> > onto the documentation page with a note saying its moved and "please
> update
> > your bookmarks". We'll inevitably want to move content around and/or
> change
> > the structure over time. Some sort of graceful way of doing that like I
> > described might be good pattern to follow.
> >
> > Thanks for taking the time to hack on this and present it to the
> community!
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 1:30 PM, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> > wrote:
> >
> > > (Please disregard the previous email, pressed enter by mistake)
> > >
> > > Hi guys, thank you for the feedback on this. The intention of the
> > > "Documentation" was to let the user know exactly where what he is
> looking
> > > for is. The content inside is not perfect, but we are getting better.
> > >
> > > The links for the changes made are below, please give feedback on them.
> > >
> > > Pull Request:
> > > https://github.com/apache/tomee-site-generator/pull/1
> > >
> > > Website for review:
> > > https://ivanjunckes.github.io/
> > >
> > > Thank you.
> > >
> > >
> > > On Thu, Jul 6, 2017 at 9:27 AM, Ivan Junckes Filho <
> > ivanjunc...@gmail.com>
> > > wrote:
> > >
> > > > Hi guys, thank you for the feedback on this. The intention of the
> > > > "Documentation" was to let the user know exactly where what he is
> > looking
> > > > for is. The content inside is not perfect, but we are getting better.
> > > >
> > > > Here are all the changes made
> > > >
> > > >
> > > > On Wed, Jul 5, 2017 at 7:51 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > >> Ok, saw Andy did a similar comment on github so probably let's
> reverse
> > > the
> > > >> question.
> > > >>
> > > >> Anyone feeling like me it is a passthrough? (if not under 1 day
> think
> > we
> > > >> can "close it" and just push it in prod)
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > >> <http://rmannibucau.wordpress.com> | Github <
> > > >> https://github.com/rmannibucau> |
> > > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > >> <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >>
> > > >> 2017-07-06 0:48 GMT+02:00 Thomas Whitmore
>  > > com
> > > >> >:
> > > >>
> > > >> > For me the Documentation menu item is very good;  it shows at the
> > top
> > > >> > level that the TomEE project has documentation.
> > > >> > Also like the content of the Documentation page, it hits 'How to
> > > >> > Configure',  'IDEs' and 'Testing' upfront & early which should
> give
> > a
> >

Re: [Discuss] Review-than-commit 3 month trial

2017-07-05 Thread Andy Gumbrecht

The main issue here is that both new and existing developers on the project
need breathing space in order to thrive and grow.

The period between releases is for everyone and not just the few. It is
only 99.99% OK for one or two individuals. Everyone else seems to be
suffering behind closed doors or in silence, or fighting constant mobbing
to the point where 'our' fun project has become too tedious for many
people's free time.

I'm not going to focus on the reasons behind the "Suffocating development
environment" thread, only that it was the web 'staging' environment used
for a review, but treated like it was North Korea production nuclear bomb
code. It should have been handled better. We found a resolution the long
way round (github web hosting).

However, the situation has evolved where existing committers don't discuss,
create or assign tickets because they are literally mobbed or hijacked by
another committer within minutes.
That is currently so predictable that it has become a kind of un-funny joke
even outside of our community. Tickets are often created 'after' a commit
with a closed status.

What needs to change is:

Committers need to be able to take and work on a ticket in peace over
several days or even weeks, without being trumped due to impatience or the
notion of 'I know better'.
Many can only dedicate a finite amount of time, but still need to push
in-progress work regularly - Git makes that easier now. The review process
should be a fun and helpful thing.

Committers and new contributors should be encouraged to take tickets.

At most, impatience should be directed towards discussion, motivation and
encouragement - It's about team play on a global scale, not 'My way or the
highway'.

It is often not viable to test the whole project for a small change - It
takes well over two hours. The buildbot is like our buzzer that says "fix
me" - Not revert me, or trash me, or trump me.

Note to self: Why does the word 'trump' feel like it's been hijacked by
someone?...

The 'buzzer' should be allowed to ring for a day or two, again not everyone
stays up the whole night ready to trash a breaking commit. They go to
sleep, get up, go to work, get home, eat... and then check the build if
they have time the next day.

It is OK to break the build. Everyone gets to have a go at that and learn
from it. Over and over. We don't release broken builds, only the good ones
in-between.

Any disagreement at any level goes to a vote. The majority wins.

I think a trial RTC policy can help achieve these goals as it forces
community involvement - A good thing.

Andy.

On 5 July 2017 at 23:02, Jonathan Gallimore 
wrote:

> Are you referring to the changes in the "Suffocating development
> environment" thread, or something else? In my view, the patch Andy applied
> last week had very limited review (1 person), and the revert had no review.
> We've seen contributions come in through GitHub PRs (which is great), but
> also applied directly to the repository by committers without further
> discussion (less great), effectively meaning just 1 reviewer - I'm not sure
> that's really the spirit of RTC.
>
> Jon
>
>
> On Wed, Jul 5, 2017 at 6:06 PM, Mark Struberg 
> wrote:
>
> > As far as I recall the original issue was initially caused by applying a
> > PR.
> > That means we had this very issue with a commit which had RTC in place.
> >
> > Draw your own conclusions...
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 05.07.2017 um 14:26 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Hmm, let put it in a raw way: can we skip the asf list on these
> > > discussions? Literally means can be use the way everybody uses for RTC,
> > ie
> > > github PRs *only*. If not I don't see the point to use it since
> > > contributors we got are mainly github/jira and I think it is natural
> as a
> > > contributor to use these media instead of the list.
> > >
> > > Can we somehow merge the github flow with the mailing in a smoother way
> > > than the jira integration - and even make jira optional? If not I'm
> > pretty
> > > sure it doesn't need any more evaluation, if we can then it can be
> great
> > to
> > > benefit from github well known flow.
> > >
> > > To rephrase it to maybe make it even more explicit: it is not about
> > making
> > > our - as committers - work easier but making contributions easier.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhclo

Re: Suffocating development environment

2017-06-28 Thread Andy Gumbrecht

The subject of this thread is intended to cover the multiple incidents of
the past and address the increasing number of current and future concerns
coming from multiple contributors, that will remain anonymous for obvious
reasons. I am just being the voice with broad shoulders here.

In this instance there were basically two simple human errors that
should/would have been resolved in an orderly manner. They only serve as
the example of how the current climate is, and why we should consider
changing it for the benefit of the community. The thread topic should still
be the focus.

1. The project was checked in missing the target svn ignore and it was
never subsequently fixed, so the add pulled in target. This was only
noticed during a commit in action. On attempting to rectify this simple
mistake less than one minute later someone had already took it upon
themselves to trash all commits rather than allow the problem to be
resolved in an orderly fashion either through the ticket in progress or
email - this came after the effect, i.e too late. Obviously this action led
to multiple conflicts. Making it virtually impossible to recover.

2. The deployment to staging has often been used to provide access for
review purposes in the past, but as Romain rightly points out there are
risks involved in doing that, and a better way is to use the personal http
spaces at Apache. The risks were still trivial and could be reverted in a
matter of minutes if the staging were to be inadvertently published, but
still agree that the personal space is the right place. That still does not
warrant trashing someone else's work, ever. The problem should have been
addressed appropriately. Acting in any other way is always going to inflame
a situation, every time, without fail. Who likes having their evenings work
deleted? Having it corrected is generally welcome I would guess.

Both actions and the ensuing assertion in comments that the effort was only
made in determent to the project, or only for the benefit of a third party
company, is derogatory and inflammatory. Especially from whence it came and
the potential conflict of interests involved already. This will again
always result in a defensive response when it is simply not true. It will
never result in a submissive response.

Either way, the introduction of a 2 or 3 plus one workflow will completely
mitigate any future issues like this. No one makes a commit with the
intention of breaking something. Commits are made every day across the
world that *do* break something. Everyone needs to understand that, and
respond appropriately. Especially on an global  OSS project where people
are dedicating their free time. TomEE is *not* a nuclear bomb that cannot
be touched for fear of it exploding between stable releases. Version
control is our saving grace. Community contributors need breathing space to
grow into the project. Everyone makes mistakes. Mistakes should not be a
means used to alienate new contributions, only as a tool to guide real
people with real feelings in the right direction.

To finish off. If work by contributors spans several days, or even weeks,
then so be it. TomEE is not a full time project for many contributors. Most
here have a life outside of the box and can only dedicate a limited amount
of time. This means that it is simply not feasible to expect feature
complete patches or commits. Incremental work must even be encouraged, as
every step counts. The impatient must learn to become patient, and not
trash incremental contributions.

Andy.

On 28 June 2017 at 12:35, Romain Manni-Bucau  wrote:

> 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> :
>
> > Wow.
> >
> > Well, thanks for writing the email, and starting the discussion. From
> where
> > I'm sitting, it looks like there are a few issues. I'll work in
> reverse-ish
> > order (in terms of your post).
> >
> > -- Reverting commits.
> >
> > I've seen the reverts - I also note that other than on a JIRA ticket,
> there
> > was zero conversation on the dev@ list. This isn't the first time that
> > this
> > has happened, and in my opinion, is fundamentally wrong. If there is a
> > genuine need to revert something, you need to post to the dev@ list,
> call
> > out the commit, and say why it needs reverting. The person proposing the
> > revert should be prepared to have a should we "roll-back or fail-forward"
> > conversation in the community, and not simply take it upon themselves to
> > make that choice. Folks might be wondering why we need to do this (I
> think
> > there is a perception that their mail might not be read, so why bother
> > posting) - reasons are simple:
> >
> > * Encourage discussion and contribution - discuss the specific issues.
> What
> > stopped working? Does

Suffocating development environment

2017-06-27 Thread Andy Gumbrecht

I'm writing this on the public dev list as there seems to be inaction on
the private list regarding the preservation and nurturing of contributions
to the TomEE project. I hope this serves as an entry into a public
discussion on how to improve or resolve the situation.

This evening (and late into the night) I was working in my free time
together with another contributor in an effort to improve the currently
very poor TomEE website. This work was offsite, and being pushed to staging
for peer review.

It became apparent that another committer deemed it in some way acceptable
to trash this effort 'during' this work without any collaboration simply
because they disagree with some of the changes, even when those changes had
not been finalised. The existence and state of the JIRA ticket was
completely disregarded by this committer.

This is not the first time that a committer has performed such arrogant and
destructive actions on other peoples contributions to the project. Such
actions are always extremely disrespectful at a personal level. This is of
course reflected by the state of the community that currently feels void of
any participation specifically due to this kind of mobbing. It has become
virtually impossible for contributors to perform any work on the project
without almost instant negative, rather than positive or nurturing, input
at every level (even documentation). I know of several potential
contributors who have avoided the project due to this currently very
predictable attitude. It has in fact almost become a joke within other
communities.

Maybe speaking for others, it is no secret that some committers do not get
along with others due to these reasons. However, I do value the immense
contribution by every committer to the TomEE project and understand each
individuals value and rights to and on the project. This does not mean that
one individual is the owner of this project (we all are) and has the right
to overwrite or trash other peoples work in progress, no one should ever
have that sole right. Well actually we all do, and this seems to be the
fundamental problem.

We desperately need to instigate some measures to prevent the further
demise of the TomEE community by individuals that seem intent on breaking
it for reasons that go beyond me (well actually they don't, but that's
another story). I believe that there was a past discussion on introducing a
2 or 3 plus one workflow into the the project, whereby all commits must
undergo a peer review. This may somewhat stifle rapid development, but on
the other hand it would ensure that commits are stable and not open to
trashing by others.

Given that the current JIRA practice is now to commit before creating the
actual issue (which has been encouraged by the overly aggressive
environment), the peer review system would also return that process back to
a normal and acceptable state. Therefore I would like to suggest we begin
taking the necessary steps for the introduction of this process.

Looking forward to some candid responses.

Best regards,

Andy.


-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: The EE8 Roadmap

2017-06-19 Thread Andy Gumbrecht

+1 for TomEE 8, when it's time - I'm sure that was what we agreed when we
made the move to TomEE 7, the major version stays inline with the EE
version. Makes it pretty clear.

Andy.

On 18 June 2017 at 18:08, Romain Manni-Bucau  wrote:

> mvc too is under radar, think cxf is a good fit but myfaces can be good too
> since we have web experts here
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-18 18:07 GMT+02:00 John D. Ament :
>
> > I think it would be great to start a project in any form for the security
> > spec.
> >
> > John
> >
> > On Sun, Jun 18, 2017 at 11:35 AM Mark Struberg  >
> > wrote:
> >
> > > Or a subproject somewhere if we create it from scratch and don't take
> > over
> > > any existing sources where the IP is not 100% guaranteed to be clear.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > > Am 18.06.2017 um 16:01 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >
> > > > first step would probably be to create an incubator project to impl
> the
> > > spec
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-06-18 13:17 GMT+02:00 Mark Struberg  >:
> > > >
> > > >> Well, that would be way cool!
> > > >>
> > > >> LieGrue,
> > > >> strub
> > > >>
> > > >>
> > > >>> Am 18.06.2017 um 11:54 schrieb Rudy De Busscher <
> > rdebussc...@gmail.com
> > > >:
> > > >>>
> > > >>> Great news
> > > >>>
> > > >>> What are the plans for the Security API?  It will also be included
> in
> > > the
> > > >>> Web Profile.
> > > >>>
> > > >>> I can help with the implementation if you like.
> > > >>>
> > > >>> Best regards
> > > >>> Rudy
> > > >>>
> > > >>>
> > > >>> On 17 June 2017 at 21:57, Mark Struberg  >
> > > >> wrote:
> > > >>>
> > > >>>> FYI, With help from Romain, Reinhard Sandtner, Gerhard Petracek
> and
> > > John
> > > >>>> Ament,  Apache OpenWebBeans now passes the CDI-2.0 TCK!
> > > >>>>
> > > >>>> The next step is to do a bit more testing, release the missing
> > > Geronimo
> > > >>>> spec APIs and then we are good to go for rolling TomEE-8.0.0 ^^
> > > >>>>
> > > >>>> LieGrue,
> > > >>>> strub
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> Am 05.06.2017 um 12:59 schrieb Jean-Louis Monteiro <
> > > >>>> jlmonte...@tomitribe.com>:
> > > >>>>>
> > > >>>>> Wow, great status Mark.
> > > >>>>> Thanks a lot.
> > > >>>>>
> > > >>>>> Yes, agree, TomEE 8.x seems to be the de facto choice based on
> what
> > > the
> > > >>>>> community decided last time.
> > > >>>>> Even though the time is missing I'd like to help somehow and join
> > the
> > > >>>>> effort.
> > > >>>>>
> > > >>>>> I'll shoot when I have some time.
> > > >>>>>
> > > >>>>> Cheers.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Jean-Louis Monteiro
> > > >>>>

Re: [DISCUSS] 1.x EOL

2017-06-19 Thread Andy Gumbrecht

-1

I would welcome an EOL announcement at the end of the year (with a years
notice), but not right now. That's too much pressure. So to make that
clear, I would announce EOL on the 1st Jan.18 and EOL is then 1st Jan 2019
- That gives everyone plenty of time to create detailed documentation on
the site that targets everyone, and then plenty of time to migrate.

We could make a pre-EOL announcement that details the above plan. An
announcement of the planned announcement so to say - That would enable
contribution and discussion regarding the EOL effort by the community
rather than being a snap decision.

Andy.

On 18 June 2017 at 20:36, Romain Manni-Bucau  wrote:

> http://tomee.apache.org/developer/migration/tomee-1-to-7.html intends to
> solve that issue, we can add any point we hit/encounter
>
> what else would be a blocker to make 1 EOL in June 2018?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-18 20:17 GMT+02:00 Romain Manni-Bucau :
>
> >
> >
> > 2017-06-18 19:50 GMT+02:00 Mark Struberg :
> >
> >> regarding migration.
> >> There are 3 different main use cases afaict.
> >> 1.) TomEE standalone server, quite like Tomcat. Using 7.x instead 1.7.x
> >> should be a no-brainer without any need to change something within your
> >> application
> >>
> >> 2.) tomee-maven-plugin: change the groupId from org.apache.openejb to
> >> org.apache.tomee. Done
> >>
> >
> >
> >
> >
> >> 3.) openejb-core for unit tests. This gets a bit trickier as the various
> >> spec APIs from EE7 (tomee) and EE6 (your application) might clash. This
> can
> >> be solved with an exclude setting in the maven-surefire-plugin
> >>
> >
> > Hmm, just means we upgrade API or you think to something else?
> >
> > I'll start a page
> >
> >
> >> LieGrue,strub
> >>
> >>
> >> On Sunday, 18 June 2017, 18:51, Romain Manni-Bucau <
> >> rmannibu...@gmail.com> wrote:
> >>
> >>
> >>  2017-06-18 18:42 GMT+02:00 Jonathan Gallimore <
> jgallim...@tomitribe.com
> >> >:
> >>
> >> > Thanks for the feedback. I think at least some sort of migration guide
> >> is
> >> > needed as some settings have changed. It would be nice for people to
> >> find
> >> > out the easy way. Happy to discuss in another thread, but we should
> >> agree
> >> > when this will appear.
> >> >
> >>
> >> Which settings are you thinking about?
> >>
> >>
> >> >
> >> > I also think some visibility on what the EOL statement will actually
> >> say (I
> >> > guess it would be a paragraph or two) would help community discussion.
> >> >
> >>
> >> No more expectation from the core community (releases etc). So
> evolutions
> >> as best effort (no guarantee).
> >>
> >>
> >> >
> >> > I suspect you won't agree, but I think an EOL is a major
> announcement. A
> >> > reminder is good if the thread has gone quiet, but I think lazy
> >> concensus
> >> > is less good, unless several reminders have been sent. You have
> stated a
> >> > deadline of today, a Sunday - I think some folks may miss that and be
> >> too
> >> > late. I think mid week would be better to reduce the scope of "missing
> >> it".
> >> > If we got to mid week, and had a couple more reminders, the lazy
> >> concensus
> >> > view would seem more reasonable.
> >> >
> >> > Wouldn't you prefer to make the EOL statement with a few more +1's?
> >> >
> >>
> >> Sure, now i used past releases as prevision of this topic activity
> >> plannification and even with 5 reminders i wouldnt have got more so
> >> preferring to move forward now. However as said  I'm happy to discuss
> each
> >> points and delay what was just a proposal.
> >>
> >>
> >> >
> >> > Jon
> >> >
> >> > On 18 Jun 2017 5:06 pm, "Romain Manni-Bucau" 
> >> > wrote:
> >> >
> >> > > 2017-06-18 17:36 GMT+02:0

Re: [VOTE] Apache TomEE 7.0.3

2017-03-10 Thread Andy Gumbrecht

If this is the case, why is tomee.jpa.factory.lazy=tue not the default? 
I'm guessing this will be an issue for anyone using hibernate.


Andy.


On 08/03/2017 20:22, DonatasCiuksys wrote:

Yes, with property tomee.jpa.factory.lazy=true it started to work.
Thank you very much, Adam!



--
View this message in context: 
http://tomee-openejb.979440.n4.nabble.com/VOTE-Apache-TomEE-7-0-3-tp4681228p4681238.html
Sent from the TomEE Dev mailing list archive at Nabble.com.


--
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: [VOTE] Apache TomEE 7.0.3

2017-03-08 Thread Andy Gumbrecht

Already know it's not getting analysed anyway, so don't really care.

Change me to a +-0


On 8 Mar 2017 13:19, "Mark Struberg"  wrote:

I also don't see any showstopper.
Yes, we might fix this but it's probably only experienced by devs anyway.
And it looks like this was the behaviour since long time, so I see no
reason to block the release neither.

Andy are you fine with targetting this for 7.0.4?

txs and LieGrue,
strub


> Am 08.03.2017 um 12:15 schrieb Romain Manni-Bucau :
>
> i sent it to the list on the commit thread that it was not needed and
> leading to close twice the pool which is an issue so just wrapped it in a
> finally (other parts of the commit were introducing regressions as
> explained in the thread).
>
> Since we start to lock the pool the race condition shouldnt occur there
but
> there was a little chance under start[abrupt ctrl+x] case to not close
> properly the pool so added a finally. Also this method is not intended to
> be used in a concurrent environment (actually issue would be higher level
> if you underploy concurrently the same app which is more than unlikely. It
> is an undeploy method bound to one bean so no supported concurrency there
-
> except in tests?).
>
> Anyway since it is there since > 5 years and not causing any security
issue
> it is not a cancel reason I think.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-03-08 11:10 GMT+01:00 Andy Gumbrecht :
>
>> -1
>>
>> https://github.com/rmannibucau/tomee/commit/
55d6d5ec89da68a6794487bc75f95b
>> 55cad7b483
>>
>> Not sure why the public boolean close(final long timeout, final TimeUnit
>> unit) throws InterruptedException { method doesn't look like this one in
>> 1.7.x?:
>> https://github.com/apache/tomee/blob/tomee-1.7.x/
>> container/openejb-core/src/main/java/org/apache/openejb/util/Pool.java
>> - Was pretty sure I checked it in on master too. Looks like an older
commit
>> and not the last one I have? My fault, as I guess I didn't push to
master.
>>
>> The stop() method also needs to be called before draining (in the close
>> method), else there is a potential race.
>>
>> The atomics must be set to null on stop(), so getAndSet is better as it
is
>> a single atomic action rather than two (get, compare = 4 locks in total).
>>
>> Basically the tomee-1.7.x Pool stop() and close() methods are correct and
>> tested (also on site), and can be forwarded to master. I won't be able to
>> fix master till I get home tonight, so if someone could compare the
>> tomee-1.7.x methods and update master that would be cool.
>>
>> Andy.
>>
>>
>> On 8 March 2017 at 08:32, Romain Manni-Bucau 
>> wrote:
>>
>>> Hi guys,
>>>
>>> as discussed on the list here is the vote for 7.0.3. It is mainly
>>> dependencies upgrades and a few fixes.
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/orgapachetomee-1104/
>>> Source zip:
>>> https://repository.apache.org/content/repositories/
>>> orgapachetomee-1104/org/apache/tomee/tomee-project/7.
>>> 0.3/tomee-project-7.0.3-source-release.zip
>>> Dist area: https://dist.apache.org/repos/dist/dev/tomee/7.0.3/
>>> Changelog:
>>> https://issues.apache.org/jira/browse/TOMEE-2018?jql=
>>> project%20%3D%20TOMEE%20AND%20fixVersion%20%3D%207.0.3%
>>> 20AND%20(resolution%20%3D%20Resolved%20OR%20resolution%20%3D%20Fixed)
>>> Green buildbot:
>>> https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/603
>>> Branch: https://github.com/rmannibucau/tomee/tree/release/7.0.3
>>>
>>> Please vote:
>>> - +1: it rocks, release it
>>> - +-0: why do you bother me?
>>> - -1 don't release it cause ${blocker}
>>>
>>> As usual vote will be open for 3 days or until we get 3 +1 bindings and
>> no
>>> -1. Anyone is welcomed to vote!
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>>> rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>
>>
>>
>>
>> --
>>  Andy Gumbrecht
>>  https://twitter.com/AndyGeeDe
>>  http://www.tomitribe.com
>>

Re: [VOTE] Apache TomEE 7.0.3

2017-03-08 Thread Andy Gumbrecht

-1

https://github.com/rmannibucau/tomee/commit/55d6d5ec89da68a6794487bc75f95b55cad7b483

Not sure why the public boolean close(final long timeout, final TimeUnit
unit) throws InterruptedException { method doesn't look like this one in
1.7.x?:
https://github.com/apache/tomee/blob/tomee-1.7.x/container/openejb-core/src/main/java/org/apache/openejb/util/Pool.java
- Was pretty sure I checked it in on master too. Looks like an older commit
and not the last one I have? My fault, as I guess I didn't push to master.

The stop() method also needs to be called before draining (in the close
method), else there is a potential race.

The atomics must be set to null on stop(), so getAndSet is better as it is
a single atomic action rather than two (get, compare = 4 locks in total).

Basically the tomee-1.7.x Pool stop() and close() methods are correct and
tested (also on site), and can be forwarded to master. I won't be able to
fix master till I get home tonight, so if someone could compare the
tomee-1.7.x methods and update master that would be cool.

Andy.


On 8 March 2017 at 08:32, Romain Manni-Bucau  wrote:

> Hi guys,
>
> as discussed on the list here is the vote for 7.0.3. It is mainly
> dependencies upgrades and a few fixes.
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1104/
> Source zip:
> https://repository.apache.org/content/repositories/
> orgapachetomee-1104/org/apache/tomee/tomee-project/7.
> 0.3/tomee-project-7.0.3-source-release.zip
> Dist area: https://dist.apache.org/repos/dist/dev/tomee/7.0.3/
> Changelog:
> https://issues.apache.org/jira/browse/TOMEE-2018?jql=
> project%20%3D%20TOMEE%20AND%20fixVersion%20%3D%207.0.3%
> 20AND%20(resolution%20%3D%20Resolved%20OR%20resolution%20%3D%20Fixed)
> Green buildbot:
> https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/603
> Branch: https://github.com/rmannibucau/tomee/tree/release/7.0.3
>
> Please vote:
> - +1: it rocks, release it
> - +-0: why do you bother me?
> - -1 don't release it cause ${blocker}
>
> As usual vote will be open for 3 days or until we get 3 +1 bindings and no
> -1. Anyone is welcomed to vote!
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: [VOTE] Apache TomEE 7.0.0

2016-05-18 Thread Andy Gumbrecht

Please give everyone a really good chance to test this one and not rush
through on a 3 +1 binding. Most are also not going to be able to fully test
until the weekend.

The docs need to be in place to explain this is *not *EE7 out of the box,
and should be a part of this review/vote.

There needs to be a definitive statement of what is and what is not
available in this release.

This is more than just a regular binary release. It is a rubber stamped
TomEE statement of the current state of the project, and should be treated
as such.

The world is our customer and we cannot afford bad press on this.

Andy.

On 18 May 2016 at 12:45, cocorossello  wrote:

> Tested, works fine in my side.  +1
>
> (you said everyone is welcome so here is my vote  )
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/VOTE-Apache-TomEE-7-0-0-tp4678479p4678488.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: tomee git commit: TOMEE-1799 - Comparison method violates its general contract

2016-05-06 Thread Andy Gumbrecht

The sort still doesn't look right to me with the default also as a criteria.

On 6 May 2016 at 14:04, Romain Manni-Bucau  wrote:

> Hi Andy
>
> This change breaks previous ordering and doesnt fix the referenced issue -
> was not an issue on 7.x.
>
> Any objection if I restore previous ordering next week?
> -- Message transféré --
> De : 
> Date : 5 mai 2016 15:11
> Objet : tomee git commit: TOMEE-1799 - Comparison method violates its
> general contract
> À : 
> Cc :
>
> Repository: tomee
> Updated Branches:
>   refs/heads/master a9e29701b -> 3a46ba5fd
>
>
> TOMEE-1799 - Comparison method violates its general contract
>
> https://issues.apache.org/jira/browse/TOMEE-1799
>
>
> Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/3a46ba5f
> Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/3a46ba5f
> Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/3a46ba5f
>
> Branch: refs/heads/master
> Commit: 3a46ba5fd624a68577726124b647d5dcd217d4d9
> Parents: a9e2970
> Author: AndyGee 
> Authored: Thu May 5 15:10:37 2016 +0200
> Committer: AndyGee 
> Committed: Thu May 5 15:10:37 2016 +0200
>
> --
>  .../org/apache/openejb/config/AutoConfig.java   |   7 +-
>  .../openejb/activemq/AMQXASupportTest.java  |   6 +-
>  .../apache/openejb/config/AutoConfigTest.java   | 448 +++
>  3 files changed, 457 insertions(+), 4 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> --
> diff --git
>
> a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
>
> b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> index fa81261..9c40293 100644
> ---
>
> a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> +++
>
> b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> @@ -2063,8 +2063,9 @@ public class AutoConfig implements DynamicDeployer,
> JndiConstants {
>  return -1;
>  } else if (o2.startsWith(prefix)) {
>  return 1;
> +} else {
> +return resourceIds.indexOf(o2) -
> resourceIds.indexOf(o1);
>  }
> -return resourceIds.indexOf(o1) - resourceIds.indexOf(o2);
>  }
>  });
>  String idd = null;
> @@ -2269,7 +2270,7 @@ public class AutoConfig implements DynamicDeployer,
> JndiConstants {
>  return null;
>  }
>
> -private static class AppResources {
> +static class AppResources {
>
>  private String appId;
>
> @@ -2307,7 +2308,7 @@ public class AutoConfig implements DynamicDeployer,
> JndiConstants {
>  public AppResources() {
>  }
>
> -public AppResources(final AppModule appModule) {
> +protected AppResources(final AppModule appModule) {
>
>  this.appId = appModule.getModuleId();
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> --
> diff --git
>
> a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
>
> b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> index b283305..1391f1e 100644
> ---
>
> a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> +++
>
> b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> @@ -119,7 +119,11 @@ public class AMQXASupportTest {
>  producer.send(session.createTextMessage(TEXT));
>  assertTrue(Listener.sync());
>  } finally {
> -connection.close();
> +try {
> +connection.close();
> +} catch (final JMSException e) {
> +//no-op
> +}
>  }
>  }
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest.java
> --
> diff --git
>
> a/container/openejb-core/src/test/java/org/apache/open

Re: tomee git commit: TOMEE-1799 - Comparison method violates its general contract

2016-05-06 Thread Andy Gumbrecht

If that's the case sure, but keep/update the test.

On 6 May 2016 at 14:04, Romain Manni-Bucau  wrote:

> Hi Andy
>
> This change breaks previous ordering and doesnt fix the referenced issue -
> was not an issue on 7.x.
>
> Any objection if I restore previous ordering next week?
> -- Message transféré --
> De : 
> Date : 5 mai 2016 15:11
> Objet : tomee git commit: TOMEE-1799 - Comparison method violates its
> general contract
> À : 
> Cc :
>
> Repository: tomee
> Updated Branches:
>   refs/heads/master a9e29701b -> 3a46ba5fd
>
>
> TOMEE-1799 - Comparison method violates its general contract
>
> https://issues.apache.org/jira/browse/TOMEE-1799
>
>
> Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/3a46ba5f
> Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/3a46ba5f
> Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/3a46ba5f
>
> Branch: refs/heads/master
> Commit: 3a46ba5fd624a68577726124b647d5dcd217d4d9
> Parents: a9e2970
> Author: AndyGee 
> Authored: Thu May 5 15:10:37 2016 +0200
> Committer: AndyGee 
> Committed: Thu May 5 15:10:37 2016 +0200
>
> --
>  .../org/apache/openejb/config/AutoConfig.java   |   7 +-
>  .../openejb/activemq/AMQXASupportTest.java  |   6 +-
>  .../apache/openejb/config/AutoConfigTest.java   | 448 +++
>  3 files changed, 457 insertions(+), 4 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> --
> diff --git
>
> a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
>
> b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> index fa81261..9c40293 100644
> ---
>
> a/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> +++
>
> b/container/openejb-core/src/main/java/org/apache/openejb/config/AutoConfig.java
> @@ -2063,8 +2063,9 @@ public class AutoConfig implements DynamicDeployer,
> JndiConstants {
>  return -1;
>  } else if (o2.startsWith(prefix)) {
>  return 1;
> +} else {
> +return resourceIds.indexOf(o2) -
> resourceIds.indexOf(o1);
>  }
> -return resourceIds.indexOf(o1) - resourceIds.indexOf(o2);
>  }
>  });
>  String idd = null;
> @@ -2269,7 +2270,7 @@ public class AutoConfig implements DynamicDeployer,
> JndiConstants {
>  return null;
>  }
>
> -private static class AppResources {
> +static class AppResources {
>
>  private String appId;
>
> @@ -2307,7 +2308,7 @@ public class AutoConfig implements DynamicDeployer,
> JndiConstants {
>  public AppResources() {
>  }
>
> -public AppResources(final AppModule appModule) {
> +protected AppResources(final AppModule appModule) {
>
>  this.appId = appModule.getModuleId();
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> --
> diff --git
>
> a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
>
> b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> index b283305..1391f1e 100644
> ---
>
> a/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> +++
>
> b/container/openejb-core/src/test/java/org/apache/openejb/activemq/AMQXASupportTest.java
> @@ -119,7 +119,11 @@ public class AMQXASupportTest {
>  producer.send(session.createTextMessage(TEXT));
>  assertTrue(Listener.sync());
>  } finally {
> -connection.close();
> +try {
> +connection.close();
> +} catch (final JMSException e) {
> +//no-op
> +}
>  }
>  }
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/3a46ba5f/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest.java
> --
> diff --git
>
> a/container/openejb-core/src/test/java/org/apache/openejb/config/AutoConfigTest

Re: TomEE 1.7.x on Java8

I'll have a look at the fix this evening. No rush for this... yet ;-)

On 2 May 2016 at 15:54, Romain Manni-Bucau  wrote:

> if it helps: there is a system property for that in the JVM to revert to
> the old sort algo, should solve it. Also think it has been fixed further on
> 7.x branch.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-05-02 15:52 GMT+02:00 Andy Gumbrecht :
>
> > OK, wasn't sure. So now I have an issue. It's maybe an app issue as it is
> > only one app from 85, but feel like TomEE should cope with this.
> >
> > https://issues.apache.org/jira/browse/TOMEE-1795
> >
> > Will post more info when available.
> >
> > Andy.
> >
> > On 2 May 2016 at 15:21, Romain Manni-Bucau 
> wrote:
> >
> > > Hi Andy,
> > >
> > > yes we do for default distributions
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-05-02 15:16 GMT+02:00 Andy Gumbrecht :
> > >
> > > > Are we supporting TomEE 1.7.x on Java8?
> > > >
> > > > Andy.
> > > >
> > > > --
> > > >   Andy Gumbrecht
> > > >   https://twitter.com/AndyGeeDe
> > > >   http://www.tomitribe.com
> > > >
> > >
> >
> >
> >
> > --
> >   Andy Gumbrecht
> >   https://twitter.com/AndyGeeDe
> >   http://www.tomitribe.com
> >
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: TomEE 1.7.x on Java8

OK, wasn't sure. So now I have an issue. It's maybe an app issue as it is
only one app from 85, but feel like TomEE should cope with this.

https://issues.apache.org/jira/browse/TOMEE-1795

Will post more info when available.

Andy.

On 2 May 2016 at 15:21, Romain Manni-Bucau  wrote:

> Hi Andy,
>
> yes we do for default distributions
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-05-02 15:16 GMT+02:00 Andy Gumbrecht :
>
> > Are we supporting TomEE 1.7.x on Java8?
> >
> > Andy.
> >
> > --
> >   Andy Gumbrecht
> >   https://twitter.com/AndyGeeDe
> >   http://www.tomitribe.com
> >
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

TomEE 1.7.x on Java8

Are we supporting TomEE 1.7.x on Java8?

Andy.

-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: 7.0.0 release vote

Yep, misleading use of the word 'OR' on this page -
http://hibernate.org/community/license/ - "Hibernate projects are licensed
under either the LGPL 2.1 or the ASL 2.0"

On 2 May 2016 at 14:05, Romain Manni-Bucau  wrote:

> 2016-05-02 14:00 GMT+02:00 Andy Gumbrecht :
>
> > I still feel we are due another Milestone release until TomEE is a little
> > closer to the mark. There needs to be a really strong statement as to
> what
> > is available and what is not. There has already been some negative
> feedback
> > from power users that expected more, and were disappointed to find
> missing
> > features they expected to find merely based on the 7.x label - Wrongly
> > thinking that TomEE EE7 support was complete (Because we haven't really
> > told them).
> >
> >
> Fully agree that's why it has been stated tomee 7 != javaee 7. We also got
> very negative feedback and worse than negative feedbacks -> blockers to not
> have a version without "M". You are free to do a milestone if you want and
> even a 8.0.0 when we get certified. In the meantime I see only harmful
> reasons to block all people waiting on a not milestone (including vendors).
>
> Said otherwise: I try to push the concrete path vs the philosophical one.
>
>
> > Would there be a problem distributing the latest Hibernate (ASL) with
> > TomEE? - Even if some features would need unwrapping and documenting.
> >
> >
> it is still mentionned being lgpl 2.1 on their website. validator is asl
> AFAIK cause of JCP but orm is not. Did you find another source?
>
>
> > Andy.
> >
> > On 2 May 2016 at 13:48, Roberto Cortez 
> > wrote:
> >
> > > Some JAX-RS tests are using JPA 2.1 features which is not supported
> yet.
> > >   From: John D. Ament 
> > >  To: dev@tomee.apache.org
> > >  Sent: Monday, May 2, 2016 12:11 PM
> > >  Subject: Re: 7.0.0 release vote
> > >
> > > On Mon, May 2, 2016 at 2:44 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Not portable test, jpa on not jpa tests etc. We pass really more
> tests
> > > > AFAIK.
> > >
> > >
> > > Could you elaborate on that a little? What is not portable?  If you
> want
> > to
> > > raise issues in our ticket system please feel free:
> > > https://github.com/javaee-samples/javaee7-samples/issues
> > >
> > > Or if you want to just say them, I can put them into github.
> > >
> > >
> > >
> > > > Le 2 mai 2016 05:48, "David Blevins"  a
> > écrit :
> > > >
> > > > > No worries on the many posts.  Thank you for the Java EE 7 samples
> > > > checkup
> > > > > :)
> > > > >
> > > > > It appears we fail 35% of the JAX-RS 2.0 tests.  Do we know what is
> > > > > preventing us from passing those tests?
> > > > >
> > > > >
> > > > > --
> > > > > David Blevins
> > > > > http://twitter.com/dblevins
> > > > > http://www.tomitribe.com
> > > > >
> > > > > > On May 1, 2016, at 6:42 PM, John D. Ament  >
> > > > wrote:
> > > > > >
> > > > > > Sorry for so many posts :-)
> > > > > >
> > > > > > TomEE Plus 7.0.0-M3 passes 238/338 tests in the suite.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Sun, May 1, 2016 at 9:30 PM John D. Ament <
> > johndam...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> I ended up changing the version and updating the code.  I ran
> the
> > > > tests,
> > > > > >> you can see the output in this gist:
> > > > > >>
> > https://gist.github.com/johnament/2443e79836605a913159b14295681536
> > > > > >>
> > > > > >> TomEE Plus fails at about 100 tests.
> > > > > >>
> > > > > >> John
> > > > > >>
> > > > > >>
> > > > > >> On Sun, May 1, 2016 at 8:10 PM John D. Ament <
> > johndam...@apache.org
> > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> If it helps any, I can push up the latest TomEE version to the
> > > TomEE
> > > > > >>> profile

Re: 7.0.0 release vote

I still feel we are due another Milestone release until TomEE is a little
closer to the mark. There needs to be a really strong statement as to what
is available and what is not. There has already been some negative feedback
from power users that expected more, and were disappointed to find missing
features they expected to find merely based on the 7.x label - Wrongly
thinking that TomEE EE7 support was complete (Because we haven't really
told them).

Would there be a problem distributing the latest Hibernate (ASL) with
TomEE? - Even if some features would need unwrapping and documenting.

Andy.

On 2 May 2016 at 13:48, Roberto Cortez  wrote:

> Some JAX-RS tests are using JPA 2.1 features which is not supported yet.
>   From: John D. Ament 
>  To: dev@tomee.apache.org
>  Sent: Monday, May 2, 2016 12:11 PM
>  Subject: Re: 7.0.0 release vote
>
> On Mon, May 2, 2016 at 2:44 AM Romain Manni-Bucau 
> wrote:
>
> > Not portable test, jpa on not jpa tests etc. We pass really more tests
> > AFAIK.
>
>
> Could you elaborate on that a little? What is not portable?  If you want to
> raise issues in our ticket system please feel free:
> https://github.com/javaee-samples/javaee7-samples/issues
>
> Or if you want to just say them, I can put them into github.
>
>
>
> > Le 2 mai 2016 05:48, "David Blevins"  a écrit :
> >
> > > No worries on the many posts.  Thank you for the Java EE 7 samples
> > checkup
> > > :)
> > >
> > > It appears we fail 35% of the JAX-RS 2.0 tests.  Do we know what is
> > > preventing us from passing those tests?
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > > > On May 1, 2016, at 6:42 PM, John D. Ament 
> > wrote:
> > > >
> > > > Sorry for so many posts :-)
> > > >
> > > > TomEE Plus 7.0.0-M3 passes 238/338 tests in the suite.
> > > >
> > > > John
> > > >
> > > > On Sun, May 1, 2016 at 9:30 PM John D. Ament 
> > > wrote:
> > > >
> > > >> I ended up changing the version and updating the code.  I ran the
> > tests,
> > > >> you can see the output in this gist:
> > > >> https://gist.github.com/johnament/2443e79836605a913159b14295681536
> > > >>
> > > >> TomEE Plus fails at about 100 tests.
> > > >>
> > > >> John
> > > >>
> > > >>
> > > >> On Sun, May 1, 2016 at 8:10 PM John D. Ament  >
> > > >> wrote:
> > > >>
> > > >>> If it helps any, I can push up the latest TomEE version to the
> TomEE
> > > >>> profile:
> > > >>>
> > >
> >
> https://github.com/javaee-samples/javaee7-samples/blob/master/pom.xml#L690
> > > >>>
> > > >>> John
> > > >>>
> > > >>>
> > > >>> On Sun, May 1, 2016 at 8:07 PM David Blevins <
> > david.blev...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> In terms of statements of compliance, which of these Java EE 7
> > samples
> > > >>>> will currently run successfully?
> > > >>>>
> > > >>>> - https://github.com/javaee-samples/javaee7-samples <
> > > >>>> https://github.com/javaee-samples/javaee7-samples>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> David Blevins
> > > >>>> http://twitter.com/dblevins
> > > >>>> http://www.tomitribe.com
> > > >>>>
> > > >>>>> On Apr 28, 2016, at 6:19 AM, ross.cohen  >
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> Actually, it looks like a 7.0 release means different things to
> > > >>>> different
> > > >>>>> people.  Romain, you took everyone's approval of the idea of a
> > 7.0.0
> > > >>>> release
> > > >>>>> to be an approval of your particular version of a 7.0.0 release,
> > > which
> > > >>>> it
> > > >>>>> clearly was not.  Looks to me like a finer-grained vote is needed
> > to
> > > >>>> figure
> > > >>>>> out exactly what people want as part of 7.0.0 release.
> > > >>>>>
> > > >>>>> Personally, I think David is correct in saying that a release
> > without
> > > >>>> some
> > > >>>>> kind of positive JEE 7 compatibility statement is a serious
> > mistake.
> > > >>>> I know
> > > >>>>> the TCK is out of the question right now, but that simply means
> you
> > > >>>> need to
> > > >>>>> invent an alternative compatibility statement:  "Apache-Certified
> > > >>>> Compliant
> > > >>>>> to Web Profile Specifications" (or some such).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> View this message in context:
> > > >>>>
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/7-0-0-release-vote-tp4678284.html
> > > >>>>> Sent from the TomEE Dev mailing list archive at Nabble.com.
> > > >>>>
> > > >>>>
> > >
> > >
> >
>
>
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: [VOTE][LAZY] Next tomee release using 7.0.0 version

+1 for 7.0.0 (documented status)

On 25 April 2016 at 14:56, Jonathan Gallimore 
wrote:

> On Mon, Apr 25, 2016 at 1:39 PM, Romain Manni-Bucau  >
> wrote:
>
> >
> > Does it clarify the intent?
> >
> >
> It does, thank you. Providing that TCK status is clearly documented with
> the release, and there are no legal issues, I have no objection to a 7.0.0.
>
> +1.
>
> Jon
> --
> Jonathan Gallimore
> http://twitter.com/jongallimore
> http://www.tomitribe.com
>



-- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: Next release 7.1?

+1 for 7.0.0, with a proper write up of what to expect from it.

http://www.tomitribe.com - @AndyGeeDe - On a small screen device.
On 25 Apr 2016 14:24, "Romain Manni-Bucau"  wrote:

> well we never said we'll align JavaEE 7 with TomEE 7 - made it clear in
> http://tomee-openejb.979440.n4.nabble.com/Versioning-help-td4677842.html
> at
> least and probably another thread - so it is milestone until we judged we
> want a final.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-04-25 14:22 GMT+02:00 Andy Gumbrecht :
>
> > I mean, it's still a milestone. So should just carry on the 7.0.0-Mx
> path.
> > 7.1.0 can't really exist until 7.0.0 is released?
> >
> > http://www.tomitribe.com - @AndyGeeDe - On a small screen device.
> > On 25 Apr 2016 13:47, "Jonathan Gallimore" 
> > wrote:
> >
> > On Mon, Apr 25, 2016 at 10:20 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > My 2 cts
> > >
> > > We have 3 milestones of the TomEE 7.0.0. People already using it are
> > > expecting a final version, and I agree with that.
> > >
> >
> > +1
> >
> > My personal opinion is that in seeing a jump to a 7.1.M1, people will
> look
> > for a 7.0 GA, and be confused because its missing. I know I would be.
> >
> >
> > >
> > > Tomcat 8.5 already integrated to master brings an important feature
> > HTTP/2
> > > we want to have and offer to our users. Tomcat 8.5 is fully backward
> > > compatible with Tomcat 8.x ( x < 5).
> > >
> >
> > +1
> >
> >
> > >
> > > So I don't see any issue in having TomEE 7.0.0 final released on the
> > master
> > > and already integrating Tomcat 8.5.
> > >
> >
> > + 1
> >
> >
> > >
> > > I understand Romain's point to reflect Tomcat jump in terms of version,
> > but
> > > having a TomEE 7.1.0 would appear weird if we don't have a TomEE 7.0.0.
> > >
> > > If we really want to follow Romain's point and reflect the Tomcat
> > > versioning jump, I'd go with first a 7.0.0 based on the M3 with a
> couple
> > of
> > > bugfixes but with Tomcat 8.x (x < 5) and also a TomEE 7.1.0 with Tomcat
> > 8.x
> > > (x >= 5).
> > >
> > > So my view is
> > >
> > > Option 1/
> > > TomEE 7.0.0 with Tomcat 8.x (x >= 5) with HTTP/2
> > >
> >
> > I don't have any objection to that.
> >
> >
> >
> > >
> > > *or*
> > >
> > > Option 2/
> > > TomEE 7.0.0 with Tomcat 8.x (x < 5) without HTTP/2
> > > +
> > > TomEE 7.1.0 with Tomcat 8.x (x >= 5) with HTTP/2
> > >
> > >
> > I think this is confusing - we already have the concept of "flavours"
> > (webprofile, jaxrs, plus, plume) which determine what features are "in
> the
> > box". Mixing in whether or not you get HTTP/2 in with the version number
> > seems confusing to me.
> >
> > If Tomcat 8.5 is fully backwards compatible with previous Tomcat 8.x
> > releases (and I note that JL says it is above), I see no reason for TomEE
> > 7.0.0.M4 onwards to use that, and include HTTP/2 support.
> >
> > Jon
> >
> > --
> > Jonathan Gallimore
> > http://twitter.com/jongallimore
> > http://www.tomitribe.com
> >
>

Re: Next release 7.1?

I mean, it's still a milestone. So should just carry on the 7.0.0-Mx path.
7.1.0 can't really exist until 7.0.0 is released?

http://www.tomitribe.com - @AndyGeeDe - On a small screen device.
On 25 Apr 2016 13:47, "Jonathan Gallimore"  wrote:

On Mon, Apr 25, 2016 at 10:20 AM, Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> My 2 cts
>
> We have 3 milestones of the TomEE 7.0.0. People already using it are
> expecting a final version, and I agree with that.
>

+1

My personal opinion is that in seeing a jump to a 7.1.M1, people will look
for a 7.0 GA, and be confused because its missing. I know I would be.


>
> Tomcat 8.5 already integrated to master brings an important feature HTTP/2
> we want to have and offer to our users. Tomcat 8.5 is fully backward
> compatible with Tomcat 8.x ( x < 5).
>

+1


>
> So I don't see any issue in having TomEE 7.0.0 final released on the
master
> and already integrating Tomcat 8.5.
>

+ 1


>
> I understand Romain's point to reflect Tomcat jump in terms of version,
but
> having a TomEE 7.1.0 would appear weird if we don't have a TomEE 7.0.0.
>
> If we really want to follow Romain's point and reflect the Tomcat
> versioning jump, I'd go with first a 7.0.0 based on the M3 with a couple
of
> bugfixes but with Tomcat 8.x (x < 5) and also a TomEE 7.1.0 with Tomcat
8.x
> (x >= 5).
>
> So my view is
>
> Option 1/
> TomEE 7.0.0 with Tomcat 8.x (x >= 5) with HTTP/2
>

I don't have any objection to that.



>
> *or*
>
> Option 2/
> TomEE 7.0.0 with Tomcat 8.x (x < 5) without HTTP/2
> +
> TomEE 7.1.0 with Tomcat 8.x (x >= 5) with HTTP/2
>
>
I think this is confusing - we already have the concept of "flavours"
(webprofile, jaxrs, plus, plume) which determine what features are "in the
box". Mixing in whether or not you get HTTP/2 in with the version number
seems confusing to me.

If Tomcat 8.5 is fully backwards compatible with previous Tomcat 8.x
releases (and I note that JL says it is above), I see no reason for TomEE
7.0.0.M4 onwards to use that, and include HTTP/2 support.

Jon

--
Jonathan Gallimore
http://twitter.com/jongallimore
http://www.tomitribe.com

Re: Next release 7.1?