Re: How Can I Help ?

[A D]

Thank you for great suggestions, I will certainly write to the list 
users@tomee.Apache with as much as details do someone can provide an idea or 
clue.
The problem is when I hit the endpoint/wsdl , absolutely we don’t see any 
activity in the Logs, 
It appears that some pieces of stuff related to wsdl is missing , not sure 

Thank you
AD

Sent from my iPhone

> On May 9, 2022, at 12:39 AM, Zowalla, Richard 
>  wrote:
> 
> If you are seeking for help / guideance for solving your wsdl/404
> issue, it might be worth to (a) subscribe and (b) write to
> 
> us...@tomee.apache.org
> 
> Add as much as explanation as possible and - which would be the most
> beneficial thing - add a small self containing code example / project
> on GitHub, which reproduces the issue. 
> 
> We have a lot of very experienced users on users@, so it could also be
> possible, that there are people, who had the same issue you are
> encounter and might have a "quick fix" in their heads. 
> 
> The dev@ list is used for technical discussion while working on
> features / bugs / enhancements, etc :)
> 
> From a practical point of view: I would try to get some more log /
> trace details from TomEE to see, what goes wrong, i.e. printing the
> wsdl link, etc. 
> 
> Gruß
> Richard
> 
> 
> 
> 
>> Am Montag, dem 09.05.2022 um 00:24 -0600 schrieb AD:
>> Thank you so much Richard or giving me an overall area of work ,
>> sounds
>> very interesting to me.
>> 
>> I will take a deeper look at these and certainly get back to you.
>> 
>> Yes , I am facing a Tomee related issue for our project , which was
>> developed for Weblogic .
>> 
>> We are now migrating to Tomee , strange is the deployment is so
>> perfect ,
>> you can't believe it , with no warning or errors . But when we try to
>> hit
>> the endpoint/wsdl  or an operation it shows 404 , which is so weird.
>> 
>> I have been spending a lot of time on tomee deployment and all its
>> samples
>> , on tomeetribe etc etc , but still no luck at ..but gaining lot of
>> knowledge and experience
>> 
>> Hope I can get some ideas/inputs to solve this , so i will have
>> certainly
>> have time to contribute here a lot
>> 
>> Thank you
>> -AD
>> 
>> On Mon, May 9, 2022 at 12:07 AM Zowalla, Richard <
>> richard.zowa...@hs-heilbronn.de> wrote:
>> 
>>> Hi AD,
>>> 
>>> TomEE consumes a variety of ASF projects for specific parts of its
>>> core
>>> functionality.
>>> 
>>> Apache Geronimo provides JavaEE / JakartaEE libraries and
>>> Microprofile
>>> implementations [1]. A big effort would be to update the
>>> Microprofile
>>> implementation in Geronimo to support JakartaEE namespace (so we do
>>> not
>>> need to use SmallRye implementation like all the other app
>>> servers).
>>> There was some discussion in [2] about this topic.
>>> 
>>> Another examples are the dependencies currently shaded to bring
>>> javax
>>> -> jakarta namespace listed in [3]. Some efforts on other projects
>>> (like the apache commons project) are needed in order to drop our
>>> fork/shade and handle the namespace change in the related project.
>>> Such
>>> activities are also of great value to the TomEE community.
>>> 
>>> While working on the namespace change for ActiveMQ, the people over
>>> there asked why we didn't support ActiveMQ Artemis yet [4]. We do
>>> not
>>> have integration code for Artemis, so this would also be a possible
>>> area of contribution if you have the skills / experience in this
>>> field.
>>> 
>>> Other areas of work involve upgrading / revising our current
>>> examples
>>> (TomEE 8.x, TomEE 9.x) by using our "BOM" approach in order to make
>>> them easier to consume / understand so users do not have to think
>>> about: "Which version of XY do I need to include to make it
>>> work?!".
>>> Some of them are using very old libraries (9+ years old)  and would
>>> benefit from an upgrade to newer dependencies / versions or use
>>> deprecated jks keystore formats, which need conversion to drop
>>> warnings. Such activies are rather "easy" and can help to get a
>>> feeling
>>> for TomEE and OSS contributions in general.
>>> 
>>> Of course our current website and the dev/admin/migration
>>> documentation
>>> would also benefit from a careful review and a subsequent review
>>> and
>>> revise.
>>> 
>>> Some harder tasks involve running the TCK [5] and working on
>>> plattform
>>> compliance for EE9.1, i.e. fixing and working on the tests. Same is
>>> true for working on the Smallrye miroprofile integration and fixing
>>> tests / things. TCK tasks require some organisation / discussion
>>> via
>>> the list to avoid that work is conducted multiple times.
>>> 
>>> Perhaps, you suffer from a TomEE bug yourself and nobody did find
>>> time
>>> to work on it yet. That would also be a starting point to jump in.
>>> 
>>> As you probably see, there is always a lof of work to do. It fully
>>> depends on your available time / resources. My list isn't nearly
>>> complete but that is what I have directly in my mind.
>>> 
>>> Gruß
>>> 

Re: Microprofile OpenAPI

[John D. Ament]

The question posed to the MP team does not really match the question posted
here, and seems to be a tangental ask.

The problem is this line of code [1], and nothing to do with TomEE's
behavior; it defaults to JSON even though the spec states it should be
YAML.  Perhaps a clean solution would be to make this a config setting?
But seems like there's a missing TCK test as well.  I'd also question when
a browser goes here, what does it send in the Accepts header.  My guess is
most modern browsers send text/html which also wouldn't line up.

John

[1]:
https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57

On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau 
wrote:

> Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends
> where you deploy it (i dont think implementing a custom writer for that is
> right for users, it has too much pitfalls once integrated to anything else
> than this very specific spec).
>
> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
>> If the spec requires that, then I'd expect to get a YAML response if
>> making a request without an `Accept` header on the request.
>>
>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>> that to be tested, and I'd suggest contributing a test there if there isn't
>> one.
>>
>> If you wanted to explicitly request a YAML response, I'd expect one of
>> these to work:
>>
>> Accept: application/x-yaml
>> Accept: text/yaml
>>
>> I'd expect a Content-Type header on the response to identify the mime
>> type of the response, whatever is being returned.
>>
>> Jon
>>
>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho 
>> wrote:
>>
>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>
>>> The spec says:
>>> "The default format of the /openapi endpoint is YAML."
>>>
>>> But when I try to access /openapi it returns JSON by default.
>>>
>>> This is not correct.
>>>
>>> Also how can I access yaml if it is not default?
>>>
>>

Re: MP-JWT progress

[John D. Ament]

On Mon, Mar 19, 2018 at 3:20 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> 2018-03-19 0:07 GMT+01:00 John D. Ament <johndam...@apache.org>:
>
>>
>>
>> On Sun, Mar 18, 2018 at 5:38 PM Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> Le 18 mars 2018 21:29, "David Blevins" <david.blev...@gmail.com> a
>>> écrit :
>>>
>>>
>>> > On Mar 18, 2018, at 12:43 PM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>> >
>>> > 1. code will be at geronimo - whatever happens at tomee
>>>
>>> As far as I understand the topic is still open and no git repos have
>>> been created anywhere yet, is that right?
>>>
>>>
>>> Yes
>>>
>>>
>>> Is there anyone on the Geronimo side who would be open to collaborating
>>> on a reusable JWT library under the TomEE project for a change?  Something
>>> not branded tomee or geronimo.
>>>
>>>
>>> This is what was proposed to be created @g which is just an umbrella, no
>>> more a project delivery by itself.
>>>
>>> Are you against/-1ing g-jwt-auth?
>>>
>>
>> As mentioned elsewhere in the thread, I am against bringing something in
>> geronimo that is TomEE specific.  I haven't looked at the code (as far as I
>> can tell, nothing is linked in this thread so I have no idea if code even
>> exists) but based on what I've seen with implementing JWT it's closely tied
>> to your container.  So I don't believe its a good fit.
>>
>> Why is your preference to bring this into geronimo?
>>
>
> As mentionned there is no link to TomEE in the jwt-auth codebase so no
> reason to hold that code in something not reusable at tomee.
>


Too many negatives in that sentence to make sense of what you're trying to
say.


>
>
>>
>>
>>>
>>>
>>>
>>> -David
>>>
>>>
>>>
>

Re: MP-JWT progress

[John D. Ament]

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

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

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

Why is your preference to bring this into geronimo?


>
>
>
> -David
>
>
>

Re: MP-JWT progress

[John D. Ament]

I don't think its a good idea to move TomEE code into Geronimo.

On Fri, Mar 9, 2018 at 5:50 AM Romain Manni-Bucau 
wrote:

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

Re: IP Clearance for Sheldon and Chatterbox

[John D . Ament]

Sorry I got dropped along the way (and am not subscribed to your dev list).  I 
believe both projects are already in public repos, so keeping there would be 
fine.  The most important part is getting the IP Clearance started in the 
incubator.

As far as moving the repos, its just an infra ticket (once the IP clearance is 
done) requesting moving the repos.  One of the infra admins will ask to be made 
an admin in your repo and will execute the move once done.

On 2018/02/13 23:12:09, Jonathan Gallimore <jonathan.gallim...@gmail.com> 
wrote: 
> Can you post where we need to review? I'm more than happy to help with the
> review process.
> 
> Jon
> 
> On Tue, Feb 13, 2018 at 8:56 PM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> 
> > John, I have both cleaned up with the right headers, notice and license
> > files.
> > It's ready for review. I'll be creating the git repos tonight and push
> > sources for review in a tomitribe repo.
> >
> > As soon as everyone is happy we can do the actual import @Apache
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Tue, Feb 13, 2018 at 6:55 PM, David Blevins <david.blev...@gmail.com>
> > wrote:
> >
> > > Thanks, John.
> > >
> > > > On Feb 13, 2018, at 9:43 AM, John D. Ament <johndam...@apache.org>
> > > wrote:
> > > >
> > > > The overall IP Clearance process can be found at [2].  Someone will
> > need
> > > to
> > > > commit the necessary files, call the vote etc.  I would recommend
> > > separate
> > > > IP Clearances for each component.  I believe I would be comfortable
> > > > pointing to specific git hashes for the import, assuming you would want
> > > to
> > > > have infra just move the repos from tomitribe to apache on github,
> > > instead
> > > > of recreating the repos (helps keep the stars and forks in sync).
> > >
> > > Moving the repos is ideal if we could do that.  Then github will
> > redirect.
> > >
> > > How do we execute that option?
> > >
> > >
> > > -David
> > >
> > >
> >
> 

Re: IP Clearance for Sheldon and Chatterbox

[John D. Ament]

Hey David & co

Assuming all files in the donation already have the header as found at [1],
then no an SGA wouldn't be required.  We've been leaning towards keeping
SGAs just when the license and copyrights need to change.  It appears the
original authors already had the ASF in mind so no need to change
anything.  If any contributor hasn't signed an ICLA, they should sign an
ICLA; but considering the code is already apache licensed it wouldn't be
needed.  You may want to consider adding a NOTICE entry indicating that the
original authors were Tomitribe not Apache, but up to you.

The overall IP Clearance process can be found at [2].  Someone will need to
commit the necessary files, call the vote etc.  I would recommend separate
IP Clearances for each component.  I believe I would be comfortable
pointing to specific git hashes for the import, assuming you would want to
have infra just move the repos from tomitribe to apache on github, instead
of recreating the repos (helps keep the stars and forks in sync).

John

[1]:
https://github.com/tomitribe/sheldon/blob/master/sheldon-impl/src/main/java/org/tomitribe/sheldon/cdi/TerminalSessionContext.java
[2]: http://incubator.apache.org/ip-clearance/


On Tue, Feb 13, 2018 at 12:14 PM David Blevins 
wrote:

> John, can you put on your Incubator hat and remind me of the process?
>
> I vaguely recall we'll need:
>
>  - Software Grant from Tomitribe for both codebases
>  - iCLA for anyone who doesn't already have it
>
> I think we're good on iCLAs -- everyone is already a committer.  Daniel
> Cunha is not yet a TomEE committer.  I forget how we handled that in
> Geronimo.
>
> I also seemed to recall there was a formal checklist.
>
>
> -David
>
>

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

[John D . Ament]

t;
> > > jlmonte...@tomitribe.com
> > > > >:
> > > > >
> > > > > > I'm fine either way, do we want one per sub-project/sub-tool or one
> > > > with
> > > > > > everything inside?
> > > > > > If we go this path I'm tempted to say, one per contribution.
> > > > > >
> > > > > >
> > > > > > That would make
> > > > > > tomee git repo
> > > > > > tomee-sheldon git repo
> > > > > > tomee-chatterbox git repo
> > > > > >
> > > > > >
> > > > > > Jean-Louis
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > > On Mon, Feb 5, 2018 at 2:35 PM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > just plain new git repos IMHO
> > > > > > >
> > > > > > >
> > > > > > > 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-05 14:21 GMT+01:00 Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com
> > > > > > >:
> > > > > > >
> > > > > > > > In terms of source code, do we want something like this
> > > > > > > >
> > > > > > > > tomee/ (the main git project)
> > > > > > > > ..tomee-server/ --> no idea what name would be the best from a
> > > user
> > > > > > > > perspective
> > > > > > > > ..sheldon/
> > > > > > > > ..chatterbox/
> > > > > > > >
> > > > > > > > WDYT?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Jean-Louis Monteiro
> > > > > > > > http://twitter.com/jlouismonteiro
> > > > > > > > http://www.tomitribe.com
> > > > > > > >
> > > > > > > > On Mon, Feb 5, 2018 at 2:06 PM, Jonathan Gallimore <
> > > > > > > > jonathan.gallim...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Excellent. Happy to help with the process in any way I can.
> > > > > > > > >
> > > > > > > > > Jon
> > > > > > > > >
> > > > > > > > > On Mon, Feb 5, 2018 at 1:03 PM, Jean-Louis Monteiro <
> > > > > > > > > jlmonte...@tomitribe.com> wrote:
> > > > > > > > >
> > > > > > > > > > Looks like David is busy, so I'll close the VOTE for him
> > and
> > > > > > proceed.
> > > > > > > > > >
> > > > > > > > > > The VOTE passes with
> > > > > > > > > >
> > > > > > > > > > +1: John D. Ament, Jonathan Gallimore, Mark Struberg, Andy
> > > > > > Gumbrecht,
> > > > > > > > > David
> > > > > > > > > > Blevins and Jean-Louis Monteiro
> > > > > > > > > >
> > > > > > > > > > No 0 and no -1
> > > > > > > > > >
> > > > > > > > > > non-binding +1: Matthew Broadhead, Elder Moraes
> > > > > > > > > >
> > > > > > > > > > Thanks for voting
> > > > > > > > > > Jean-Louis
> > > > > > > > > >
> > > > > > &

Re: Implementing Microprofile JWT

[John D . Ament]

On 2018/02/12 20:42:58, Jonathan Gallimore <jonathan.gallim...@gmail.com> 
wrote: 
> On Mon, Feb 12, 2018 at 8:20 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> 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 don't recall that discussion. Where did it take place?

I *think* he meant me.  The only time JWT came up on Geronimo was at [1].  I 
had mentioned bringing over an impl based on Jose4J, Romain felt very strongly 
we mustn't rely on 3rd party libraries.  I'm not sure why that is, but it 
seemed based on the discussion we had two different aims so it wasn't something 
I pushed forward on.  If there's interest within TomEE to get a JWT impl up and 
running, I'd be happy to help (though I do feel strongly relying on a 3rd party 
lib for the actual signature validation + external sig support is important; to 
avoid that overhead).

RE MP @ TomEE/Geronimo.  I don't believe there's any hard or fast rules about 
what projects are allowed to host.  For example, there's interest within 
Skywalking to host the CDI and JAX-RS extensions to support OpenApi; but this 
spec doesn't represent something any server vendor would support since its 
really about your APM solution.  CXF happily took on the MP Rest Client when I 
proposed it; though I would hope TomEE relies on the CXF library instead of 
crafting their own client (selfish desires).  The JWT spec is weird, because it 
defined non MP runtime behavior in addition to MP runtime behavior; so there 
may be more integration work in a fuller app server like TomEE.



John

[1]: 
https://lists.apache.org/thread.html/4edc997cfe2e45aaf25bb118bc621634c2832641cf3a9d954a6f7245@%3Cdev.geronimo.apache.org%3E

> 
> 
> >
> > 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.
> >
> 
> I agree the discussion should happen first, and I note that the change has
> been reverted. I recall that we agreed on this list that we'd create new
> git projects for Sheldon and Chatterbox under the TomEE umbrella. Should
> other components sit under TomEE, I imagine that they would follow the same
> pattern - i.e. discuss first, agree location, create repo or move things
> around as appropriate.
> 
> I don't know what your specific issues are here, but I think you are making
> some assumptions that are simply not true.
> 
> Jon
> 
> 
> 
> >
> > Le 12 févr. 2018 21:14, "Andy Gumbrecht" <agumbre...@tomitribe.com> 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
> > >> > h

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

[John D. Ament]

Did you tally?

I have an internal ASF use case for chatterbox that I'd like to figure out
the next steps on.

John

On Mon, Sep 25, 2017 at 3:21 PM David Blevins 
wrote:

> My +1
>
> ... will tally shortly.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Sep 8, 2017, at 2:24 PM, David Blevins 
> wrote:
> >
> > Let’s put this up for a vote.  Proposal:
> >
> > Should we accept the code donations of Sheldon and Chatterbox as part of
> the Apache TomEE project.
> >
> >  - https://tomitribe.io/projects/sheldon <
> https://tomitribe.io/projects/sheldon>
> >  - https://tomitribe.io/projects/chatterbox <
> https://tomitribe.io/projects/chatterbox>
> >
> > They’ll be named Apache Sheldon and Apache Chatterbox respectively.
> Maven groupid and java packages up for discussion.  (I have no preference)
> >
> > All votes welcome:
> >
> >  +1: Let’s do this!
> >
> > +0: I don't feel strongly about it, but I'm okay with this.
> >
> > -0: I won't get in the way, but I'd rather we didn't do this.
> >
> > -1: I really don't like this, because [insert reason]
> >
> > I’ll leave this up for a week so people have time to vote.  All votes
> are welcome from anyone.  The more votes the better.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins 
> > http://www.tomitribe.com
> >
>
>

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

[John D. Ament]

+1 IF and ONLY IF Sheldon has a class named Cooper.

On Sep 8, 2017 5:24 PM, "David Blevins"  wrote:

> Let’s put this up for a vote.  Proposal:
>
> Should we accept the code donations of Sheldon and Chatterbox as part of
> the Apache TomEE project.
>
>  - https://tomitribe.io/projects/sheldon
>  - https://tomitribe.io/projects/chatterbox
>
> They’ll be named Apache Sheldon and Apache Chatterbox respectively.  Maven
> groupid and java packages up for discussion.  (I have no preference)
>
> All votes welcome:
>
>  +1: Let’s do this!
>
> +0: I don't feel strongly about it, but I'm okay with this.
>
> -0: I won't get in the way, but I'd rather we didn't do this.
>
> -1: I really don't like this, because [insert reason]
>
> I’ll leave this up for a week so people have time to vote.  All votes are
> welcome from anyone.  The more votes the better.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: [DISCUSS] Code donations: Sheldon and Chatterbox

[John D. Ament]

In all honesty, while the ASF as a whole doesn't have a true strategy, or
expect projects to work to benefit each other, I do think in this situation
it makes a lot of sense to think about the various communities at the ASF
and do some thinking around what makes the most sense for a user of Apache
products (independent of past, present, future employers).

There are some PMCs that exist to support the implementation of a Java EE
specification.  There are other PMCs that support Java EE but also come up
with very easy ways to make their product work independent of Java EE.  By
being independent of any specific application server, projects like
Johnzon, OpenWebBeans can go ahead and be leveraged in other products.
This gives those products broader reach by being fully independent.  By
putting Sheldon and Chatterbox directly into the TomEE PMC's hands, you are
closely tying the products together.

One other idea that I heard throw around was creating an EE commons type of
project.  It could handle these off to the side projects that are really
maintained by the ASF #usualSuspects and make it clear that they really
work across many different platforms, similar to the original premise
behind Apache DeltaSpike.  On the flip side, I'm not convinced that
Geronimo is that project either.

John

On Sun, Aug 13, 2017 at 2:58 PM David Blevins 
wrote:

> We can keep any existing ssh code if we like.
>
> In terms of why TomEE, as mentioned here’s are some of the benefits:
>
>  - show the TomEE ecosystem is a bit bigger than just the server
>  - provide a clear pattern for “crazy new ideas” to start here that could
> potentially benefit TomEE or other EE related-projects
>  - more opportunities to earn commit
>  - give the community a boost
>
> We used to get a lot of committers in based on EJB improvements, however
> since that spec has slowed and is not moving forward, I think we need more
> opportunities for people to earn commit.
>
> In terms of G.  Obviously as co-founder of the project and someone who
> spent 9+ years on it full-time under 3 different employers, I have a
> different relationship to the name.  I think it’s great there’s new blood
> in G, including you, imagining a new future for it.  But my heart is really
> in TomEE.  When I look at Geronimo I see my past, when I look at TomEE I
> see my future.
>
> Everyone is entitled to his or her own goals, hopes and dreams, I just
> want to be clear where my heart is at.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Aug 11, 2017, at 11:43 PM, Romain Manni-Bucau 
> wrote:
> >
> > Does it mean we drop the ssh module?
> >
> > Why ot going incubator to promote the portability of these projects?
> > (Whatever you do, if tomee subproject it is perceived as tomee bound).
> Are
> > they too small?
> >
> > Why not geronimo subprojects since it is the official umbrella project
> now
> > - vs tomee is not until we rediscuss it transprojects.
> >
> > Really sounds weird to me to try to push it in tomee when we agreed to do
> > it in G weeks ago, what am I missing?
> >
> > Le 11 août 2017 22:58, "David Blevins"  a
> écrit :
> >
> >>> On Aug 11, 2017, at 3:20 AM, Mark Struberg 
> >> wrote:
> >>>
> >>> Reusable components make sense they are clearly distinctable. The part
> >> which contains that reusable components imo must get a different brand
> name
> >> than TomEE.
> >>
> >> Sheldon would stay named Sheldon.  Chatterbox would stay named
> >> Chatterbox.  They’d get their own JIRAs.  They’d just be hosted here on
> you
> >> could get to them via the tomee.apache.org website.
> >>
> >>> The problem here is: TomEE does a really bad job in pointing out these
> >> ties! If TomEE would kind of cumulate this progress and make it clear
> that
> >> this makes it into TomEE, then it would be much clearer that there is no
> >> standstill but actually tons of activity.
> >>
> >> I think this is a great topic you should lead.
> >>
> >>
> >> -David
> >>
> >>
>
>

Re: [DISCUSS] Code donations: Sheldon and Chatterbox

[John D. Ament]

Don't forget to do IP clearance


I personally think these are awesome projects.  David's been passionate
about this stuff for a long time, and I was really hopefully to get these
MDB enhancements working on the JMS spec, never happened :-(

It would be great to see these at Apache, and hopefully with a pretty
robust test suite showing them working in multiple EE containers.

John

On Wed, Aug 9, 2017 at 9:58 PM David Blevins 
wrote:

> Hi All,
>
> I’d like to open the topic of potentially donating a couple components
> we’ve built over at tomitribe.io to our beloved TomEE project:
>
>  - https://tomitribe.io/projects/sheldon <
> https://tomitribe.io/projects/sheldon>
>  - https://tomitribe.io/projects/chatterbox <
> https://tomitribe.io/projects/chatterbox>
>
> There are couple motivating factors:
>
>  - show the TomEE ecosystem is a bit bigger than just the server
>  - provide a clear pattern for “crazy new ideas” to start here that could
> potentially benefit TomEE or other EE related-projects
>  - more opportunities to earn commit
>  - give the community a boost
>
> We went from EJB container to EE server.  I’d be great to take another
> step and see us go to EE ecosystem.
>
> Thoughts?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: Site NG on github

[John D. Ament]

Romain,

For the site generation, if you want to switch to gitwcsub (and dump the
SVN repo) its simply a matter of having a job (buildbot or jenkins) that
will build the commit and push the result to a special branch (most are
using asf-site).  Since you're already using mvn to generate the site, I
think all you'd have to do is specify the new repo + branch name.

John


On Tue, Jul 4, 2017 at 12:20 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Ok submitted
> https://git-wip-us.apache.org/repos/asf/tomee-tomee-site-generator.git,
>
> @John: do you have more details about gitwcsub, didnt find much except it
> is the git replacement of svnpubsub? idea would be to sync a generated
> folder with the remote "content" repo. Very worse case I can add it to our
> generator with a java svn or git client, shouldnt take the night ;)
>
>
> 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-04 17:20 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > Would be better to request a git repo via https://reporeq.apache.org/ if
> > you want a repository.  You may also want to consider using gitwcsub
> > instead of svnpubsub for the actual generated site.
> >
> > John
> >
> > On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau <rmannibu...@gmail.com
> >
> > wrote:
> >
> > > Ok, let say if there is no -1 tonight I'll update the ticket to ask it
> -
> > it
> > > doesnt hurt worse case so dont think we need to wait much more, in
> > > particular if we want to work on the website now. Let me know if it is
> a
> > > concern at any level.
> > >
> > >
> > > 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-04 15:04 GMT+02:00 Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com>
> > > :
> > >
> > > > As in +1 for moving the project :-)
> > > >
> > > > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
> > > > ivanjunc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> I think last time I checked github for the website was not up to
> > date.
> > > > >>
> > > > >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha <
> > daniels...@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >> > Well, TomEE already moved to git, you don't need to use SVN.
> > > > >> > PR integration already works fine, I saw that with last
> > Jean-Louis's
> > > > >> merge.
> > > > >> >
> > > > >> > But yes, will be awesome to have it, we can use it like a stage
> > and
> > > > the
> > > > >> > process to deploy in prod will be identical.
> > > > >> >
> > > > >> > +1 for that.
> > > > >> >
> > > > >> > On Tue, Jul 4, 2017 at 9:56 AM, Ivan Junckes Filho <
> > > > >> ivanjunc...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > This would be great, way better than doing svn patches.
> > > > >> > >
> > > > >> > > +1
> > > > >> > >
> > > > >> > > On Tue, Jul 4, 2017 at 9:54 AM, Romain Manni-Bucau <
> > > > >> > rmannibu...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Hi guys,
> > > > >> > > >
> > > > >> > > >

Re: Site NG on github

[John D. Ament]

Would be better to request a git repo via https://reporeq.apache.org/ if
you want a repository.  You may also want to consider using gitwcsub
instead of svnpubsub for the actual generated site.

John

On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau 
wrote:

> Ok, let say if there is no -1 tonight I'll update the ticket to ask it - it
> doesnt hurt worse case so dont think we need to wait much more, in
> particular if we want to work on the website now. Let me know if it is a
> concern at any level.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> :
>
> > As in +1 for moving the project :-)
> >
> > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > +1
> > >
> > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
> > ivanjunc...@gmail.com>
> > > wrote:
> > >
> > >> I think last time I checked github for the website was not up to date.
> > >>
> > >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha 
> > >> wrote:
> > >>
> > >> > Well, TomEE already moved to git, you don't need to use SVN.
> > >> > PR integration already works fine, I saw that with last Jean-Louis's
> > >> merge.
> > >> >
> > >> > But yes, will be awesome to have it, we can use it like a stage and
> > the
> > >> > process to deploy in prod will be identical.
> > >> >
> > >> > +1 for that.
> > >> >
> > >> > On Tue, Jul 4, 2017 at 9:56 AM, Ivan Junckes Filho <
> > >> ivanjunc...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > This would be great, way better than doing svn patches.
> > >> > >
> > >> > > +1
> > >> > >
> > >> > > On Tue, Jul 4, 2017 at 9:54 AM, Romain Manni-Bucau <
> > >> > rmannibu...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Hi guys,
> > >> > > >
> > >> > > > I asked INFRA to proxy our new website project on github but it
> > >> looks
> > >> > > hard,
> > >> > > > they propose us to move the project to another git repo.
> > >> > > >
> > >> > > > Anyone against it?
> > >> > > >
> > >> > > > For reference here is the ticket:
> > >> > > > https://issues.apache.org/jira/browse/INFRA-14249
> > >> > > >
> > >> > > > Concretely we would get a git-asf/site-tomee-ng.git (or
> > equivalent)
> > >> and
> > >> > > > have a github proxy.
> > >> > > >
> > >> > > > In term of deployment it would still be the same, ie we copy the
> > >> output
> > >> > > to
> > >> > > > content/ of the cms subversion repo or we wire pubsub maven
> > plugin.
> > >> > > >
> > >> > > > Romain Manni-Bucau
> > >> > > > @rmannibucau  |  Blog
> > >> > > >  | Old Blog
> > >> > > >  | Github <
> https://github.com/
> > >> > > > rmannibucau> |
> > >> > > > LinkedIn  | JavaEE
> > Factory
> > >> > > > 
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Daniel Cunha
> > >> > https://twitter.com/dvlc_
> > >> >
> > >>
> > >
> > >
> >
>

Re: The EE8 Roadmap

[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  >:
> >
> > first step would probably be to create an incubator project to impl the
> spec
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 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  >:
> >>>
> >>> 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
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> > On Fri, Jun 2, 2017 at 8:55 PM, Romain Manni-Bucau <
>  rmannibu...@gmail.com>
> > wrote:
> >
> >> 2017-06-02 20:27 GMT+02:00 Mark Struberg  >:
> >>
> >>> Hi folks!
> >>>
> >>> Behind the scene there was a lot of work done towards EE8.
> >>> Not directly in TomEE, but in most parts which are needed
> >>>
> >>> * Tomcat 9 for Servlet 4.0 - While the final API is not yet ready
> we
> >>> already have many public Milestone builds
> >>>
> >>> * OpenWebBeans-2.0.x for CDI 2.0 - We already implemented most of
> the
>  new
> >>> features and are down to 35 failing TCK tests (out of 1300). Might
> >> take
> >> us
> >>> 2 more weeks to finish, but we are already very close
> >>>
> >>> * BVal - Matt Benson is working like wild for implementing the new
> >> spec
> >>> changes. Once OWB is finished Romain and I will join the effort
> with
>  more
> >>> power. Others are welcome to help of course!
> >>>
> >>> * Johnzon for JSON-P 1.1 and JSON-B 1.0: 1.1.1 is currently being
> >>> released. Works like a charm!
> >>>
> >>> * MyFaces - gonna need to check the latest status, but I think Leo
> >> has
> >>> already implemented most things
> >>>
> >>> * OpenJPA - lags a bit behind, but there have been no changes so
> far
> >> in
> >>> JPA for EE8 anyway
> >>>
> >>> * Geronimo - we have quite a few new spec versions to be released.
> >> Most
> >>> are already implemented and just need to get released once the
> specs
> >> go
> >>> final and we can compare our signatures with the ones from the
> >> official
> >>> artifacts.
> >>>
> >>>
> >>> How to name the baby? TomEE-8.0.0 seems quite natural to me, wdyt?
> >>>
> >>>
> >> Well no real choice we moved to 7 recently with this engagement for
> at
> >> least a moment.
> >>
> >>
> >>> When to branch away from trunk?
> >>>
> >>
> >> When at least OWB is fully ready I'd say and 7.0.4 out, can do it
> soon
>  if
> >> it helps
> >>
> >>
> >>> After OWB is finished?
> >>>
> >>>
> >> Hehe seems we agree ;)
> >>
> >>
> >>> C'mon, tell me what you think, lords and ladies!
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>>
> >>
> 
> 
> >>
> >>
>
>

Re: ClassNotFoundException: com.sun.el.ExpressionFactoryImpl in embedded Arquillian container

[John D. Ament]

Don't forget, TomEe will ship Geronimo jars.  If you reference Javax.el
you'll get duplicates

On Aug 23, 2016 17:25, "Alex Soto"  wrote:

> Then now I have no idea, it seems emedded instance does not contain the
> javax.el interpreter. Can you try using remote artifacts?
>
> El 23 ago. 2016 11:19 p. m., "Ivan St. Ivanov" 
> escribió:
>
> > Hey Alex :)
> >
> > I'm using the Arquillian Universe BOM Alpha 3. Downgraded to Alpha 2, but
> > getting the same exception.
> >
> > Cheers,
> > Ivan
> >
> > On Wed, Aug 24, 2016 at 12:15 AM, Alex Soto  wrote:
> >
> > > Are you using arquillian 1.1.11, if so try with .10
> > >
> > > El 23 ago. 2016 10:47 p. m., "Ivan St. Ivanov" <
> ivan.st.iva...@gmail.com
> > >
> > > escribió:
> > >
> > > > Hi folks,
> > > >
> > > > I have an issue when I run Arquillian test in the TomEE embedded
> > > > container, version 7.0.1. Originally I wanted to run a test as client
> > > > (@RunAsClient) that checks a RESTful web service's response [1].
> > However,
> > > > during the deployment of the ShrinkWrap archive I get the following
> > > > exception:
> > > >
> > > > javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not
> > > found
> > > > at javax.el.FactoryFinder.newInstance(FactoryFinder.java:101)
> > > > at javax.el.FactoryFinder.find(FactoryFinder.java:197)
> > > > at javax.el.ExpressionFactory.newInstance(ExpressionFactory.
> java:197)
> > > > at javax.el.ExpressionFactory.newInstance(ExpressionFactory.
> java:168)
> > > > at org.apache.jasper.runtime.JspApplicationContextImpl.(
> > > > JspApplicationContextImpl.java:46)
> > > > at org.apache.jasper.runtime.JspApplicationContextImpl.getInstance(
> > > > JspApplicationContextImpl.java:76)
> > > > at org.apache.jasper.runtime.JspFactoryImpl.
> getJspApplicationContext(
> > > > JspFactoryImpl.java:217)
> > > > at org.apache.openejb.cdi.OpenEJBLifecycle.setJspELFactory(
> > > > OpenEJBLifecycle.java:416)
> > > > at org.apache.openejb.cdi.OpenEJBLifecycle.initializeServletContext(
> > > > OpenEJBLifecycle.java:387)
> > > > at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(
> > > > TomcatWebAppBuilder.java:1423)
> > > >
> > > > The whole exception trace is attached to this emal.
> > > >
> > > > I wondered what the problem is, so I added a dummy resource [2] that
> > > > doesn't involve CDI. And then ran a test [3] as client and it went
> > fine.
> > > > Then I added a test that doesn't run as client and involves a class
> > that
> > > > uses CDI [4]. And I got the same exception as above.
> > > >
> > > > Do you know what is the reason for the failure? The same tests run
> > > > successfully on the WildFly 10 managed container. And they keep
> failing
> > > on
> > > > TomEE embedded even with an empty beans.xml added to the ShrinkWrap
> web
> > > > archive.
> > > >
> > > > The app under test is runnable under TomEE 7 Plume as well as via the
> > > > Maven plugin.
> > > >
> > > > Thank you,
> > > > Ivan
> > > >
> > > > [1] https://github.com/ivannov/javaee-actuator/blob/
> > > > arquillian/javaee-actuator/src/test/java/io/github/
> > > > ivannov/actuator/resources/MetricsResourceTest.java
> > > > [2] https://github.com/ivannov/javaee-actuator/blob/
> > > > arquillian/javaee-actuator/src/main/java/io/github/
> > > > ivannov/actuator/resources/HelloResource.java
> > > > [3] https://github.com/ivannov/javaee-actuator/blob/
> > > > arquillian/javaee-actuator/src/test/java/io/github/
> > > > ivannov/actuator/resources/HelloResourceTest.java
> > > > [4] https://github.com/ivannov/javaee-actuator/blob/
> > > > arquillian/javaee-actuator/src/test/java/io/github/
> > > > ivannov/actuator/resources/BeansResourceTest.java
> > > >
> > >
> >
>

Re: Exposing RESTful web services from WEB-INF/lib

[John D. Ament]

Looks like he has a master branch where that works properly.

John

On Sat, Jul 16, 2016 at 10:35 AM Alex Soto  wrote:

> At mobile now but have you tried adding classes in war project and see if
> they work and then extract to jar?
>
> El 16 jul. 2016 4:34 p. m., "Ivan St. Ivanov" 
> escribió:
>
> > Hi folks,
> >
> > I have the following case. I am developing a simple web application,
> which
> > is empty for the moment, but contains a jar that exposes RESTful web
> > services via JAX-RS. Here is the structure:
> >
> > - actuator.jar: contains class extending javax.ws.rs.core.Application as
> > well as a class annotated with @Path and containing a method annotated
> with
> > @GET
> > - actuator.war packages actuator.jar in WEB-INF/lib and apart from that
> is
> > empty
> >
> > The source code is here:
> > https://github.com/ivannov/javaee-actuator/tree/split
> >
> > I deployed this into TomEE 7.0.1 Plume and when I tried to access my
> > RESTful resource, I got 404. I don't see anything in the catalina log.
> And
> > these are the application deployment messages form the console:
> >
> > INFO - Enterprise application
> > "/opt/apache-tomee-plume-7.0.1/webapps/actuator" loaded.
> > INFO - Assembling app: /opt/apache-tomee-plume-7.0.1/webapps/actuator
> > INFO - Deployed
> > Application(path=/opt/apache-tomee-plume-7.0.1/webapps/actuator)
> > INFO - At least one JAR was scanned for TLDs yet contained no TLDs.
> Enable
> > debug logging for this logger for a complete list of JARs that were
> scanned
> > but no TLDs were found in them. Skipping unneeded JARs during scanning
> can
> > improve startup time and JSP compilation time.
> > INFO - Deployment of web application archive
> > /opt/apache-tomee-plume-7.0.1/webapps/actuator.war has finished in 1,808
> ms
> >
> > The same works fine in Wildfly 10. It works OK on TomEE as well when
> > actuator.jar is actually a war and deploy it directly.
> >
> > Do I have to do anything special in order to make resources packaged in
> > WEB-INF/lib discoverable in TomEE?
> >
> > Thanks,
> > Ivan
> >
>

Re: [VOTE] Apache TomEE 7.0.0

[John D. Ament]

On Fri, May 20, 2016 at 12:40 PM David Blevins 
wrote:

>
> > On May 19, 2016, at 11:27 PM, Romain Manni-Bucau 
> wrote:
> >
> > 2016-05-20 1:23 GMT+02:00 David Blevins :
> >
> >> Also, we’ve historically done a preview run in advance of an official
> vote
> >> for major releases:
> >>
> >>  [PREVIEW] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1034)
> >>  http://openejb.markmail.org/thread/jjiheacmtd4tb6qw
> >>
> >>  [preview] OpenEJB 4.6.0/TomEE 1.6.0 (staging-092)
> >>  http://markmail.org/message/u6ripoz3lsxvcron
> >>
> >>  1.0.0 preview binaries
> >>  http://markmail.org/message/f6ix44zeqlcaet3w
> >>
> >>  [preview] OpenEJB 4.5.1/TomEE 1.5.1 (staging-132)
> >>  http://markmail.org/message/l3rvltbc3az7xu65
> >>
> >> Binary comparison of this release to previous to help with LICENSE and
> >> NOTICE file updates:
> >>
> >>  1.0.0 - 1.5.0  http://openejb.markmail.org/thread/ppvkyeznaryjluve
> >>
> >>  1.5.0 - 1.5.1  http://markmail.org/message/pmwkycgdrz2php6n
> >>
> >>  1.5.1 - 1.6.0  http://openejb.markmail.org/thread/xwy56krafcxm3kgs
> >>
> >> And RAT scan:
> >>
> >> - http://markmail.org/message/fmj5kveiw6kwmq6d <
> >> http://markmail.org/message/fmj5kveiw6kwmq6d>
> >>
> >> Also preemptive note, despite that “72 hours” has been in all the vote
> >> threads, we’ve always left votes open longer to ensure everyone has
> time to
> >> give feedback.  So I’m hoping the response is not “you have 72 hours to
> do
> >> this” as they’ve historically been done by the release manager.
> >>
> >> Can we consider this a preview release and execute the diffs, rat
> reports
> >> and ensure our LICENSE and NOTICE files are up to date?  Or at the very
> >> least pause this vote till that stuff is done.
> >>
> >>
> > 6 months ago I would have said yes but since v7 is > 1 year old think we
> > got all the time to do all the fancy stuff we want and if not done in 1
> > year will likely not be done now so *personally* I don't accept any
> excuse
> > anymore to delay a release.
>
> Just an FYI that incorrect LICENSE and NOTICE files is a showstopper for
> any release and not subject to majority vote.
>

For a TLP, it definitely is.


>
> I’ve had to reroll countless releases because they were wrong, hence
> putting effort into those practices.
>
>
> -David
>
>
> >
> >
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On May 19, 2016, at 12:45 PM, David Blevins 
> >> wrote:
> >>>
> >>> Can you put up a proposed page for the download and I can give feedback
> >> on how it should be updated.  Let’s start another thread.
> >>>
> >>> I’m obviously very time constrained, but happy to give you time and
> work
> >> openly on it.
> >>>
> >>>
> >>> --
> >>> David Blevins
> >>> http://twitter.com/dblevins 
> >>> http://www.tomitribe.com
> >>>
>  On May 19, 2016, at 12:37 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >> > wrote:
> 
>  @David: http://tomee.apache.org/tomee-version-policies.html <
> >> http://tomee.apache.org/tomee-version-policies.html>, just added a
>  link on the download page
> http://tomee.apache.org/downloads.html.Think
> >>  the
>  information is there but don't hesitate to tune/customize/update the
>  website until you are fully happy with it.
> 
> 
>  Romain Manni-Bucau
>  @rmannibucau  >> https://twitter.com/rmannibucau>> |  Blog
>   >>
> >> | Github  https://github.com/rmannibucau>>
> >> |
>  LinkedIn  >> https://www.linkedin.com/in/rmannibucau>> | Tomitriber
>  > | JavaEE
> Factory
>   >> https://javaeefactory-rmannibucau.rhcloud.com/>>
> 
>  2016-05-19 21:03 GMT+02:00 David Blevins  >> >:
> 
> > Also the download page would need to be updated.  It currently says
> >> “Java
> > EE 6 compliant” and we would need to remove that and replace it with
> >> “NOT
> > Java EE 7 compliant”.  That text should be a link to an explanation
> of
> >> why
> > and an explanation of the version number.
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins 
> > http://www.tomitribe.com
> >
> >> On May 19, 2016, at 11:59 AM, David Blevins <
> david.blev...@gmail.com>
> > wrote:
> >>
> >> Where is the documentation page again?
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins 
> >> 

Re: 7.0.0 release vote

[John D. Ament]

I'm not sure if you're interpretting it as hibernate ORM is AL or not, but
ORM is LGPL.  OGM and search are also LGPL.  Bean validation is pretty much
the only ALv2 component.

On Mon, May 2, 2016 at 8:31 AM Andy Gumbrecht <agumbre...@tomitribe.com>
wrote:

> 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 <rmannibu...@gmail.com> wrote:
>
> > 2016-05-02 14:00 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:
> >
> > > 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 <radcor...@yahoo.com.invalid>
> > > wrote:
> > >
> > > > Some JAX-RS tests are using JPA 2.1 features which is not supported
> > yet.
> > > >   From: John D. Ament <johndam...@apache.org>
> > > >  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" <david.blev...@gmail.com> 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 <
> johndam...@apache.org
> > >
> > > > > 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:
> > >

Re: 7.0.0 release vote

[John D. Ament]

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" <david.blev...@gmail.com> 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 <johndam...@apache.org>
> 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:
> > >>>
> >
> 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 <ross.cohen...@gmail.com>
> > >>>> 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.
> > >>>>
> > >>>>
> >
> >
>

Re: 7.0.0 release vote

[John D. Ament]

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:
>> 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 <ross.cohen...@gmail.com>
>>> 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.
>>>
>>>

Re: 7.0.0 release vote

[John D. Ament]

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:
> 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 <ross.cohen...@gmail.com>
>> 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.
>>
>>

Re: 7.0.0 release vote

[John D. Ament]

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 
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.
>
>

Re: Next release 7.1?

[John D. Ament]

On Sun, Apr 24, 2016 at 6:59 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> Le 25 avr. 2016 00:36, "John D. Ament" <johndam...@apache.org> a écrit :
> >
> > It doesn't make sense to jump to a 7.1 immediately without even releasing
> a
> > 7.0.  Just confusing from a semantic versioning standpoint.
>
> Do you think releasing a version which changes structurally with the same
> minor is less confusing - was my fear ?
>

Maybe your fears aren't clear.  Granted I haven't tried tomcat 8.5.  Are
you saying that using Tomcat 8.5 causes TomEE to have a different directory
structure or something?  Or what structurally is the issue here? Its not
clear.


>
> >
> > Given the current status of the TCK & ASF, I wonder if waiting for it and
> > claiming EE 7 compatibility at a later date would make more sense.  So
> > maybe along what Dave's mentioning and favor a TomEE 2 that's focused on
> EE
> > 7 capabilities without stating that its EE7 compliant.
> >
>
> As mentionned 2.x would break tools - tomee ones which is ok but several
> externals including maven/ivy (gradle) based ones so I'm against it and
> prefer to confuse vs break.
>

How does it break maven/ivy/gradle?


>
> About doing a 7.0 with master:  if everyone wants I m happy to promote M3
> as final - we can disucss later if we backport or not things.
>
>
I think the part I don't understand is what benefit is there to release
TomEE ?? based on Tomcat 8.0 when 8.5 is coming out now.  Maybe the bigger
question is does it make sense to release TomEE 7 based on Tomcat 8.5?


> If everyone wants just to move on 7.0 I'm also happy with it but please ack
> we delete all the minor part with NO replacement of the page
> http://tomee.apache.org/tomee-version-policies.html - we never respects
> any
> mathematical logic for minors and cause of our stack I guess we'll never
> do.
>
> Excepted Alex everyone feedback was 7.0.
>
> @Alex: wyt about it?
>
> Anyone feeling something else before we use that?
>
> > John
> >
> > On Sun, Apr 24, 2016 at 6:05 PM David Blevins <david.blev...@gmail.com>
> > wrote:
> >
> > > On hijacking, I think your single sentence communicated a lot more in
> your
> > > head than was actually said :)  I beg your patience :)
> > >
> > > “Why not 7.0” or “What about 7.0” are fair questions.  But I see your
> goal
> > > a little clearer — some way to get a TomEE version of Tomcat 8.5 out
> the
> > > door.
> > >
> > > Let’s get some feedback.
> > >
> > >
> > > --
> > > David Blevins
> > > http://twitter.com/dblevins
> > > http://www.tomitribe.com
> > >
> > > > On Apr 24, 2016, at 2:29 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >
> > > wrote:
> > > >
> > > > We can do a 7.0 based on M3 and 7.1 (8.0 if you prefer) in the same
> vote.
> > > >
> > > > Basically I want master released whatever TCK status is and whatever
> > > > version it is while > 7.0 for toolings compliance ( 2.x and 3.x are
> no
> > > more
> > > > an  option IMO cause of that).
> > > >
> > > > Side note: speaking about 7.0 hijacks this thread which has as only
> > > topic:
> > > > how to get tomee http2 support out this month or next one.
> > > > Le 24 avr. 2016 23:23, "David Blevins" <david.blev...@gmail.com> a
> > > écrit :
> > > >
> > > >> I see and agree on not surprising people around a Tomcat 8.0 -> 8.5
> > > >> upgrade.
> > > >>
> > > >> I’m not seeing how discussing finishing 7.0 is highjacking.  I think
> > > >> people would find it quite confusing for us to move on to 7.1
> without
> > > >> actually doing a GA of 7.0
> > > >>
> > > >>
> > > >> -David
> > > >>
> > > >>
> > > >>> On Apr 24, 2016, at 2:11 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > >
> > > >> wrote:
> > > >>>
> > > >>> We can release a 7.0 based on M3 but not master - I dont care much
> for
> > > >> this
> > > >>> thread topic but feel free to open another thread on next 7.0.x if
> you
> > > >>> care/want. Master is on tomcat 8.5 since few weeks and I d like to
> > > >> release
> > > >>> it once this thread passed/is done - was planning to wait until
> > > 

Re: Next release 7.1?

[John D. Ament]

It doesn't make sense to jump to a 7.1 immediately without even releasing a
7.0.  Just confusing from a semantic versioning standpoint.

Given the current status of the TCK & ASF, I wonder if waiting for it and
claiming EE 7 compatibility at a later date would make more sense.  So
maybe along what Dave's mentioning and favor a TomEE 2 that's focused on EE
7 capabilities without stating that its EE7 compliant.

John

On Sun, Apr 24, 2016 at 6:05 PM David Blevins <david.blev...@gmail.com>
wrote:

> On hijacking, I think your single sentence communicated a lot more in your
> head than was actually said :)  I beg your patience :)
>
> “Why not 7.0” or “What about 7.0” are fair questions.  But I see your goal
> a little clearer — some way to get a TomEE version of Tomcat 8.5 out the
> door.
>
> Let’s get some feedback.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Apr 24, 2016, at 2:29 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> >
> > We can do a 7.0 based on M3 and 7.1 (8.0 if you prefer) in the same vote.
> >
> > Basically I want master released whatever TCK status is and whatever
> > version it is while > 7.0 for toolings compliance ( 2.x and 3.x are no
> more
> > an  option IMO cause of that).
> >
> > Side note: speaking about 7.0 hijacks this thread which has as only
> topic:
> > how to get tomee http2 support out this month or next one.
> > Le 24 avr. 2016 23:23, "David Blevins" <david.blev...@gmail.com> a
> écrit :
> >
> >> I see and agree on not surprising people around a Tomcat 8.0 -> 8.5
> >> upgrade.
> >>
> >> I’m not seeing how discussing finishing 7.0 is highjacking.  I think
> >> people would find it quite confusing for us to move on to 7.1 without
> >> actually doing a GA of 7.0
> >>
> >>
> >> -David
> >>
> >>
> >>> On Apr 24, 2016, at 2:11 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> >> wrote:
> >>>
> >>> We can release a 7.0 based on M3 but not master - I dont care much for
> >> this
> >>> thread topic but feel free to open another thread on next 7.0.x if you
> >>> care/want. Master is on tomcat 8.5 since few weeks and I d like to
> >> release
> >>> it once this thread passed/is done - was planning to wait until
> wednesday
> >>> and few more feedbacks - but to not make this important upgrade silent
> >> and
> >>> surprise users I d like to change the version more than a last digit.
> >>>
> >>> Then coming topics are:
> >>> - objection for a 7.1?
> >>> - what do we maintain? 1.7/7.1 - not only for the palimdrom beauty ;)?
> >>>
> >>> (Please dont hijack this thread commenting on these coming ones, just
> >> tried
> >>> to give a bit more visibility on the overall goal and why I asked about
> >> 7.x
> >>> versioning now)
> >>> Le 24 avr. 2016 23:04, "David Blevins" <david.blev...@gmail.com> a
> >> écrit :
> >>>
> >>>> Good thread.
> >>>>
> >>>> Recap of my understanding:  we release 7.0 as-is and move forward to
> 7.1
> >>>> based on Tomcat 8.5?
> >>>>
> >>>> I’d be +1 for that plan.
> >>>>
> >>>>
> >>>> -David
> >>>>
> >>>>> On Apr 23, 2016, at 2:17 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>>
> >>>> wrote:
> >>>>>
> >>>>> Hi guys
> >>>>>
> >>>>> Having tomcat 8.5 now I d like to move tomee to 7.1 to show coming
> >>>> release
> >>>>> is not just another 7.0.
> >>>>>
> >>>>> Any objection?
> >>>>
> >>>>
> >>
> >>
>
>

Re: Vote new committer: Daniel Cunha

[Alan D. Cabrera]

> On Nov 20, 2015, at 7:06 AM, Romain Manni-Bucau  wrote:
> 
> Not the way it is generally. Main point is suppose we say no...Daniel would
> leave the project where the no can also mean " let's see a bit more".
> 
> That said such demand generally has some notable contribution on the
> project to promote the candidate to help evaluating the guy - we all know
> Daniel I guess so it is just a "for next round" comment.
> 
> @pmc: do we keep it there or do we move it to private to stay formal?

Private please.  How else can I complain about his lack of color coordination 
without hurting his feelings?


Regards,
Alan

Re: Protocol of Arquillian Embedded Adapter

[John D. Ament]

The fundamental problem (if I had to guess) is that let's say I'm testing a
REST API (heck even using the REST extension), persistence extension
doesn't know that my request went through since I'm controlling it, so its
call backs won't take effect.  By running embedded, you're more likely to
not be inside the same transaction, which is one of the things being banked
on I'm sure.

John

On Mon, Oct 5, 2015 at 3:26 AM Alex Soto <asot...@gmail.com> wrote:

> If there are bugs/improvements let s do it. I am thinking in terms of doing
> the life of developers easier and in fact changing the protocol to servlet
> dos not introduce (a priori) any back incompatibility but a lot of
> extensions are going to work with embedded mode.
>
> Alex.
>
> El dg, 4 oct 2015 a les 7:53 Romain Manni-Bucau <rmannibu...@gmail.com> va
> escriure:
>
> > Hi Alex
> >
> > Local protocol allows nicer start so very tempted to keep it like that.
> > Servlet protocol has few bugs/issues and is not what you target by
> default
> > with embedded adapters IMO.
> > Le 4 oct. 2015 01:25, "John D. Ament" <johndam...@apache.org> a écrit :
> >
> > > Hey Alex,
> > >
> > > To be honest, I find the protocol section of arquillian the most
> > confusing
> > > for new users to pick up.  Why should they care what the protocol
> > > transferring the test data is using?  I remember at the beginning, AS7
> > had
> > > a JMX protocol.  This made tons of sense, since it didn't impact the
> > > running application.  No one understood why their tests stopped work
> > > though!  Truth be told, the fact that most people end up relying on
> > > servlet, without even realizing that its the arquillian runtime
> starting
> > an
> > > HTTP request makes it confusing to understand scope.  Basically, users
> > end
> > > up relying on the servlet protocol to start their HTTP request for
> them,
> > > instead of starting an HTTP request for their test invocation.
> > >
> > > Just curious, is this out on discourse somewhere? I can continue my
> whine
> > > fest there :-)
> > >
> > > John
> > >
> > > On Sat, Oct 3, 2015 at 4:58 PM Alex Soto <asot...@gmail.com> wrote:
> > >
> > > > Hello mates,
> > > >
> > > > I send this email to start a discussion for a change on TomEE
> > Arquillian
> > > > Adapter.
> > > >
> > > > The other day, because of the book (Arquillian In Action), I checked
> > the
> > > > protocol used by different adapters. I noticed that only Weld adapter
> > and
> > > > TomEE embedded adapter are using the local protocol,all other ones
> are
> > > > using the Servlet 3.0 protocol. And maybe you are asking why this is
> > > > important? Well the problem is that a lot of extensions requires this
> > > > protocol to work, for example Arquillian Persistence extension or
> > > Arquillan
> > > > Warp extension. In case a user wants to use  embedded TomEE and one
> > > > extension that requires servlet protocol, it would get a cryptic
> > > exception.
> > > > Of course there is a workaround and it is overriding the default
> > protocol
> > > > by using protocol special tag in arquillian.xml and adding the
> > > > servlet-protocol dependency.
> > > >
> > > > I think that it would be easier for everyone if all adapters works in
> > the
> > > > same way. With the release of TomEE 7 I think it could be a good
> > > > opportunity to make this change in the Arquillian embedded adapter as
> > > well
> > > > and align with the rest of the containers.
> > > >
> > > > The change to be done is very simple in terms of code (Adding one
> > > > dependency and change one String of the adapter).
> > > >
> > > > What do you think? From the point of view of Arquillian community it
> > > would
> > > > be the logic step.
> > > >
> > > > Alex.
> > > >
> > >
> >
>

Re: Protocol of Arquillian Embedded Adapter

[John D. Ament]

Hey Alex,

To be honest, I find the protocol section of arquillian the most confusing
for new users to pick up.  Why should they care what the protocol
transferring the test data is using?  I remember at the beginning, AS7 had
a JMX protocol.  This made tons of sense, since it didn't impact the
running application.  No one understood why their tests stopped work
though!  Truth be told, the fact that most people end up relying on
servlet, without even realizing that its the arquillian runtime starting an
HTTP request makes it confusing to understand scope.  Basically, users end
up relying on the servlet protocol to start their HTTP request for them,
instead of starting an HTTP request for their test invocation.

Just curious, is this out on discourse somewhere? I can continue my whine
fest there :-)

John

On Sat, Oct 3, 2015 at 4:58 PM Alex Soto  wrote:

> Hello mates,
>
> I send this email to start a discussion for a change on TomEE Arquillian
> Adapter.
>
> The other day, because of the book (Arquillian In Action), I checked the
> protocol used by different adapters. I noticed that only Weld adapter and
> TomEE embedded adapter are using the local protocol,all other ones are
> using the Servlet 3.0 protocol. And maybe you are asking why this is
> important? Well the problem is that a lot of extensions requires this
> protocol to work, for example Arquillian Persistence extension or Arquillan
> Warp extension. In case a user wants to use  embedded TomEE and one
> extension that requires servlet protocol, it would get a cryptic exception.
> Of course there is a workaround and it is overriding the default protocol
> by using protocol special tag in arquillian.xml and adding the
> servlet-protocol dependency.
>
> I think that it would be easier for everyone if all adapters works in the
> same way. With the release of TomEE 7 I think it could be a good
> opportunity to make this change in the Arquillian embedded adapter as well
> and align with the rest of the containers.
>
> The change to be done is very simple in terms of code (Adding one
> dependency and change one String of the adapter).
>
> What do you think? From the point of view of Arquillian community it would
> be the logic step.
>
> Alex.
>

Re: [discuss] drop drop-in-war

[John D. Ament]

David,


On Tue, May 19, 2015 at 6:29 PM David Blevins david.blev...@gmail.com
wrote:

 What do people think about dropping the drop-in-war feature in .next?

 It has had two use cases:

  - allow users to use their own tomcat version and just add TomEE

  - allow users to use TomEE in situations where they don't have access to
 modify the server (cloud)


I'm assuming you mean PaaS here, right?



 It seems we can do the first case better with the TomEE maven plugin
 (certainly a possibility if not already there).

 The second seems less needed these days. Jelastic has first class support
 for TomEE in their cloud. Others should learn from them.

 Thoughts?

 -David



 --
 Sent from my iPhone

Re: what is which branch up for?

[Alan D. Cabrera]

 On Jan 29, 2015, at 10:28 PM, Mark Struberg strub...@yahoo.de wrote:
 
 Hi Alan!
 
 Where do you see that?  I keep reading that Atlasssian document and I don’t 
 see
 where it requires cherry picking each and every commit.
 
 
 You have a master branch and a development branch. All work happens on the 
 development branch but releases happen from master branch, right? So how do 
 all the commits end up on the master branch? Someone has to pick the 'good' 
 ones from the development branch over to the master branch. Especially when a 
 release comes near.

Well, I do agree that’s cumbersome and error prone but I thought that the 
master was *merged* from a release branch.

 Can you point me to the parts that justify your allegations?
 
 My 'musts' listed below are not from gitflow. Those are requirements we do 
 have as ASF project. As an ASF project we are required to maintain a clean 
 code provenance and a immutable project source history. This means we must 
 not do any history rewrite of stuff which already hit the ASF repo (of course 
 a local! rebase or your own work which you did not push to some ASF repo is 
 perfectly fine).
 
 So we should really disable history rewrite on our cannonical ASF git repo.
 
 As to my argument about branch deletes. Gitflow requires that you create an 
 own branch for every feature someone does. But that would have us end up with 
 400++ branches pretty soon. I guess you see that this is not really easy to 
 maintain. Of course after a feature got merged in to some 'upstream' branch 
 then we can delete this feature branch technically. But the problem is that 
 it's really easy to trash a GIT repo with branch deletes. And there is no way 
 back other than a full file restore from a backup. 
 
 What people don't get most of the time:
 
 A delete of a branch in SVN is really just an additional commit which sets a 
 'deleted' flag. So you can always do an undelete in SVN. But that's not the 
 way it works with GIT. If you delete a branch in GIT then it is gone. 
 Especially if there was a git-prune or git-gc scheduled afterwards.
 
 So I'd rather forbid all history rewrite (including deletess) on our repos 
 and do experimental stuff on a different repo (either an own sandbox repo at 
 ASF or on github).

Thanks for providing detail.  I agree that if a feature branch is worked on by 
more than one person it probably shouldn’t be deleted; I think it’s more likely 
s/shouldn’t/must not/.  But that’s a problem w/ git.  It’s too bad that there 
can’t be two repos per project, one is for feature development and the other is 
for official releases.

I don’t see the requirement to squash commits in GitFlow.

Thanks for taking the time to bring me up to speed.  Frankly, I didn’t have the 
bandwidth to keep up w/ the initial git discussions.  Is there an ASF position 
document on git usage?

With that said, I haven’t been doing a lot of development here lately and so 
I’ve been reticent on the issue with the exception being where there are gaps 
in my understanding of things.  But, I do want to make one very important 
observation.

The Apache Way” is not a set of rules.  The Apache Way is community over code. 
 That’s it.  Nothing else.

The biggest aspect of that is treating your colleagues on this project with 
respect and not trying to bully others to get your way.  Take a personal pause 
on this thread and redouble your efforts to attain your goal while realizing 
that since this is not a technical issue you will need to garner the consensus 
of your colleagues. Using expletives and couching accusations of development 
immaturity will only cause others to “circle the wagons”, making for yet 
another interminable thread that I have to slog through.

We have probably one of the best developer groups on this project in the planet 
here.  They are smart, articulate, and will listen to calm, respectful, 
reasoning.


Regards,
Alan

Re: what is which branch up for?

[Alan D. Cabrera]

 On Jan 28, 2015, at 11:48 PM, Mark Struberg strub...@yahoo.de wrote:
 
 Alan, the gitflow way is basically review then commit. Because the 'Release 
 Manager' (of whom we lack...) needs to review and choose (cherry-pick) EACH 
 AND EVERY SINGLE COMMIT.

Where do you see that?  I keep reading that Atlasssian document and I don’t see 
where it requires cherry picking each and every commit.

 And even worse - by deleting the 'temp' branch afterwards we also loose all 
 the other work later.
 
 And once again: 
 
 We must not delete anything from our repos! 
 
 We must not squash commits!
 
 We must not loose any history!
 We must guarantee a verifyable code provenance!
 
 Those are no 'should' those are MUST!

You guys must be reading something different than I am or I am accidentally 
skimming over some critical bit:

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow 
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Can you point me to the parts that justify your allegations?


Regards,
Alan

Re: what is which branch up for?

[Alan D. Cabrera]

 On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:
 
 well it is by design opposed to apache way since if it is used it is
 to have the ability to change commit history - if not it is really
 useless.

I’m sure that I’m being dense but how is this form of branch management not the 
apache way?


Regards,
Alan

Re: useless branches and branch deletes at asf git repos

[Alan D. Cabrera]

Ahh, ok, your warnings did seem overly broad to me.

How is that enforced on ASF infrastructure?  Is it by an “honor system” that we 
assume no history rewrites are taking place?


Regards,
Alan


 On Jan 28, 2015, at 10:12 AM, Mark Struberg strub...@yahoo.de wrote:
 
 Deleting those is fine. But we must make sure that no essential commit gets 
 lost. And this is only doable by totally forbidding history rewrite on the 
 repo.
 
 LieGrue,
 strub
 
 
 
 
 
 On Wednesday, 28 January 2015, 18:27, Alan Cabrera l...@toolazydogs.com 
 wrote:
 Deleting committed changes is definitely bad. Deleting branches that 
 ultimately 
 participate in the release is also bad.
 
 However, deleting tags for failed releases is fine as is deleting a 
 branch that never transitively participated in a release should be fine as 
 well.
 
 Do I misunderstand something?  Is there some infrastructure limitation?
 
 Sent from my iPhone
 
 
 On Jan 28, 2015, at 6:07 AM, Mark Struberg strub...@yahoo.de wrote:
 
 Hi folks!
 
 I've found another thing which is ugly
 
 release-tomee-1.7.2 and
 tomee-1.7.2 branches which are actually just leftovers it seems?
 
 
 Please be aware that we MUST NOT DELETE anything at ASF repos! We must not 
 do history rewrite!
 
 So think REALLY hard before creating branches which are just utter garbage. 
 In git you just cannot get rid of them that easily. They get mirrored 
 downstream 
 automatically and we have no whatever control about them anymore!
 
 Please read how we handle GIT over at DeltaSpike. 
 
 We e.g. release with localCheckout=true and pushChanges=false. 
 
 
 Just ping me if I need to go into details.
 
 LieGrue,
 strub
 

Re: [VOTE] TomEE 1.7.2/OpenEJB 4.7.2 (staging-1045)

[Alan D. Cabrera]

openejb-4.7.2 does not build for me

[INFO] Using Groovy-Eclipse compiler to compile both Java and Groovy files
org.codehaus.groovy.control.messages.SyntaxErrorMessage@22a80e24
/home/acabrera/dev/tomee/examples/groovy-spock/src/test/java/org/superbiz/groovy/HelloSpecification.groovy:
 21 Groovy:unable to resolve class org.jboss.arquillian.spock.ArquillianSputnik
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/home/acabrera/dev/tomee/examples/groovy-spock/src/test/java/org/superbiz/groovy/HelloSpecification.groovy:[21,35]
 1. ERROR in 
/home/acabrera/dev/tomee/examples/groovy-spock/src/test/java/org/superbiz/groovy/HelloSpecification.groovy
 (at line 21)
import org.jboss.arquillian.spock.ArquillianSputnik
  ^
Groovy:unable to resolve class org.jboss.arquillian.spock.ArquillianSputnik

[ERROR] 
/home/acabrera/dev/tomee/examples/groovy-spock/src/test/java/org/superbiz/groovy/HelloSpecification.groovy:[33,10]
 2. ERROR in 
/home/acabrera/dev/tomee/examples/groovy-spock/src/test/java/org/superbiz/groovy/HelloSpecification.groovy
 (at line 33)
@RunWith(ArquillianSputnik.class)
 
ClassArquillianSputnik cannot be resolved to a type

[ERROR] Found 2 errors and 0 warnings.

 On Jan 24, 2015, at 1:20 PM, Jonathan Gallimore 
 jonathan.gallim...@gmail.com wrote:
 
 Hi
 
 Apologies for the delay in getting this vote started - I had a few issues
 getting the artifacts to the Nexus repository. Everything is there now, so
 hopefully we good to go. Here are the details:
 
 GIT Tag:
 https://git-wip-us.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/openejb-4.7.2
 
 Maven Repo: https://dist.apache.org/repos/dist/dev/tomee/staging-1045/
 
 Binaries  Source:
 https://dist.apache.org/repos/dist/dev/tomee/staging-1045/tomee-1.7.2
 
 Legal: http://tomee.staging.apache.org/legal-tomee-1.7.2/archives.html
 
 Vote will be open for 72 hours or as needed.
 
 Many thanks
 
 Jon

Re: git workflow?

[John D. Ament]

I personally like the idea of using gitflow, makes the project look more
stable and quality focused.  Allows you to stay in a shape of ready to
tackle major issues immediately.  Plus it makes contributions easier to
manage.

On Fri, Oct 17, 2014 at 7:25 AM, Andy Gumbrecht agumbre...@tomitribe.com
wrote:

 +1

 The issue here really is that this discussion was due once the staging
 site was in place, not before it. Never mind, we'll just have to see how it
 works out.

 On 17/10/2014 13:16, Christofer Dutz wrote:

 Just my 50ct to this topic:

 At the Apache Flex project we too introduced GitFlow (even if we never
 explicitly called it that way)
 Working on Develop and having Master in the state of the last release is
 a very good thing to have (in my opinion). this way someone can always
 start with a working build as Develop usually tends to be buggy now and
 then.

 I don’t quite understand why you claim that a merge from develop to
 master after a release adds another day to the process … no commit should
 to to master and therefore there shouldn’t be any conflicts. So a merge
 should be a on-command thing in Git.

 Also one thing with the feature branches. In flex some people tend to
 start working on something together. So they start a feature-branch and
 work  on that … as soon as that’s finished they might decide to give it up
 or to merge the stuff back to develop. This way their experiments don’t
 interfere with any other people.

 I think it’s a good thing.

 Chris

 --

 Mit freundlichen Grüßen | Best regards

 Christofer Dutz | Senior IT Consultant

 codecentric AG | An der Welle 4 | 60322 Frankfurt am Main | Deutschland
 mobil: +49 (0) 1525.3057806 | fax: +49 (0) 69.7593-8200
 www.codecentric.de http://www.codecentric.de/ | blog.codecentric.de 
 http://blog.codecentric.de/ | www.meettheexperts.de 
 http://www.meettheexperts.de/ | www.more4fi.de http://www.more4fi.de/


 Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
 Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
 Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
 Schütz

 Diese E-Mail einschließlich evtl. beigefügter Dateien enthält
 vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht
 der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
 informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail und
 evtl. beigefügter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder
 Öffnen evtl. beigefügter Dateien sowie die unbefugte Weitergabe dieser
 E-Mail ist nicht gestattet.

 Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau rmannibu...@gmail.com
 mailto:rmannibu...@gmail.com:

  Hi guys,

 just browsed the git workflow Andy wrote
 (http://tomee.staging.apache.org/dev/source-code.html) and I have a
 few question:
 1) (more a surprise than anything else) we don't discuss it?
 2) I find it overcomplicated - this develop branch thing. Today we are
 not big enough to need it IMHO and we are agile enough to change when
 we'll need this. It is great if we would like to rewrite the history
 but we are open source and I think it is important to not do it.
 3) if we really use it it means release preparation will take one
 extra day - to not say a week - to merge properly from develop to
 master but I don't see the gain
 4) ds doesn't use it and project goes well so what do we expect? -
 https://deltaspike.apache.org/suggested-git-workflows.html

 any inputs?


 Romain Manni-Bucau
 @rmannibucau
 http://www.tomitribe.com
 http://rmannibucau.wordpress.com
 https://github.com/rmannibucau




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

Re: Github pull requests?

[John D. Ament]

Here's hoping that one day the TomEE moves to Git.

On Wed, Oct 8, 2014 at 10:31 AM, Tommy Tynjä to...@diabol.se wrote:

 Your pull request will most likely be ignored. I've tried that approach as
 well but since TomEE has not moved over from svn to git, it doesn't make
 sense yet.

 I've used the git svn mirror to check out the code and keep it updated.
 When submitting contributions I've created a corresponding svn patch for
 the change set which I've then attached to the associated JIRA issue for
 any of the committers to evaluate and to commit.

 Best regards,
 Tommy Tynjä


 On Mon, Sep 29, 2014 at 1:46 PM, Chris Christo _...@mail.com wrote:

  Can anyone confirm please?
 
  Chris Christo
  { github.com/christchristo }
 
  On 18 Sep 2014, at 15:18, Chris Christo _...@mail.com wrote:
 
   On that note, will my pull request be ignored for now? Shall I re
 submit
  with a linked JIRA?
  
   On 28 Aug 2014, at 15:42, Andy Gumbrecht andy...@gmx.de wrote:
  
   Until we are actually a Git based project (
  https://git-wip-us.apache.org/repos/asf) rather than an SVN one we'll
  have issues.
  
   At the moment it's a Git mirror of SVN, which makes working with it
  'unusual'. Not something we should promote, especially if we are about to
  change to Git.
  
   Any changes 'should' have a JIRA - Doesn't always happen, but it is
  good practice - Would actually be nice to be able to enforce this.
  
   The best way to get noticed is still to create a JIRA and attach a
  patch - This forces the submitter to accept the Apache Software
 Foundation
  contributor license (which I don't see with Git currently).
  
   We shouldn't apply pull requests without knowing if the contributor
 has
  acknowledged the ASF license.
  
   Andy.
  
   On 27/08/2014 17:30, Thiago Veronezi wrote:
   Yeah... It looks like the github notifications need to be approved to
  be
   published in the dev list.
  
   []s,
   Thiago.
  
  
   On Wed, Aug 27, 2014 at 11:26 AM, Romain Manni-Bucau 
  rmannibu...@gmail.com
   wrote:
  
   just got the notification. Well not linking it to a jira means it
 will
   not be linked to a release AFAIK
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-08-27 17:21 GMT+02:00 Chris Christo _...@mail.com:
   Why do I need a JIRA name in the commit message? Is that the
  guidelines
   you guys require for every commit? I imagine the owners of the
 github
  repo
   would be watching it, and thus would receive notifications.
  
   Chris Christo
   { twitter.com/christokios }
   { github.com/christokios }
  
   On 27 Aug 2014, at 23:16, Thiago Veronezi thi...@veronezi.org
  wrote:
  
   Ah! I just saw it. It was filtered by my email client!
  
   []s,
   Thiago.
  
  
  
  
   On Wed, Aug 27, 2014 at 11:09 AM, Romain Manni-Bucau 
   rmannibu...@gmail.com
   wrote:
  
   * link = put jira name in the commit message
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-08-27 17:09 GMT+02:00 Romain Manni-Bucau 
  rmannibu...@gmail.com:
   did you linked it to a jira? otherwise I think we don't have any
   notification
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-08-27 17:06 GMT+02:00 helio frota 00h...@gmail.com:
   Its only a readme, but was testing the waters to see if anyone
  is
   actively handling pull requests, before I submit something 
 more
   substantial.
  
   Chris Christo +1
  
  
  
  
  
   On Wed, Aug 27, 2014 at 11:22 AM, Chris Christo _...@mail.com
 
   wrote:
   I submitted a pull request, just wondering if anyone will pick
  this
   up?
   Its only a readme, but was testing the waters to see if anyone
  is
   actively
   handling pull requests, before I submit something more
  substantial.
  
   Chris Christo
   { twitter.com/christokios }
   { github.com/christokios }
  
   On 25 Aug 2014, at 20:06, Romain Manni-Bucau 
  rmannibu...@gmail.com
   wrote:
  
   cause our main repo is not github and nobody was using github
  so
   README.adoc was not that useful ;)
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-08-25 13:55 GMT+02:00 Chris Christo _...@mail.com:
   Cool! Any reason why there’s no README.md at root? Can I add
  one
   (at
   least just to assure pull requests are all good)?
  
   Chris Christo
   { twitter.com/christokios }
   { github.com/christokios }
  
   On 25 Aug 2014, at 19:52, Romain Manni-Bucau 
   rmannibu...@gmail.com
   wrote:
   Hi
  
   it should be wired now
  
  
 

Re: [VOTE] OpenEJB 4.7.1/TomEE 1.7.1 (staging-1041)

[Alan D. Cabrera]

+1


Regards,
Alan

On Sep 12, 2014, at 3:01 PM, Andy Gumbrecht agumbre...@tomitribe.com wrote:

 SVN Tag:
 
 https://svn.apache.org/repos/asf/tomee/tomee/tags/tomee-1.7.1/
 
 Maven Repo:
 
 https://repository.apache.org/content/repositories/orgapachetomee-1041
 
 Binaries  Source:
 
 https://dist.apache.org/repos/dist/dev/tomee/staging-1041/tomee-1.7.1/
 
 Legal:
 
 No changes
 
 Vote will be open for 72 hours or as needed.
 
 Andy.
 
 -- 
  Andy Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com
 

What is the LIBRARIES file for?

[Alan D. Cabrera]

Just wondering.


Regards,
Alan

Re: [VOTE] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1039)

[Alan D. Cabrera]

On Aug 11, 2014, at 2:36 PM, dsh daniel.hais...@gmail.com wrote:

 Hi Alan,
 
 what is the exact error? Maybe it can be fixed easily. I once asked the
 INFRA team whether we could get an OSX builtbot so such issues could be
 determined ahead of time. I could try to open a JIRA for that if we say
 that we want regression testing on OSX too.
 
 Normally we would need buildbot setups for at least the Oracle and IBM JDK
 I'd say and Windoze, Linux and OSX.


---
Test set: org.apache.openejb.timer.QuartzPersistenceForEJBTimersTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.675 sec  
FAILURE! - in org.apache.openejb.timer.QuartzPersistenceForEJBTimersTest
doTest(org.apache.openejb.timer.QuartzPersistenceForEJBTimersTest)  Time 
elapsed: 5.533 sec   ERROR!
org.apache.openejb.OpenEJBException: Creating application failed: 
/Users/acabrera/x/tomee-1.7.0/container/openejb-core/target/QuartzPersistenceForEJBTimersTest:
 Error starting 'MyTimedEjb'.  Exception: class 
java.lang.IllegalStateException: Cannot run without an instance id.: Cannot run 
without an instance id.
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:896)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:623)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:619)
at 
org.apache.openejb.testing.ApplicationComposers.before(ApplicationComposers.java:705)
at 
org.apache.openejb.testing.ApplicationComposers.evaluate(ApplicationComposers.java:794)
at 
org.apache.openejb.junit.DeployApplication.evaluate(DeployApplication.java:40)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: org.apache.openejb.OpenEJBException: Error starting 'MyTimedEjb'.  
Exception: class java.lang.IllegalStateException: Cannot run without an 
instance id.: Cannot run without an instance id.
at 
org.apache.openejb.assembler.classic.Assembler.startEjbs(Assembler.java:1174)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:807)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:623)
at 
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:619)
at 
org.apache.openejb.testing.ApplicationComposers.before(ApplicationComposers.java:705)
at 
org.apache.openejb.testing.ApplicationComposers.evaluate(ApplicationComposers.java:794)
at 
org.apache.openejb.junit.DeployApplication.evaluate(DeployApplication.java:40)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at 

Re: [VOTE] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1039)

[Alan D. Cabrera]

I think that I’m suffering from deja vu, realistically dementia; I think that 
I’ve asked this question before.  Do we care if the tagged source cannot build 
under Mac OS X?


Regards,
Alan

On Aug 10, 2014, at 4:24 PM, Andy Gumbrecht agumbre...@tomitribe.com wrote:

 Hi Everyone,
 
 What's changed:
 
 Using Apache Tomcat 7.0.55 - TCK and Buildbot pass.
 Removed Mozilla Public License for Javassist.
 Fixed tomee-webapp phase so that webjar is included.
 Fixed Junit dependency requirement when -Phibernate is specified.
 Add a missing license file.
 
 http://www.apache.org/dist/openejb/KEYS
 
 SVN Tag:
 
 https://svn.apache.org/repos/asf/tomee/tomee/tags/tomee-1.7.0/
 
 Maven Repo:
 
 https://repository.apache.org/content/repositories/orgapachetomee-1039
 
 Binaries  Source:
 
 https://dist.apache.org/repos/dist/dev/tomee/staging-1039/tomee-1.7.0/
 
 Legal:
 
 http://tomee.staging.apache.org/legal/archives.html
 
 Vote will be open for 72 hours or as needed.
 
 Andy.
 
 -- 
  Andy Gumbrecht
 
  http://www.tomitribe.com
  agumbre...@tomitribe.com
  https://twitter.com/AndyGeeDe
 
  TomEE treibt Tomitribe! | http://tomee.apache.org
 

Re: [VOTE] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1038)

[Alan D. Cabrera]

Why did you have to cancel?

On Aug 9, 2014, at 3:31 PM, agumbrecht agumbre...@tomitribe.com wrote:

 Had to cancel, will do a detailed vote the next round.
 
 Andy.
 
 
 
 -
-- 
Andy Gumbrecht
 
http://www.tomitribe.com
agumbre...@tomitribe.com
https://twitter.com/AndyGeeDe
 
TomEE treibt Tomitribe ! | http://tomee.apache.org
 --
 View this message in context: 
 http://tomee-openejb.979440.n4.nabble.com/VOTE-OpenEJB-4-7-0-TomEE-1-7-0-staging-1038-tp4670945p4670962.html
 Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: [VOTE] OpenEJB 4.7.0/TomEE 1.7.0 (staging-1038)

[Alan D. Cabrera]

nm, http://www.apache.org/dist/openejb/KEYS.

+1


Regards,
Alan

On Aug 9, 2014, at 3:07 PM, Alan D. Cabrera l...@toolazydogs.com wrote:

 Can spmeone remind me where is our KEYS file?  Thanks!
 
 
 Regards,
 Alan
 
 On Aug 9, 2014, at 2:44 AM, Andy Gumbrecht agumbre...@tomitribe.com wrote:
 
 Hi Everyone,
 
 Round two vote:
 
 SVN Tag:
 
 https://svn.apache.org/repos/asf/tomee/tomee/tags/tomee-1.7.0/
 
 Maven Repo:
 
 https://repository.apache.org/content/repositories/orgapachetomee-1038
 
 Binaries  Source:
 
 https://dist.apache.org/repos/dist/dev/tomee/staging-1038/tomee-1.7.0/
 
 Legal:
 
 http://tomee.staging.apache.org/legal/archives.html
 
 Vote will be open for 72 hours or as needed.
 
 -- 
 Andy Gumbrecht
 
 http://www.tomitribe.com
 agumbre...@tomitribe.com
 https://twitter.com/AndyGeeDe
 
 TomEE treibt Tomitribe! | http://tomee.apache.org
 
 

Re: [VOTE] TomEE 1.6.0 / OpenEJB 4.6.0 (staging-147)

[Alan D. Cabrera]

There seems to be a number of license failures after I run

ant -f rat.xml scan


On Nov 17, 2013, at 2:16 AM, David Blevins david.blev...@gmail.com wrote:

 Ok, TCK clean so far.
 
 Maven Repo:
 
 - https://repository.apache.org/content/repositories/orgapachetomee-147/
 
 Binaries:
 
 - https://dist.apache.org/repos/dist/dev/tomee/staging-147/tomee-1.6.0/
 
 Tag:
 
 - https://svn.apache.org/repos/asf/tomee/tomee/tags/tomee-1.6.0/
 
 
 The vote will go for 72 hours.  This one should be fairly easy as the 
 binaries are effectively the same.  Will attempt to do a little binary diff 
 work later today to save everyone the trouble of having to re-evaluate the 
 full set of binaries from scratch.
 
 
 -David