Re: Classpath discovery in REST annotations with virtual classpath

Ok I see - Is that modification is in your roadMap? Or can you guide me to propose this ? - m2e-webby is in eclipse, do you think use tomee:embedded maven goal in eclipse to ? Or you think use in other part ? -- View this message in context: http://tomee-openejb.979440.n4.nabble.com/Classpath

Re: Classpath discovery in REST annotations with virtual classpath

2014-10-17 9:01 GMT+02:00 tcollignon : > Ok I see > > - Is that modification is in your roadMap? Or can you guide me to propose > this ? Before you ask it was not under the radar. If you want to try a fix it should be easy, here the pointers. We extract the info from http://svn.apache.org/repos/as

Re: Classpath discovery in REST annotations with virtual classpath

Ok I will try a modification if I can. Thanks a lot -- View this message in context: http://tomee-openejb.979440.n4.nabble.com/Classpath-discovery-in-REST-annotations-with-virtual-classpath-tp4672309p4672370.html Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Migration to GIT

Andy, Not forget to update the Web page. http://tomee.apache.org/dev/source-code.html Thanks. ^^ -- Daniel Cunha (soro) Blog: http://www.danielsoro.com.br Twitter: https://twitter.com/dvlc_ GitHub: https://github.com/danielsoro LinkedIn: http://www.linkedin.com/in/daniel

git workflow?

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

Re: Migration to GIT

Now why would I forget that? On 17/10/2014 12:34, Daniel Cunha wrote: Andy, Not forget to update the Web page. http://tomee.apache.org/dev/source-code.html Thanks. ^^

Re: git workflow?

Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau: > 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 deve

Re: git workflow?

Explain where the extra week is required? Also, someone just went an released the git repository without discussing it or letting others check it or waiting for the docs and buildbot etc? This was not the plan - The plan was to put everything in place and fire off a discussion on staging and

Re: git workflow?

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

Re: git workflow?

+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

Re: Migration to GIT

Hi Andy, I saw the webpage and didn't see the new repository. I thought that might have forgotten. Sorry. :) -- Daniel Cunha (soro) Blog: http://www.danielsoro.com.br Twitter: https://twitter.com/dvlc_ GitHub: https://github.com/danielsoro LinkedIn: http://www.linkedin.c

Re: Migration to GIT

Just kidding :-P . I had it in staging already ...you can always see what's coming here: http://tomee.staging.apache.org Andy. On 17/10/2014 13:25, Daniel Cunha wrote: Hi Andy, I saw the webpage and didn't see the new repository. I thought that might have forgotten. Sorry. :) -- Andy Gu

Re: git workflow?

we'll see but I don't get any reason for it: 1) master is in the state of last release: so start from the tag to develop if that's what you want. In most case merges will be an issue (at least for tomee) if you really do it. 2) the extra work is cause you do it when releasing and then you need to m

Re: git workflow?

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 wrote: > +1 > > The issu

Re: Migration to GIT

Great, added in my favorites. Thank you very much Andy. :) -- Daniel Cunha (soro) Blog: http://www.danielsoro.com.br Twitter: https://twitter.com/dvlc_ GitHub: https://github.com/danielsoro LinkedIn: http://www.linkedin.com/in/danielvlcunha Sent from my cell phone Em 17/1

Re: git workflow?

Regarding the creation of a release branch I assume that creating the branch from 'develop' implies that all available tests and quality criteries must be matched before the actual branching takes place. Am I right on this ? Best regards Daniel Kasmeroglu

Re: git workflow?

Not quite, the /release /branch takes place 'whenever' - This means it would be 'nice' to create it from a stable /develop/, but is NOT required (this is the big +1 for me). The /release /branch is where the release is polished and prepared and all the tests must 'eventually' pass - work can c

Re: git workflow?

sorry I'm surely slow today but it if can avoid me 1h ;): so what's different with tags? ie when do you go to master without having a release? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-10-17 16:41 GMT+02:00 Andy

Re: git workflow?

Release branches act as a buffer between feature development (develop) and public releases (master). Whenever you merge something into master, you should tag the commit for reference git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master git push --tags On 17/10/2014 16:46, Romain Manni-Bucau

Re: git workflow?

yes, so master is just a single branch showing only tags, what's the need behind? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-10-17 17:30 GMT+02:00 Andy Gumbrecht : > Release branches act as a buffer between featu

Re: TCK cdi-embedded

did you have your JAVA_OPTS properly tuned? I use the following in /etc/mavenrc: export MAVEN_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=196m -client" Works fine for most projects. LieGrue, strub > On Friday, 17 October 2014, 8:26, Romain Manni-Bucau > wrote: > > Hi > > that's the case 'ie n

Re: TCK cdi-embedded

well here the issue is on your side I already increased it to 512 but we should be able to run it with 64. A task to do before hacking on tcks. That's the game ;) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-10-17

Pull requests

Hi, I've turned the previously made patches into pull requests (always based upon the /develop branch). Please let me know if I did something wrong here. * https://issues.apache.org/jira/browse/TOMEE-1377 * https://issues.apache.org/jira/browse/TOMEE-1395 * https://issues.apache.org/jira/browse/T