Re: Classpath discovery in REST annotations with virtual classpath

[tcollignon]

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-discovery-in-REST-annotations-with-virtual-classpath-tp4672309p4672368.html
Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Classpath discovery in REST annotations with virtual classpath

[Romain Manni-Bucau]

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/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/config/QuickContextXmlParser.java
and to get catalina_home/base you use
SystemInstance.get().getBase/Home(). So you just need to check other
files are present and if so read them as well. I'd do it in
org.apache.openejb.config.QuickContextXmlParser#parse.

> - m2e-webby is in eclipse, do you think use tomee:embedded maven goal in
> eclipse to ? Or you think use in other part ?
>

we didn't plan eclipse an integration yet (actually eclipse should
drive it IMHO)


>
>
>
> --
> View this message in context: 
> http://tomee-openejb.979440.n4.nabble.com/Classpath-discovery-in-REST-annotations-with-virtual-classpath-tp4672309p4672368.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.

Re: Classpath discovery in REST annotations with virtual classpath

[tcollignon]

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

[Daniel Cunha]

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/danielvlcunha
Sent from my cell phone
Em 16/10/2014 07:01, "Daniel Cunha"  escreveu:

> +1
>
> On Thu, Oct 16, 2014 at 6:06 AM, Daniel Kasmeroglu <
> daniel.kasmero...@kasisoft.net> wrote:
>
>> Am 16.10.2014 um 11:05 schrieb Andy Gumbrecht:
>> > OK guys and gals, today is SVN lockdown. We are moving to GIT this
>> > afternoon.
>> >
>> > If you are working on something then please wait until we are up in GIT,
>> > and be aware that this may take an unknown number of hours.
>> >
>> But it will be worth it ;-)
>>
>> Good luck with the migration (although there shouldn't be big issues).
>>
>>
>> Best regards
>>
>> Daniel Kasmeroglu
>>
>
>
>
> --
> 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
>

git workflow?

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

Re: Migration to GIT

[Andy]

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?

[Daniel Kasmeroglu]

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 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?
> 
I cannot access this as I don't have the necessary permissions (at least
my apache account is not working here).


Best regards

Daniel Kasmeroglu

Re: git workflow?

[Andy Gumbrecht]

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 or vote before opening the door.


So now you/we get to discuss it with the door open. I will have to 
publish the docs now so that at least others have a chance at hearing 
that something has changed.


Andy.

On 17/10/2014 13:04, Romain Manni-Bucau wrote:

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: git workflow?

[Christofer Dutz]

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 | blog.codecentric.de | www.meettheexperts.de | 
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 :

> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: git workflow?

[Andy Gumbrecht]

+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  | blog.codecentric.de 
 | www.meettheexperts.de 
 | 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 
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: Migration to GIT

[Daniel Cunha]

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.com/in/danielvlcunha
Sent from my cell phone
Em 17/10/2014 08:05, "Andy"  escreveu:

> 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: Migration to GIT

[Andy Gumbrecht]

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 Gumbrecht
  https://twitter.com/AndyGeeDe
  http://www.tomitribe.com

Re: git workflow?

[Romain Manni-Bucau]

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 merge develop/master ensuring history is good ie not 1-1 merge
(manual process). if you don't do it then develop branch doesn't bring
anything
3) agree that feature branches are great (local or remote depending
the visibility of the work)



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


2014-10-17 13:25 GMT+02:00 Andy Gumbrecht :
> +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  | blog.codecentric.de
>>  | www.meettheexperts.de
>>  | 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 > >:
>>
>>> 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: 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 
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  | blog.codecentric.de <
>> http://blog.codecentric.de/> | www.meettheexperts.de <
>> http://www.meettheexperts.de/> | 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 > >:
>>
>>  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: Migration to GIT

[Daniel Cunha]

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/10/2014 09:01, "Andy Gumbrecht"  escreveu:

> 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 Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>
>

Re: git workflow?

[Daniel Kasmeroglu]

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?

[Andy Gumbrecht]

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 continue in /develop/ 
(another big +1) - everyone can help make the /release /stable.


When the /release /branch is ready then it is merged to /master /*and 
*/develop /(if there were changes in the /release /then they also need 
to get merged back to /develop/)


The /master /branch only ever contains stable production ready code.

Andy.

On 17/10/2014 15:54, Daniel Kasmeroglu wrote:

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






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

Re: git workflow?

[Romain Manni-Bucau]

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 Gumbrecht :
> 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 continue in /develop/ (another
> big +1) - everyone can help make the /release /stable.
>
> When the /release /branch is ready then it is merged to /master /*and
> */develop /(if there were changes in the /release /then they also need to
> get merged back to /develop/)
>
> The /master /branch only ever contains stable production ready code.
>
> Andy.
>
>
> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>
>> 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
>>
>>
>>
>
>
> --
>   Andy Gumbrecht
>   https://twitter.com/AndyGeeDe
>   http://www.tomitribe.com
>

Re: git workflow?

[Andy Gumbrecht]

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 wrote:

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 Gumbrecht :

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 continue in /develop/ (another
big +1) - everyone can help make the /release /stable.

When the /release /branch is ready then it is merged to /master /*and
*/develop /(if there were changes in the /release /then they also need to
get merged back to /develop/)

The /master /branch only ever contains stable production ready code.

Andy.


On 17/10/2014 15:54, Daniel Kasmeroglu wrote:

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





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





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

Re: git workflow?

[Romain Manni-Bucau]

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 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 wrote:
>>
>> 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 Gumbrecht :
>>>
>>> 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 continue in /develop/
>>> (another
>>> big +1) - everyone can help make the /release /stable.
>>>
>>> When the /release /branch is ready then it is merged to /master /*and
>>> */develop /(if there were changes in the /release /then they also need to
>>> get merged back to /develop/)
>>>
>>> The /master /branch only ever contains stable production ready code.
>>>
>>> Andy.
>>>
>>>
>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:

 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



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

Re: TCK cdi-embedded

[Mark Struberg]

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 not your laptop issue)
> 
> first step in tck work is to get rid of it. I didnt dig into it but it
> is likely an issue with a memory leak with arquillian openejb embedded
> or openejb-http embedded layer, maybe due to LocalBeanProxy - not
> sure.
> 
> To reduce the set of test you can use the testng xml file but I don't
> like the idea to reduce the default set since it would just hide a
> real issue.
> 
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 
> 2014-10-17 2:03 GMT+02:00 Daniel Cunha :
>>  Hi guys,
>> 
>>  Maybe I don't have a good laptop, but TCK for cdi-embedded don't 
> run here.
>>  :(
>>  I have a "GC overhead limit exceeded" when I run the TCK tests in 
> my work,
>>  I don't have problem, but at home always show this msg.
>> 
>>  Can I reduce some TCK tests? How do I do it?
>> 
>>  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/danielvlcunha
> 

Re: TCK cdi-embedded

[Romain Manni-Bucau]

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 20:59 GMT+02:00 Mark Struberg :
> 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 not your laptop issue)
>>
>> first step in tck work is to get rid of it. I didnt dig into it but it
>> is likely an issue with a memory leak with arquillian openejb embedded
>> or openejb-http embedded layer, maybe due to LocalBeanProxy - not
>> sure.
>>
>> To reduce the set of test you can use the testng xml file but I don't
>> like the idea to reduce the default set since it would just hide a
>> real issue.
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>>
>> 2014-10-17 2:03 GMT+02:00 Daniel Cunha :
>>>  Hi guys,
>>>
>>>  Maybe I don't have a good laptop, but TCK for cdi-embedded don't
>> run here.
>>>  :(
>>>  I have a "GC overhead limit exceeded" when I run the TCK tests in
>> my work,
>>>  I don't have problem, but at home always show this msg.
>>>
>>>  Can I reduce some TCK tests? How do I do it?
>>>
>>>  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/danielvlcunha
>>

Pull requests

[Daniel Kasmeroglu]

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/TOMEE-1396
* https://issues.apache.org/jira/browse/TOMEE-1397
* https://issues.apache.org/jira/browse/TOMEE-1399
* https://issues.apache.org/jira/browse/TOMEE-1401
* https://issues.apache.org/jira/browse/TOMEE-1403


Best regards

Daniel Kasmeroglu