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 strub...@yahoo.de 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 gerhard.petra...@gmail.com 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 strub...@yahoo.de 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 pm...@redhat.com 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 gerhard.petra...@gmail.com 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 strub...@yahoo.de 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 rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; 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 strub...@yahoo.de 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 ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de 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 john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi! In the last 2 months I did a few conference talks and smaller presentations (OpenBlend, W-JAX, ..) and always got the same questions: it's only a 0.x version, so is it already stable? I don't like to use it
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 oranh...@gmail.com: 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 strub...@yahoo.de 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 gerhard.petra...@gmail.com 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 strub...@yahoo.de 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 pm...@redhat.com 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 gerhard.petra...@gmail.com 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 strub...@yahoo.de 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 rmannibu...@gmail.com To: Mark Struberg strub...@yahoo.de; 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 strub...@yahoo.de 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 ch0...@gmail.com To: dev@deltaspike.apache.org Cc: Mark Struberg strub...@yahoo.de 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 john.d.am...@gmail.comwrote: Yep, agreed. Users care about the version #. I would recommend that if we could release a 1.0 based on the current code base + some additional bug fixes we'll get huge wins. +1 to switching current to 1.0.0-SNAPSHOT. On Mon, Nov 11, 2013 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi!
[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-tabpanelfocusedCommentId=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)
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 gerhard.petra...@gmail.com 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 oranh...@gmail.com: 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 strub...@yahoo.de wrote: I'd be +1 for 1.0 LieGrue, strub On Sunday, 16 February 2014, 14:52, Nicklas Karlsson nicka...@gmail.com 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 oranh...@gmail.com 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 strub...@yahoo.de 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 gerhard.petra...@gmail.com 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 strub...@yahoo.de 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
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 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 andraschko.tho...@gmail.com: +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 oranh...@gmail.com 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 gerhard.petra...@gmail.com 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 andraschko.tho...@gmail.com: +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
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 rmannibu...@gmail.comwrote: 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 rmannibu...@gmail.com: 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 jeano...@gmail.com: +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 thomas@gmail.com: 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
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 thomas@gmail.com: 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 rmannibu...@gmail.comwrote: 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 rmannibu...@gmail.com: 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 jeano...@gmail.com: +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 thomas@gmail.com: 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
