Re: [Discuss] Data Module - Transactional Repositories
Hello, 1) a producer + qualifier would be easier on entitymanager side so I'd propagate it to the repository. 2) em in transactionscoped should be useless since if you produce the em you are already in a scope so already cached by CDI itself, no? 3) we don't really need interceptors since we can invoke it ourself in the handler (for me CRUD + transaction need to fit together so not shocking to keep them linked. JPA is linked to JTA BTW ;)), it would even be important to be able to avoid nested transactions by default (I don't recall what does default @Tx impl). Where I'm less confident is with current @Tx impl we can't force a new transaction so we doesn't cover all needed case. But should be enough to start. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-17 7:51 GMT+01:00 Thomas Hug : > Yes would be great to get this sorted out soon. Looks like 2) is the > preferred way to go, which would also mean some work on the JPA module. > > - Any thoughts on how the Data EntityManagerResolver fits in the picture > there? > - Also [1] seems rather nasty in this context. Is there a better way > dealing with it than just trying to detect it has not been picked up and > then call the TransactionStrategy by ourself? > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-419 > > > On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau > wrote: > >> Hi Thomas, >> >> would be great to get it in 0.6, any idea if it would be possible? I >> should be able to help once decided and if needed. >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> >> 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau : >> > While it works with JTA it is ok for me, I think it should be >> > compatible with our @Transactional and EE 7 one. I think reusing >> > @Transactional is important in declaration (on method) so maybe the >> > way to go. >> > Romain Manni-Bucau >> > Twitter: @rmannibucau >> > Blog: http://rmannibucau.wordpress.com/ >> > LinkedIn: http://fr.linkedin.com/in/rmannibucau >> > Github: https://github.com/rmannibucau >> > >> > >> > >> > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO : >> >> +1 for 2/ as well. >> >> That is right from an end user experience point of view. >> >> Also right to reuse and put in common some parts of JPA and Data module >> >> Closer to Java EE 7 @Transactional approach >> >> >> >> JLouis >> >> >> >> >> >> >> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug : >> >> >> >>> Not sure where we stopped in the discussion but AFAIR we had two >> approaches >> >>> here: >> >>> >> >>> 1) An automatic internal tx handling if one is needed by the query, >> >>> probably similar to what the JPA module does in the >> >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by >> an >> >>> attribute on @Repository defaulting to active. >> >>> >> >>> 2) Integration with @Transactional of the JPA module. For this we'd >> also >> >>> have to look at: >> >>> - Aligning EntityManager resolution between the two modules. That could >> >>> include moving the EntityManagerResolver into the JPA module API and >> >>> eventually removing the current qualifier-based resolution. That one >> would >> >>> need some more thoughts to get out something consistent. >> >>> - Eventually exposing the resolved EM @TransactionScoped so the >> repository >> >>> can easily access it. >> >>> - Deal with PartialBeans not picking up interceptors - AFAIR this was >> >>> reported to be an issue on some Weld versions? >> >>> >> >>> +1 on 2) - makes for me much more sense from a user perspective. >> >>> >> >> >> >> >> >> >> >> -- >> >> Jean-Louis >>
Re: [Discuss] Data Module - Transactional Repositories
Yes would be great to get this sorted out soon. Looks like 2) is the preferred way to go, which would also mean some work on the JPA module. - Any thoughts on how the Data EntityManagerResolver fits in the picture there? - Also [1] seems rather nasty in this context. Is there a better way dealing with it than just trying to detect it has not been picked up and then call the TransactionStrategy by ourself? [1] https://issues.apache.org/jira/browse/DELTASPIKE-419 On Sun, Feb 16, 2014 at 10:10 PM, Romain Manni-Bucau wrote: > Hi Thomas, > > would be great to get it in 0.6, any idea if it would be possible? I > should be able to help once decided and if needed. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau : > > While it works with JTA it is ok for me, I think it should be > > compatible with our @Transactional and EE 7 one. I think reusing > > @Transactional is important in declaration (on method) so maybe the > > way to go. > > Romain Manni-Bucau > > Twitter: @rmannibucau > > Blog: http://rmannibucau.wordpress.com/ > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > Github: https://github.com/rmannibucau > > > > > > > > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO : > >> +1 for 2/ as well. > >> That is right from an end user experience point of view. > >> Also right to reuse and put in common some parts of JPA and Data module > >> Closer to Java EE 7 @Transactional approach > >> > >> JLouis > >> > >> > >> > >> 2014-02-12 11:20 GMT+01:00 Thomas Hug : > >> > >>> Not sure where we stopped in the discussion but AFAIR we had two > approaches > >>> here: > >>> > >>> 1) An automatic internal tx handling if one is needed by the query, > >>> probably similar to what the JPA module does in the > >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by > an > >>> attribute on @Repository defaulting to active. > >>> > >>> 2) Integration with @Transactional of the JPA module. For this we'd > also > >>> have to look at: > >>> - Aligning EntityManager resolution between the two modules. That could > >>> include moving the EntityManagerResolver into the JPA module API and > >>> eventually removing the current qualifier-based resolution. That one > would > >>> need some more thoughts to get out something consistent. > >>> - Eventually exposing the resolved EM @TransactionScoped so the > repository > >>> can easily access it. > >>> - Deal with PartialBeans not picking up interceptors - AFAIR this was > >>> reported to be an issue on some Weld versions? > >>> > >>> +1 on 2) - makes for me much more sense from a user perspective. > >>> > >> > >> > >> > >> -- > >> Jean-Louis >
Re: [DISCUSS] next release version? 0.6 or 1.0?
That’s reasonable enough. On 16. feb. 2014, at 23:02, Jason Porter wrote: > Probably because we've become busy with some other projects and priorities :(— > Sent from Mailbox for iPhone > > On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim wrote: > >> The commit graph shows too few committers.. and I appreciate your work! >> I also notice too few Redhat/JBoss Weld/Seam committers left on the project. >> How come? >> /ove >> On 16. feb. 2014, at 22:10, Gerhard Petracek >> wrote: >>> hi ove, >>> >>> i was only talking about the commits. >>> >>> regards, >>> gerhard >>> >>> http://www.irian.at >>> >>> Your JSF/JavaEE powerhouse - >>> JavaEE Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >>> >>> >>> >>> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko : >>> +1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
Probably because we've become busy with some other projects and priorities :(— Sent from Mailbox for iPhone On Sun, Feb 16, 2014 at 2:39 PM, Ove Ranheim wrote: > The commit graph shows too few committers.. and I appreciate your work! > I also notice too few Redhat/JBoss Weld/Seam committers left on the project. > How come? > /ove > On 16. feb. 2014, at 22:10, Gerhard Petracek > wrote: >> hi ove, >> >> i was only talking about the commits. >> >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF/JavaEE powerhouse - >> JavaEE Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> 2014-02-16 22:07 GMT+01:00 Thomas Andraschko : >> >>> +1 Ove >>> We are really late for an 0.6. I would release 0.6 this/next month and >>> after that, lets finish 1.0. >>> We should fix all open issues and finish the documentation! >>>
Re: [DISCUSS] next release version? 0.6 or 1.0?
The commit graph shows too few committers.. and I appreciate your work! I also notice too few Redhat/JBoss Weld/Seam committers left on the project. How come? /ove On 16. feb. 2014, at 22:10, Gerhard Petracek wrote: > hi ove, > > i was only talking about the commits. > > regards, > gerhard > > http://www.irian.at > > Your JSF/JavaEE powerhouse - > JavaEE Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2014-02-16 22:07 GMT+01:00 Thomas Andraschko : > >> +1 Ove >> We are really late for an 0.6. I would release 0.6 this/next month and >> after that, lets finish 1.0. >> We should fix all open issues and finish the documentation! >>
Re: [DISCUSS] next release version? 0.6 or 1.0?
hi ove, i was only talking about the commits. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 22:07 GMT+01:00 Thomas Andraschko : > +1 Ove > We are really late for an 0.6. I would release 0.6 this/next month and > after that, lets finish 1.0. > We should fix all open issues and finish the documentation! >
Re: [Discuss] Data Module - Transactional Repositories
Hi Thomas, would be great to get it in 0.6, any idea if it would be possible? I should be able to help once decided and if needed. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-12 12:13 GMT+01:00 Romain Manni-Bucau : > While it works with JTA it is ok for me, I think it should be > compatible with our @Transactional and EE 7 one. I think reusing > @Transactional is important in declaration (on method) so maybe the > way to go. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-12 11:40 GMT+01:00 Jean-Louis MONTEIRO : >> +1 for 2/ as well. >> That is right from an end user experience point of view. >> Also right to reuse and put in common some parts of JPA and Data module >> Closer to Java EE 7 @Transactional approach >> >> JLouis >> >> >> >> 2014-02-12 11:20 GMT+01:00 Thomas Hug : >> >>> Not sure where we stopped in the discussion but AFAIR we had two approaches >>> here: >>> >>> 1) An automatic internal tx handling if one is needed by the query, >>> probably similar to what the JPA module does in the >>> EnvironmentAwareTransactionStrategy. Could eventually be controlled by an >>> attribute on @Repository defaulting to active. >>> >>> 2) Integration with @Transactional of the JPA module. For this we'd also >>> have to look at: >>> - Aligning EntityManager resolution between the two modules. That could >>> include moving the EntityManagerResolver into the JPA module API and >>> eventually removing the current qualifier-based resolution. That one would >>> need some more thoughts to get out something consistent. >>> - Eventually exposing the resolved EM @TransactionScoped so the repository >>> can easily access it. >>> - Deal with PartialBeans not picking up interceptors - AFAIR this was >>> reported to be an issue on some Weld versions? >>> >>> +1 on 2) - makes for me much more sense from a user perspective. >>> >> >> >> >> -- >> Jean-Louis
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 Ove We are really late for an 0.6. I would release 0.6 this/next month and after that, lets finish 1.0. We should fix all open issues and finish the documentation!
Re: [DISCUSS] next release version? 0.6 or 1.0?
Hi Gerhard, Was your point the commit graph or the professional support? I would recognize Apache Software to be an Open Source Foundation. My intent was not identify myself as a customer to shop commercial product support, on something not completed, but to urge the importance of getting sources, compiled binaries (read: i can do that myself), out the door. Not, the professional part of it. I used to be one of the JBoss-ers evangelists (external) and wishes to see the joint efforts agreed on 2+ years ago to become the success on top of CDI, that DS really deserves to become. Cheers, Ove On 16. feb. 2014, at 21:54, Gerhard Petracek wrote: > hi ove, > > fyi: > i just sent the link for our site. > for code+site you can have a look at [1]. > > regards, > gerhard > > [1] http://s.apache.org/Pov > > http://www.irian.at > > Your JSF/JavaEE powerhouse - > JavaEE Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2014-02-16 21:27 GMT+01:00 Ove Ranheim : > >> Mark, when do you plan to get the 1.0 release out? Time is important. >> Since there's a lot of documentation required, wouldn't this cause further >> delays? Are we talking about a shippable product in May timeframe, or would >> we see a release in Feb, possibly in March? >> >> I'm a user of DS, but in order to trust CDI/DS and not move towards >> Spring. This is a big question for me, and I'm sure for many others (and >> potential) users too. IMO, it's a mistake not keep a tight e.g 12 weekly >> shippable release. Being Agile is key to success. The project has been >> running for 25+ months now. Reading through sources and looking at the >> commit-graph from Gerhard. I think you guys deserve to see an uptake of DS. >> But, binaries needs to be pushed to central. >> >> I'd say: -1 for 1.0 && +1 for 0.6. >> >> br, ove >> >> On 16. feb. 2014, at 16:39, Mark Struberg wrote: >> >>> I'd be +1 for 1.0 >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>> On Sunday, 16 February 2014, 14:52, Nicklas Karlsson >> wrote: >>> >>> (the rumors of my demise is somewhat exaggerated ;-) After migrating some applications from Seam 2 to Seam 3 (and then have >> Seam 3 "run out of steam"), I recommended migrating to DeltaSpike so I have >> some interest in DeltaSpike not end up the same way, that would be... professionally embarrassing ;-) Although I'm not obsessed with version numbers, I know several people >> who are and a 1.0 would certainly attract attention (and hopefully contributors). OTOH, one must be careful not to destroy the reputation >> of the framework by releasing too early and give a crappy first impression. Even if there are not that many fancy features, if the existing ones are well documented and accompanied by examples, people are usually more forgiving. Having said that, I might be able to contribute some company time on >> e.g. the JSF module (since we are using that, too). regards, - Nik On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim >> wrote: > Dear DS team! > > Two months ago the team discussed a 0.6 release. What is your plan? >> There > are many new great features since 0.5, so what is stopping the DS-team >> to > provide a new release? > > Looking through the JIRA there are 30 open issues, many of them regards > JSF and Tests. I don't use JSF anymore, so it hurts to be held back by > stack-releases. > > 6 out of 30 are Improvements. > 7 are New Features. > 1 is a Wish of porting Seam Mail. Cody has discontinued development of > Seam Mail, so this issue could probably be Resolved/Won't fix. > > If you constrain the release window to only bug fixing it looks like 14 > issues should be moved to 0.7. > 16 issues are real issues that needs to be decided upon. > > Would it make sense to elect on some big tickets to get 0.6 out? > > 15 months ago DS was proposed to be incubated. IMHO, if DS is going to >> be > a success, regular releases is a key factor. > > It's been five months since last 0.5 release. > > regards, > ove > > > On 12. nov. 2013, at 16:28, Mark Struberg wrote: > >> yea, but what are the alternatives? >> If you have a better idea, then tell us :) >> >> The problem is that it's not only about the JSF module but about all > other modules as well. >> >> LieGrue, >> strub >> >> >> >> >> - Original Message - >>> From: Gerhard Petracek >>> To: dev@deltaspike.apache.org >>> Cc: >>> Sent: Tuesday, 12 November 2013, 16:18 >>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >>> >>> @mark: >>> i never said that we should do #2. >>> >>> regards, >>> gerhard >>> >>>
Re: [DISCUSS] next release version? 0.6 or 1.0?
hi ove, fyi: i just sent the link for our site. for code+site you can have a look at [1]. regards, gerhard [1] http://s.apache.org/Pov http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014-02-16 21:27 GMT+01:00 Ove Ranheim : > Mark, when do you plan to get the 1.0 release out? Time is important. > Since there's a lot of documentation required, wouldn't this cause further > delays? Are we talking about a shippable product in May timeframe, or would > we see a release in Feb, possibly in March? > > I'm a user of DS, but in order to trust CDI/DS and not move towards > Spring. This is a big question for me, and I'm sure for many others (and > potential) users too. IMO, it's a mistake not keep a tight e.g 12 weekly > shippable release. Being Agile is key to success. The project has been > running for 25+ months now. Reading through sources and looking at the > commit-graph from Gerhard. I think you guys deserve to see an uptake of DS. > But, binaries needs to be pushed to central. > > I'd say: -1 for 1.0 && +1 for 0.6. > > br, ove > > On 16. feb. 2014, at 16:39, Mark Struberg wrote: > > > I'd be +1 for 1.0 > > > > LieGrue, > > strub > > > > > > > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > wrote: > > > > (the rumors of my demise is somewhat exaggerated ;-) > >> > >> After migrating some applications from Seam 2 to Seam 3 (and then have > Seam > >> 3 "run out of steam"), I recommended migrating to DeltaSpike so I have > some > >> interest in DeltaSpike not end up the same way, that would be... > >> professionally embarrassing ;-) > >> > >> Although I'm not obsessed with version numbers, I know several people > who > >> are and a 1.0 would certainly attract attention (and hopefully > >> contributors). OTOH, one must be careful not to destroy the reputation > of > >> the framework by releasing too early and give a crappy first impression. > >> Even if there are not that many fancy features, if the existing ones are > >> well documented and accompanied by examples, people are usually more > >> forgiving. > >> > >> Having said that, I might be able to contribute some company time on > e.g. > >> the JSF module (since we are using that, too). > >> > >> regards, > >> - Nik > >> > >> > >> > >> On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim > wrote: > >> > >>> Dear DS team! > >>> > >>> Two months ago the team discussed a 0.6 release. What is your plan? > There > >>> are many new great features since 0.5, so what is stopping the DS-team > to > >>> provide a new release? > >>> > >>> Looking through the JIRA there are 30 open issues, many of them regards > >>> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by > >>> stack-releases. > >>> > >>> 6 out of 30 are Improvements. > >>> 7 are New Features. > >>> 1 is a Wish of porting Seam Mail. Cody has discontinued development of > >>> Seam Mail, so this issue could probably be Resolved/Won't fix. > >>> > >>> If you constrain the release window to only bug fixing it looks like 14 > >>> issues should be moved to 0.7. > >>> 16 issues are real issues that needs to be decided upon. > >>> > >>> Would it make sense to elect on some big tickets to get 0.6 out? > >>> > >>> 15 months ago DS was proposed to be incubated. IMHO, if DS is going to > be > >>> a success, regular releases is a key factor. > >>> > >>> It's been five months since last 0.5 release. > >>> > >>> regards, > >>> ove > >>> > >>> > >>> On 12. nov. 2013, at 16:28, Mark Struberg wrote: > >>> > yea, but what are the alternatives? > If you have a better idea, then tell us :) > > The problem is that it's not only about the JSF module but about all > >>> other modules as well. > > LieGrue, > strub > > > > > - Original Message - > > From: Gerhard Petracek > > To: dev@deltaspike.apache.org > > Cc: > > Sent: Tuesday, 12 November 2013, 16:18 > > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > > > @mark: > > i never said that we should do #2. > > > > regards, > > gerhard > > > > > > > > > > 2013/11/12 Mark Struberg > > > >> Pete, Gerhard > >> > >> The Problem here is that there are only 2 ways to handle the > situation: > >> > >> 1.) all modules share the same version but have different maturity > >>> grades > >> > >> 2.) each module has it's very own version. A 0.x reflects > instability, > > 1.x > >> reflects maturity. But you know what happened with exactly this > >>> approach in > >> Seam3? The problem is that users do not know which version of > >>> ds-jsf-api > >> works together with which version of ds-core-impl for example. It > gets > >>> much > >> more complicated with later modules. > >> > >> Thus I prefer 1.). > >> > >> LieGrue, > >> strub > >>
Re: [DISCUSS] next release version? 0.6 or 1.0?
Mark, when do you plan to get the 1.0 release out? Time is important. Since there’s a lot of documentation required, wouldn’t this cause further delays? Are we talking about a shippable product in May timeframe, or would we see a release in Feb, possibly in March? I’m a user of DS, but in order to trust CDI/DS and not move towards Spring. This is a big question for me, and I’m sure for many others (and potential) users too. IMO, it’s a mistake not keep a tight e.g 12 weekly shippable release. Being Agile is key to success. The project has been running for 25+ months now. Reading through sources and looking at the commit-graph from Gerhard. I think you guys deserve to see an uptake of DS. But, binaries needs to be pushed to central. I’d say: -1 for 1.0 && +1 for 0.6. br, ove On 16. feb. 2014, at 16:39, Mark Struberg wrote: > I'd be +1 for 1.0 > > LieGrue, > strub > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > wrote: > > (the rumors of my demise is somewhat exaggerated ;-) >> >> After migrating some applications from Seam 2 to Seam 3 (and then have Seam >> 3 "run out of steam"), I recommended migrating to DeltaSpike so I have some >> interest in DeltaSpike not end up the same way, that would be... >> professionally embarrassing ;-) >> >> Although I'm not obsessed with version numbers, I know several people who >> are and a 1.0 would certainly attract attention (and hopefully >> contributors). OTOH, one must be careful not to destroy the reputation of >> the framework by releasing too early and give a crappy first impression. >> Even if there are not that many fancy features, if the existing ones are >> well documented and accompanied by examples, people are usually more >> forgiving. >> >> Having said that, I might be able to contribute some company time on e.g. >> the JSF module (since we are using that, too). >> >> regards, >> - Nik >> >> >> >> On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim wrote: >> >>> Dear DS team! >>> >>> Two months ago the team discussed a 0.6 release. What is your plan? There >>> are many new great features since 0.5, so what is stopping the DS-team to >>> provide a new release? >>> >>> Looking through the JIRA there are 30 open issues, many of them regards >>> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by >>> stack-releases. >>> >>> 6 out of 30 are Improvements. >>> 7 are New Features. >>> 1 is a Wish of porting Seam Mail. Cody has discontinued development of >>> Seam Mail, so this issue could probably be Resolved/Won't fix. >>> >>> If you constrain the release window to only bug fixing it looks like 14 >>> issues should be moved to 0.7. >>> 16 issues are real issues that needs to be decided upon. >>> >>> Would it make sense to elect on some big tickets to get 0.6 out? >>> >>> 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be >>> a success, regular releases is a key factor. >>> >>> It's been five months since last 0.5 release. >>> >>> regards, >>> ove >>> >>> >>> On 12. nov. 2013, at 16:28, Mark Struberg wrote: >>> yea, but what are the alternatives? If you have a better idea, then tell us :) The problem is that it's not only about the JSF module but about all >>> other modules as well. LieGrue, strub - Original Message - > From: Gerhard Petracek > To: dev@deltaspike.apache.org > Cc: > Sent: Tuesday, 12 November 2013, 16:18 > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > @mark: > i never said that we should do #2. > > regards, > gerhard > > > > > 2013/11/12 Mark Struberg > >> Pete, Gerhard >> >> The Problem here is that there are only 2 ways to handle the situation: >> >> 1.) all modules share the same version but have different maturity >>> grades >> >> 2.) each module has it's very own version. A 0.x reflects instability, > 1.x >> reflects maturity. But you know what happened with exactly this >>> approach in >> Seam3? The problem is that users do not know which version of >>> ds-jsf-api >> works together with which version of ds-core-impl for example. It gets >>> much >> more complicated with later modules. >> >> Thus I prefer 1.). >> >> LieGrue, >> strub >> >> >> >> >>> >>> From: Pete Muir >>> To: dev@deltaspike.apache.org >>> Sent: Tuesday, 12 November 2013, 14:35 >>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >>> >>> >>> +1 to Gerhard's point (I am looking to try to find someone to help >>> with >> docs, but the person I had in mind just left Red Hat :-(. Also +1 to >>> going >> to 1.0 soon (i.e. making docs and stability a priority!). >>> >>> >>> On 11 Nov 2013, at 23:09, Gerhard Petracek > >> wrote
Re: [DISCUSS] next release version? 0.6 or 1.0?
When do you like to release, Mark? I would like to finish ViewAccessScoped before 1.0 - and we should completely finish the documentation!!! So it will take some more weeks... 2014-02-16 16:43 GMT+01:00 Gerhard Petracek : > imo v0.6 is way overdue. > > @nik: > that's the issue - there are still several undocumented parts (also see > e.g. [1]) and there are only few examples. > > regards, > gerhard > > [1] http://s.apache.org/gf9 > > > > 2014-02-16 16:39 GMT+01:00 Mark Struberg : > > > I'd be +1 for 1.0 > > > > LieGrue, > > strub > > > > > > > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > > > wrote: > > > > (the rumors of my demise is somewhat exaggerated ;-) > > > > > >After migrating some applications from Seam 2 to Seam 3 (and then have > > Seam > > >3 "run out of steam"), I recommended migrating to DeltaSpike so I have > > some > > >interest in DeltaSpike not end up the same way, that would be... > > >professionally embarrassing ;-) > > > > > >Although I'm not obsessed with version numbers, I know several people > who > > >are and a 1.0 would certainly attract attention (and hopefully > > >contributors). OTOH, one must be careful not to destroy the reputation > of > > >the framework by releasing too early and give a crappy first impression. > > >Even if there are not that many fancy features, if the existing ones are > > >well documented and accompanied by examples, people are usually more > > >forgiving. > > > > > >Having said that, I might be able to contribute some company time on > e.g. > > >the JSF module (since we are using that, too). > > > > > >regards, > > > - Nik > > > > > > > > > > > >On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim > wrote: > > > > > >> Dear DS team! > > >> > > >> Two months ago the team discussed a 0.6 release. What is your plan? > > There > > >> are many new great features since 0.5, so what is stopping the DS-team > > to > > >> provide a new release? > > >> > > >> Looking through the JIRA there are 30 open issues, many of them > regards > > >> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by > > >> stack-releases. > > >> > > >> 6 out of 30 are Improvements. > > >> 7 are New Features. > > >> 1 is a Wish of porting Seam Mail. Cody has discontinued development of > > >> Seam Mail, so this issue could probably be Resolved/Won't fix. > > >> > > >> If you constrain the release window to only bug fixing it looks like > 14 > > >> issues should be moved to 0.7. > > >> 16 issues are real issues that needs to be decided upon. > > >> > > >> Would it make sense to elect on some big tickets to get 0.6 out? > > >> > > >> 15 months ago DS was proposed to be incubated. IMHO, if DS is going to > > be > > >> a success, regular releases is a key factor. > > >> > > >> It's been five months since last 0.5 release. > > >> > > >> regards, > > >> ove > > >> > > >> > > >> On 12. nov. 2013, at 16:28, Mark Struberg wrote: > > >> > > >> > yea, but what are the alternatives? > > >> > If you have a better idea, then tell us :) > > >> > > > >> > The problem is that it's not only about the JSF module but about all > > >> other modules as well. > > >> > > > >> > LieGrue, > > >> > strub > > >> > > > >> > > > >> > > > >> > > > >> > - Original Message - > > >> >> From: Gerhard Petracek > > >> >> To: dev@deltaspike.apache.org > > >> >> Cc: > > >> >> Sent: Tuesday, 12 November 2013, 16:18 > > >> >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > >> >> > > >> >> @mark: > > >> >> i never said that we should do #2. > > >> >> > > >> >> regards, > > >> >> gerhard > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> 2013/11/12 Mark Struberg > > >> >> > > >> >>> Pete, Gerhard > > >> >>> > > >> >>> The Problem here is that there are only 2 ways to handle the > > situation: > > >> >>> > > >> >>> 1.) all modules share the same version but have different maturity > > >> grades > > >> >>> > > >> >>> 2.) each module has it's very own version. A 0.x reflects > > instability, > > >> >> 1.x > > >> >>> reflects maturity. But you know what happened with exactly this > > >> approach in > > >> >>> Seam3? The problem is that users do not know which version of > > >> ds-jsf-api > > >> >>> works together with which version of ds-core-impl for example. It > > gets > > >> much > > >> >>> more complicated with later modules. > > >> >>> > > >> >>> Thus I prefer 1.). > > >> >>> > > >> >>> LieGrue, > > >> >>> strub > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> > > >> From: Pete Muir > > >> To: dev@deltaspike.apache.org > > >> Sent: Tuesday, 12 November 2013, 14:35 > > >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > >> > > >> > > >> +1 to Gerhard's point (I am looking to try to find someone to > help > > >> with > > >> >>> docs, but the person I had in mind just left Red Hat :-(. Also +1 > to > > >> going > > >> >>> to 1.0 soon (i.e. making docs and stability a priority!). > > >> >>
Re: [DISCUSS] next release version? 0.6 or 1.0?
imo v0.6 is way overdue. @nik: that's the issue - there are still several undocumented parts (also see e.g. [1]) and there are only few examples. regards, gerhard [1] http://s.apache.org/gf9 2014-02-16 16:39 GMT+01:00 Mark Struberg : > I'd be +1 for 1.0 > > LieGrue, > strub > > > > > > On Sunday, 16 February 2014, 14:52, Nicklas Karlsson > wrote: > > (the rumors of my demise is somewhat exaggerated ;-) > > > >After migrating some applications from Seam 2 to Seam 3 (and then have > Seam > >3 "run out of steam"), I recommended migrating to DeltaSpike so I have > some > >interest in DeltaSpike not end up the same way, that would be... > >professionally embarrassing ;-) > > > >Although I'm not obsessed with version numbers, I know several people who > >are and a 1.0 would certainly attract attention (and hopefully > >contributors). OTOH, one must be careful not to destroy the reputation of > >the framework by releasing too early and give a crappy first impression. > >Even if there are not that many fancy features, if the existing ones are > >well documented and accompanied by examples, people are usually more > >forgiving. > > > >Having said that, I might be able to contribute some company time on e.g. > >the JSF module (since we are using that, too). > > > >regards, > > - Nik > > > > > > > >On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim wrote: > > > >> Dear DS team! > >> > >> Two months ago the team discussed a 0.6 release. What is your plan? > There > >> are many new great features since 0.5, so what is stopping the DS-team > to > >> provide a new release? > >> > >> Looking through the JIRA there are 30 open issues, many of them regards > >> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by > >> stack-releases. > >> > >> 6 out of 30 are Improvements. > >> 7 are New Features. > >> 1 is a Wish of porting Seam Mail. Cody has discontinued development of > >> Seam Mail, so this issue could probably be Resolved/Won't fix. > >> > >> If you constrain the release window to only bug fixing it looks like 14 > >> issues should be moved to 0.7. > >> 16 issues are real issues that needs to be decided upon. > >> > >> Would it make sense to elect on some big tickets to get 0.6 out? > >> > >> 15 months ago DS was proposed to be incubated. IMHO, if DS is going to > be > >> a success, regular releases is a key factor. > >> > >> It's been five months since last 0.5 release. > >> > >> regards, > >> ove > >> > >> > >> On 12. nov. 2013, at 16:28, Mark Struberg wrote: > >> > >> > yea, but what are the alternatives? > >> > If you have a better idea, then tell us :) > >> > > >> > The problem is that it's not only about the JSF module but about all > >> other modules as well. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > > >> > > >> > - Original Message - > >> >> From: Gerhard Petracek > >> >> To: dev@deltaspike.apache.org > >> >> Cc: > >> >> Sent: Tuesday, 12 November 2013, 16:18 > >> >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >> >> > >> >> @mark: > >> >> i never said that we should do #2. > >> >> > >> >> regards, > >> >> gerhard > >> >> > >> >> > >> >> > >> >> > >> >> 2013/11/12 Mark Struberg > >> >> > >> >>> Pete, Gerhard > >> >>> > >> >>> The Problem here is that there are only 2 ways to handle the > situation: > >> >>> > >> >>> 1.) all modules share the same version but have different maturity > >> grades > >> >>> > >> >>> 2.) each module has it's very own version. A 0.x reflects > instability, > >> >> 1.x > >> >>> reflects maturity. But you know what happened with exactly this > >> approach in > >> >>> Seam3? The problem is that users do not know which version of > >> ds-jsf-api > >> >>> works together with which version of ds-core-impl for example. It > gets > >> much > >> >>> more complicated with later modules. > >> >>> > >> >>> Thus I prefer 1.). > >> >>> > >> >>> LieGrue, > >> >>> strub > >> >>> > >> >>> > >> >>> > >> >>> > >> > >> From: Pete Muir > >> To: dev@deltaspike.apache.org > >> Sent: Tuesday, 12 November 2013, 14:35 > >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >> > >> > >> +1 to Gerhard's point (I am looking to try to find someone to help > >> with > >> >>> docs, but the person I had in mind just left Red Hat :-(. Also +1 to > >> going > >> >>> to 1.0 soon (i.e. making docs and stability a priority!). > >> > >> > >> On 11 Nov 2013, at 23:09, Gerhard Petracek > >> >> > >> >>> wrote: > >> > >> > if we move to v1 soon, we need an useful versioning strategy, > >> >> better > >> >>> docs > >> > and examples + the api and spi need to be stable for some time (in > >> >> the > >> >>> best > >> > case until v2+). > >> > > >> > regards, > >> > gerhard > >> > > >> > > >> > > >> > 2013/11/11 Mark Struberg > >> > > >> >> > >> >> > >> >> how should that work? > >> >> > >> >> Please no
Re: [DISCUSS] next release version? 0.6 or 1.0?
I'd be +1 for 1.0 LieGrue, strub On Sunday, 16 February 2014, 14:52, Nicklas Karlsson wrote: (the rumors of my demise is somewhat exaggerated ;-) > >After migrating some applications from Seam 2 to Seam 3 (and then have Seam >3 "run out of steam"), I recommended migrating to DeltaSpike so I have some >interest in DeltaSpike not end up the same way, that would be... >professionally embarrassing ;-) > >Although I'm not obsessed with version numbers, I know several people who >are and a 1.0 would certainly attract attention (and hopefully >contributors). OTOH, one must be careful not to destroy the reputation of >the framework by releasing too early and give a crappy first impression. >Even if there are not that many fancy features, if the existing ones are >well documented and accompanied by examples, people are usually more >forgiving. > >Having said that, I might be able to contribute some company time on e.g. >the JSF module (since we are using that, too). > >regards, > - Nik > > > >On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim wrote: > >> Dear DS team! >> >> Two months ago the team discussed a 0.6 release. What is your plan? There >> are many new great features since 0.5, so what is stopping the DS-team to >> provide a new release? >> >> Looking through the JIRA there are 30 open issues, many of them regards >> JSF and Tests. I don't use JSF anymore, so it hurts to be held back by >> stack-releases. >> >> 6 out of 30 are Improvements. >> 7 are New Features. >> 1 is a Wish of porting Seam Mail. Cody has discontinued development of >> Seam Mail, so this issue could probably be Resolved/Won't fix. >> >> If you constrain the release window to only bug fixing it looks like 14 >> issues should be moved to 0.7. >> 16 issues are real issues that needs to be decided upon. >> >> Would it make sense to elect on some big tickets to get 0.6 out? >> >> 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be >> a success, regular releases is a key factor. >> >> It's been five months since last 0.5 release. >> >> regards, >> ove >> >> >> On 12. nov. 2013, at 16:28, Mark Struberg wrote: >> >> > yea, but what are the alternatives? >> > If you have a better idea, then tell us :) >> > >> > The problem is that it's not only about the JSF module but about all >> other modules as well. >> > >> > LieGrue, >> > strub >> > >> > >> > >> > >> > - Original Message - >> >> From: Gerhard Petracek >> >> To: dev@deltaspike.apache.org >> >> Cc: >> >> Sent: Tuesday, 12 November 2013, 16:18 >> >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >> >> >> >> @mark: >> >> i never said that we should do #2. >> >> >> >> regards, >> >> gerhard >> >> >> >> >> >> >> >> >> >> 2013/11/12 Mark Struberg >> >> >> >>> Pete, Gerhard >> >>> >> >>> The Problem here is that there are only 2 ways to handle the situation: >> >>> >> >>> 1.) all modules share the same version but have different maturity >> grades >> >>> >> >>> 2.) each module has it's very own version. A 0.x reflects instability, >> >> 1.x >> >>> reflects maturity. But you know what happened with exactly this >> approach in >> >>> Seam3? The problem is that users do not know which version of >> ds-jsf-api >> >>> works together with which version of ds-core-impl for example. It gets >> much >> >>> more complicated with later modules. >> >>> >> >>> Thus I prefer 1.). >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> >> >> From: Pete Muir >> To: dev@deltaspike.apache.org >> Sent: Tuesday, 12 November 2013, 14:35 >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >> >> >> +1 to Gerhard's point (I am looking to try to find someone to help >> with >> >>> docs, but the person I had in mind just left Red Hat :-(. Also +1 to >> going >> >>> to 1.0 soon (i.e. making docs and stability a priority!). >> >> >> On 11 Nov 2013, at 23:09, Gerhard Petracek >> >> >> >>> wrote: >> >> > if we move to v1 soon, we need an useful versioning strategy, >> >> better >> >>> docs >> > and examples + the api and spi need to be stable for some time (in >> >> the >> >>> best >> > case until v2+). >> > >> > regards, >> > gerhard >> > >> > >> > >> > 2013/11/11 Mark Struberg >> > >> >> >> >> >> >> how should that work? >> >> >> >> Please note that we will have some not perfectly finished >> >> modules very >> >> often. Basically whenever we add a new module... >> >> There is just no way to avoid this other than making those >> >> modules own >> >> releases. But this does not work out neither (as seen on a few >> >> other >> >> projects I don't like to name). >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >> >> >> >> >> >> >>> >> >>> From: Romain Manni-Bucau >> >>> To: Mark Struberg ; >> >> dev@deltaspike.apac
Re: [DISCUSS] next release version? 0.6 or 1.0?
(the rumors of my demise is somewhat exaggerated ;-) After migrating some applications from Seam 2 to Seam 3 (and then have Seam 3 "run out of steam"), I recommended migrating to DeltaSpike so I have some interest in DeltaSpike not end up the same way, that would be... professionally embarrassing ;-) Although I'm not obsessed with version numbers, I know several people who are and a 1.0 would certainly attract attention (and hopefully contributors). OTOH, one must be careful not to destroy the reputation of the framework by releasing too early and give a crappy first impression. Even if there are not that many fancy features, if the existing ones are well documented and accompanied by examples, people are usually more forgiving. Having said that, I might be able to contribute some company time on e.g. the JSF module (since we are using that, too). regards, - Nik On Sun, Feb 16, 2014 at 1:40 PM, Ove Ranheim wrote: > Dear DS team! > > Two months ago the team discussed a 0.6 release. What is your plan? There > are many new great features since 0.5, so what is stopping the DS-team to > provide a new release? > > Looking through the JIRA there are 30 open issues, many of them regards > JSF and Tests. I don't use JSF anymore, so it hurts to be held back by > stack-releases. > > 6 out of 30 are Improvements. > 7 are New Features. > 1 is a Wish of porting Seam Mail. Cody has discontinued development of > Seam Mail, so this issue could probably be Resolved/Won't fix. > > If you constrain the release window to only bug fixing it looks like 14 > issues should be moved to 0.7. > 16 issues are real issues that needs to be decided upon. > > Would it make sense to elect on some big tickets to get 0.6 out? > > 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be > a success, regular releases is a key factor. > > It's been five months since last 0.5 release. > > regards, > ove > > > On 12. nov. 2013, at 16:28, Mark Struberg wrote: > > > yea, but what are the alternatives? > > If you have a better idea, then tell us :) > > > > The problem is that it's not only about the JSF module but about all > other modules as well. > > > > LieGrue, > > strub > > > > > > > > > > - Original Message - > >> From: Gerhard Petracek > >> To: dev@deltaspike.apache.org > >> Cc: > >> Sent: Tuesday, 12 November 2013, 16:18 > >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >> > >> @mark: > >> i never said that we should do #2. > >> > >> regards, > >> gerhard > >> > >> > >> > >> > >> 2013/11/12 Mark Struberg > >> > >>> Pete, Gerhard > >>> > >>> The Problem here is that there are only 2 ways to handle the situation: > >>> > >>> 1.) all modules share the same version but have different maturity > grades > >>> > >>> 2.) each module has it's very own version. A 0.x reflects instability, > >> 1.x > >>> reflects maturity. But you know what happened with exactly this > approach in > >>> Seam3? The problem is that users do not know which version of > ds-jsf-api > >>> works together with which version of ds-core-impl for example. It gets > much > >>> more complicated with later modules. > >>> > >>> Thus I prefer 1.). > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > > From: Pete Muir > To: dev@deltaspike.apache.org > Sent: Tuesday, 12 November 2013, 14:35 > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > > +1 to Gerhard's point (I am looking to try to find someone to help > with > >>> docs, but the person I had in mind just left Red Hat :-(. Also +1 to > going > >>> to 1.0 soon (i.e. making docs and stability a priority!). > > > On 11 Nov 2013, at 23:09, Gerhard Petracek > >> > >>> wrote: > > > if we move to v1 soon, we need an useful versioning strategy, > >> better > >>> docs > > and examples + the api and spi need to be stable for some time (in > >> the > >>> best > > case until v2+). > > > > regards, > > gerhard > > > > > > > > 2013/11/11 Mark Struberg > > > >> > >> > >> how should that work? > >> > >> Please note that we will have some not perfectly finished > >> modules very > >> often. Basically whenever we add a new module... > >> There is just no way to avoid this other than making those > >> modules own > >> releases. But this does not work out neither (as seen on a few > >> other > >> projects I don't like to name). > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > >>> > >>> From: Romain Manni-Bucau > >>> To: Mark Struberg ; > >> dev@deltaspike.apache.org > >>> Sent: Monday, 11 November 2013, 20:54 > >>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >>> > >>> > >>> > >>> Well if code is released it should be stable or > >> explicitely in > >> alpha/beta..maybe we should do s
[jira] [Resolved] (DELTASPIKE-379) Provide an annotation equivalent to JSF @ViewScope but assignable to producer methods
[ https://issues.apache.org/jira/browse/DELTASPIKE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-379. - Resolution: Won't Fix fixed by jsf 2.2 itself (see javax.faces.view.ViewScoped) > Provide an annotation equivalent to JSF @ViewScope but assignable to producer > methods > - > > Key: DELTASPIKE-379 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-379 > Project: DeltaSpike > Issue Type: Improvement > Components: JSF-Module >Affects Versions: 0.4 >Reporter: Denis Forveille > > Tie the current JSF CDIfied ViewScope to a new annotation that can be used > for producers (@PageScope ?) to mimic Seam2 "Page Scope". > Current JSF @ViewScope annotation can only be set on types/classes. > Note that Seam 2 "PageScope" is different from CODI "ViewAccessScope". > ViewAccessScope live until there are no more referenced by ANY view. > PageScope object live in one and only one view until the view is > dismissed..) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (DELTASPIKE-456) wildfly-build-managed profile
[ https://issues.apache.org/jira/browse/DELTASPIKE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-456. - Resolution: Fixed > wildfly-build-managed profile > - > > Key: DELTASPIKE-456 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-456 > Project: DeltaSpike > Issue Type: Task > Components: Build >Affects Versions: 0.5 >Reporter: Gerhard Petracek >Assignee: Jozef Hartinger > Fix For: 0.6 > > > no build-managed profile was added with DELTASPIKE-408 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-508) @Transaction return NPE on qualified Datasource injections
[ https://issues.apache.org/jira/browse/DELTASPIKE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-508: Priority: Minor (was: Major) Fix Version/s: 0.7 Assignee: Mark Struberg Labels: (was: datasources transactions) a workaround exists -> priority minor > @Transaction return NPE on qualified Datasource injections > -- > > Key: DELTASPIKE-508 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-508 > Project: DeltaSpike > Issue Type: Bug > Components: JPA-Module >Affects Versions: 0.5 > Environment: Linux, JBoss-EAP-6.2, Java 7 >Reporter: Cloves J. G. Almeida >Assignee: Mark Struberg >Priority: Minor > Fix For: 0.7 > > > When using JTA transactions (and probably Resouce Local), a bean injecting a > qualified DataSource _without an EntityManager also being injected_ will fail > with an NPE if there's no default EntityManager or won't put the correct > datasource into the transaction (and fail or act inconsistently). > The reason is that in > org.apache.deltaspike.jpa.impl.transaction.TransactionStrategyHelper.resolveEntityManagerQualifiers > only injected EntityManagers are scanned for qualifiers used to resolve. > A workaround is to place a qualified EntityManager pointing to the same > datasource. This is limited, however. Some use cases, like batch processing > does not require an EntityManager and one might not be available. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-521) CDI CTL TCK fails on Windows/Weld 1.1.10
[ https://issues.apache.org/jira/browse/DELTASPIKE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902689#comment-13902689 ] Gerhard Petracek commented on DELTASPIKE-521: - it looks like an issue in combination with some jdk-versions, since it isn't a general issue on windows. > CDI CTL TCK fails on Windows/Weld 1.1.10 > > > Key: DELTASPIKE-521 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-521 > Project: DeltaSpike > Issue Type: Test >Reporter: John D. Ament >Assignee: John D. Ament > > Tests in error: > testRestartContexts(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest) > > testSimpleContainerBoot(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest): > WELD-001303 No active contexts for scope type > javax.enterprise.context.RequestS > coped > testContainerBoot(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest): > WELD- > 001303 No active contexts for scope type > javax.enterprise.context.RequestScoped > originally reported by Jean-Louis -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-521) CDI CTL TCK fails on Windows/Weld 1.1.10
[ https://issues.apache.org/jira/browse/DELTASPIKE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated DELTASPIKE-521: Reporter: Jean-Louis MONTEIRO (was: John D. Ament) > CDI CTL TCK fails on Windows/Weld 1.1.10 > > > Key: DELTASPIKE-521 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-521 > Project: DeltaSpike > Issue Type: Test >Reporter: Jean-Louis MONTEIRO >Assignee: John D. Ament > > Tests in error: > testRestartContexts(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest) > > testSimpleContainerBoot(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest): > WELD-001303 No active contexts for scope type > javax.enterprise.context.RequestS > coped > testContainerBoot(org.apache.deltaspike.cdise.tck.ContainerCtrlTckTest): > WELD- > 001303 No active contexts for scope type > javax.enterprise.context.RequestScoped > originally reported by Jean-Louis -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [DISCUSS] next release version? 0.6 or 1.0?
+1 for 0.6 and 1.0 as the next release after 0.6 2014-02-16 12:40 GMT+01:00 Ove Ranheim : > Dear DS team! > > Two months ago the team discussed a 0.6 release. What is your plan? There > are many new great features since 0.5, so what is stopping the DS-team to > provide a new release? > > Looking through the JIRA there are 30 open issues, many of them regards > JSF and Tests. I don't use JSF anymore, so it hurts to be held back by > stack-releases. > > 6 out of 30 are Improvements. > 7 are New Features. > 1 is a Wish of porting Seam Mail. Cody has discontinued development of > Seam Mail, so this issue could probably be Resolved/Won't fix. > > If you constrain the release window to only bug fixing it looks like 14 > issues should be moved to 0.7. > 16 issues are real issues that needs to be decided upon. > > Would it make sense to elect on some big tickets to get 0.6 out? > > 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be > a success, regular releases is a key factor. > > It's been five months since last 0.5 release. > > regards, > ove > > > On 12. nov. 2013, at 16:28, Mark Struberg wrote: > > > yea, but what are the alternatives? > > If you have a better idea, then tell us :) > > > > The problem is that it's not only about the JSF module but about all > other modules as well. > > > > LieGrue, > > strub > > > > > > > > > > - Original Message - > >> From: Gerhard Petracek > >> To: dev@deltaspike.apache.org > >> Cc: > >> Sent: Tuesday, 12 November 2013, 16:18 > >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >> > >> @mark: > >> i never said that we should do #2. > >> > >> regards, > >> gerhard > >> > >> > >> > >> > >> 2013/11/12 Mark Struberg > >> > >>> Pete, Gerhard > >>> > >>> The Problem here is that there are only 2 ways to handle the situation: > >>> > >>> 1.) all modules share the same version but have different maturity > grades > >>> > >>> 2.) each module has it's very own version. A 0.x reflects instability, > >> 1.x > >>> reflects maturity. But you know what happened with exactly this > approach in > >>> Seam3? The problem is that users do not know which version of > ds-jsf-api > >>> works together with which version of ds-core-impl for example. It gets > much > >>> more complicated with later modules. > >>> > >>> Thus I prefer 1.). > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > > From: Pete Muir > To: dev@deltaspike.apache.org > Sent: Tuesday, 12 November 2013, 14:35 > Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > > > +1 to Gerhard's point (I am looking to try to find someone to help > with > >>> docs, but the person I had in mind just left Red Hat :-(. Also +1 to > going > >>> to 1.0 soon (i.e. making docs and stability a priority!). > > > On 11 Nov 2013, at 23:09, Gerhard Petracek > >> > >>> wrote: > > > if we move to v1 soon, we need an useful versioning strategy, > >> better > >>> docs > > and examples + the api and spi need to be stable for some time (in > >> the > >>> best > > case until v2+). > > > > regards, > > gerhard > > > > > > > > 2013/11/11 Mark Struberg > > > >> > >> > >> how should that work? > >> > >> Please note that we will have some not perfectly finished > >> modules very > >> often. Basically whenever we add a new module... > >> There is just no way to avoid this other than making those > >> modules own > >> releases. But this does not work out neither (as seen on a few > >> other > >> projects I don't like to name). > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > >>> > >>> From: Romain Manni-Bucau > >>> To: Mark Struberg ; > >> dev@deltaspike.apache.org > >>> Sent: Monday, 11 November 2013, 20:54 > >>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? > >>> > >>> > >>> > >>> Well if code is released it should be stable or > >> explicitely in > >> alpha/beta..maybe we should do subreleases for unstables > >> modules > >>> Le 11 nov. 2013 18:43, "Mark Struberg" > >> a écrit : > >>> > >>> Oki folks, txs 4 the feedback, all! > > > I'd say we should create the > >> module-maturity-matrix.md first and > >>> then > >> we might do the version bump. > Maybe something like green/blue/orange/red for mature > >> / ready but > >>> still > >> needs a few features / ready but might change it's api > >> still / work in > >> progress > > > LieGrue, > strub > > > > > - Original Message - > > From: Charles Moulliard > > To: dev@deltaspike.apache.org > > Cc: Mark Struberg > > Sent: Monday, 11 November 2013, 18:25 > > Subject: Re: [DISCUS
Re: [DISCUSS] next release version? 0.6 or 1.0?
Dear DS team! Two months ago the team discussed a 0.6 release. What is your plan? There are many new great features since 0.5, so what is stopping the DS-team to provide a new release? Looking through the JIRA there are 30 open issues, many of them regards JSF and Tests. I don’t use JSF anymore, so it hurts to be held back by stack-releases. 6 out of 30 are Improvements. 7 are New Features. 1 is a Wish of porting Seam Mail. Cody has discontinued development of Seam Mail, so this issue could probably be Resolved/Won’t fix. If you constrain the release window to only bug fixing it looks like 14 issues should be moved to 0.7. 16 issues are real issues that needs to be decided upon. Would it make sense to elect on some big tickets to get 0.6 out? 15 months ago DS was proposed to be incubated. IMHO, if DS is going to be a success, regular releases is a key factor. It’s been five months since last 0.5 release. regards, ove On 12. nov. 2013, at 16:28, Mark Struberg wrote: > yea, but what are the alternatives? > If you have a better idea, then tell us :) > > The problem is that it's not only about the JSF module but about all other > modules as well. > > LieGrue, > strub > > > > > - Original Message - >> From: Gerhard Petracek >> To: dev@deltaspike.apache.org >> Cc: >> Sent: Tuesday, 12 November 2013, 16:18 >> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >> >> @mark: >> i never said that we should do #2. >> >> regards, >> gerhard >> >> >> >> >> 2013/11/12 Mark Struberg >> >>> Pete, Gerhard >>> >>> The Problem here is that there are only 2 ways to handle the situation: >>> >>> 1.) all modules share the same version but have different maturity grades >>> >>> 2.) each module has it's very own version. A 0.x reflects instability, >> 1.x >>> reflects maturity. But you know what happened with exactly this approach in >>> Seam3? The problem is that users do not know which version of ds-jsf-api >>> works together with which version of ds-core-impl for example. It gets much >>> more complicated with later modules. >>> >>> Thus I prefer 1.). >>> >>> LieGrue, >>> strub >>> >>> >>> >>> From: Pete Muir To: dev@deltaspike.apache.org Sent: Tuesday, 12 November 2013, 14:35 Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? +1 to Gerhard’s point (I am looking to try to find someone to help with >>> docs, but the person I had in mind just left Red Hat :-(. Also +1 to going >>> to 1.0 soon (i.e. making docs and stability a priority!). On 11 Nov 2013, at 23:09, Gerhard Petracek >> >>> wrote: > if we move to v1 soon, we need an useful versioning strategy, >> better >>> docs > and examples + the api and spi need to be stable for some time (in >> the >>> best > case until v2+). > > regards, > gerhard > > > > 2013/11/11 Mark Struberg > >> >> >> how should that work? >> >> Please note that we will have some not perfectly finished >> modules very >> often. Basically whenever we add a new module... >> There is just no way to avoid this other than making those >> modules own >> releases. But this does not work out neither (as seen on a few >> other >> projects I don't like to name). >> >> LieGrue, >> strub >> >> >> >> >> >>> >>> From: Romain Manni-Bucau >>> To: Mark Struberg ; >> dev@deltaspike.apache.org >>> Sent: Monday, 11 November 2013, 20:54 >>> Subject: Re: [DISCUSS] next release version? 0.6 or 1.0? >>> >>> >>> >>> Well if code is released it should be stable or >> explicitely in >> alpha/beta..maybe we should do subreleases for unstables >> modules >>> Le 11 nov. 2013 18:43, "Mark Struberg" >> a écrit : >>> >>> Oki folks, txs 4 the feedback, all! I'd say we should create the >> module-maturity-matrix.md first and >>> then >> we might do the version bump. Maybe something like green/blue/orange/red for mature >> / ready but >>> still >> needs a few features / ready but might change it's api >> still / work in >> progress LieGrue, strub - Original Message - > From: Charles Moulliard > To: dev@deltaspike.apache.org > Cc: Mark Struberg > Sent: Monday, 11 November 2013, 18:25 > Subject: Re: [DISCUSS] next release version? 0.6 >> or 1.0? > > +1 to move to 1.0. We have done the same thing >> with Apache Aries >>> moving > Blueprint from 0.5 to 1.0 release > > > > On Mon, Nov 11, 2013 at 6:17 PM, John D. Ament > wrote: > >> Yep, agreed. Users care about the version #. >> I
