[jira] [Updated] (BVAL-101) Need a formal post-Incubator Build versioning and to include JSR 303 API jar
[ https://issues.apache.org/jira/browse/BVAL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BK Lau updated BVAL-101: Description: Since Apache BaVal has been voted to a top-level project, please release a post-Incubation Build number instead of continuing with 0.4 incubating to allow enterprise adoption and usage. May I suggest 1.0.0 to coincide with 0.4 incubating build? Also include a JSR 303 API jar since its missing from all incubator build. That way, user don't have to hunt it and download it from Oracle or JBoss site. was: Since Apache has been voted to a top-level project, please release a post-Incubation Build number instead of continuing with 0.4 incubating to allow enterprise adoption and usage. May I suggest 1.0.0 to coincide with 0.4 incubating build? Summary: Need a formal post-Incubator Build versioning and to include JSR 303 API jar (was: Need a formal post-Incubator Build versioning) Need a formal post-Incubator Build versioning and to include JSR 303 API jar - Key: BVAL-101 URL: https://issues.apache.org/jira/browse/BVAL-101 Project: BVal Issue Type: Bug Affects Versions: 0.4-incubating Reporter: BK Lau Labels: build, post-Incubating, release, versioning Since Apache BaVal has been voted to a top-level project, please release a post-Incubation Build number instead of continuing with 0.4 incubating to allow enterprise adoption and usage. May I suggest 1.0.0 to coincide with 0.4 incubating build? Also include a JSR 303 API jar since its missing from all incubator build. That way, user don't have to hunt it and download it from Oracle or JBoss site. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Logging API
+1 On Monday, March 19, 2012, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2012/3/19 Matt Benson gudnabr...@gmail.com Apparently the selection of slf4j might not suit everyone. While I am comfortable enough with its API (I prefer slf5j), it does cause us to impose downstream dependencies on our users that aren't really necessary. As an implementation of an EE specification it would be nice of us to impose dependencies, particularly ones that require a degree of manual intervention like slf4j, on our users only when absolutely necessary. We have 233 .java files in src/main folders, only 10 of which contain the String slf4j by which I guess that we are only logging a very small amount of information, in which case we might consider ourselves better citizens to simply use jul for BVal regardless of how we may feel about it in the context of implementing applications. Thoughts? Matt -- Sent from Gmail Mobile
Re: Logging API
yup, jul is shitty but better than having 3rd party deps. +1 LieGrue, strub - Original Message - From: Matthias Wessendorf mat...@apache.org To: dev@bval.apache.org dev@bval.apache.org Cc: Sent: Monday, March 19, 2012 8:46 PM Subject: Re: Logging API +1 On Monday, March 19, 2012, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2012/3/19 Matt Benson gudnabr...@gmail.com Apparently the selection of slf4j might not suit everyone. While I am comfortable enough with its API (I prefer slf5j), it does cause us to impose downstream dependencies on our users that aren't really necessary. As an implementation of an EE specification it would be nice of us to impose dependencies, particularly ones that require a degree of manual intervention like slf4j, on our users only when absolutely necessary. We have 233 .java files in src/main folders, only 10 of which contain the String slf4j by which I guess that we are only logging a very small amount of information, in which case we might consider ourselves better citizens to simply use jul for BVal regardless of how we may feel about it in the context of implementing applications. Thoughts? Matt -- Sent from Gmail Mobile
Re: Are we ready for a 1.0 release candidate?
+1 regards, gerhard 2012/3/19 Mark Struberg strub...@yahoo.de yup 0.4 is fine as well. I'd even say 0.8 or 0.9 is better ;) LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: dev@bval.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, March 19, 2012 8:12 PM Subject: Re: Are we ready for a 1.0 release candidate? G erhard pointed out to me that there may be other items we want to look at (e.g. Apache* classnames) in addition to the logging discussion before we call our implementation baked enough for 1.0. I tend to agree with him and will proceed with 0.4 to be followed with a 1.0 in the near future, unless anyone disagrees. Matt On Tue, Mar 13, 2012 at 12:22 PM, Mark Struberg strub...@yahoo.de wrote: Folks this logging discussion sucks ^^ Ok, not the _discussion_ sucks, the topic does ;) We need this stuff over and over again, and I really do think this loudly cries out for a commons-logging-2 or so. I already wrote this to the commons list, because we have this discussion over and over again on various projects. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@bval.apache.org Cc: Sent: Tuesday, March 13, 2012 6:18 PM Subject: Re: Are we ready for a 1.0 release candidate? hi matt, +1! for a release, but i'm not sure if we should call it v1.0 already (if i remember correctly, we still don't have an agreement e.g. about the logging framework). regards, gerhard 2012/3/13 Matt Benson gudnabr...@gmail.com Subject says it all. Some of our other Apache TLPs would like to see us make a release. It's been a long time since 0.3-incubating, and 1.0 would be a great way to inaugurate the project after having moved to TLP. Matt
Re: Are we ready for a 1.0 release candidate?
+1 for the 0.4 release first and then go for the 1.0 On Mon, Mar 19, 2012 at 9:01 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2012/3/19 Mark Struberg strub...@yahoo.de yup 0.4 is fine as well. I'd even say 0.8 or 0.9 is better ;) LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: dev@bval.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Monday, March 19, 2012 8:12 PM Subject: Re: Are we ready for a 1.0 release candidate? G erhard pointed out to me that there may be other items we want to look at (e.g. Apache* classnames) in addition to the logging discussion before we call our implementation baked enough for 1.0. I tend to agree with him and will proceed with 0.4 to be followed with a 1.0 in the near future, unless anyone disagrees. Matt On Tue, Mar 13, 2012 at 12:22 PM, Mark Struberg strub...@yahoo.de wrote: Folks this logging discussion sucks ^^ Ok, not the _discussion_ sucks, the topic does ;) We need this stuff over and over again, and I really do think this loudly cries out for a commons-logging-2 or so. I already wrote this to the commons list, because we have this discussion over and over again on various projects. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@bval.apache.org Cc: Sent: Tuesday, March 13, 2012 6:18 PM Subject: Re: Are we ready for a 1.0 release candidate? hi matt, +1! for a release, but i'm not sure if we should call it v1.0 already (if i remember correctly, we still don't have an agreement e.g. about the logging framework). regards, gerhard 2012/3/13 Matt Benson gudnabr...@gmail.com Subject says it all. Some of our other Apache TLPs would like to see us make a release. It's been a long time since 0.3-incubating, and 1.0 would be a great way to inaugurate the project after having moved to TLP. Matt -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: Logging API
+1, we (OpenEJB ;)) are waiting bval and owb and clearly next release can be a first step before THE release :). - Romain 2012/3/19 Matt Benson gudnabr...@gmail.com On Mon, Mar 19, 2012 at 3:19 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: +1 I want to volunteer to do it I have not done anything for BVal since its start. Great, thanks! As per the release of 0.4 I think this would be something we need to put it in there. Is there any rough estimate on when we need to cut the 0.4 release ? As far as I know our friends at OpenEJB want to include our next release in a new version of TomEE, and may be blocked waiting. In the interest of community I'd like to give it to them ASAP, but I don't personally consider the logging issue to be a blocker to 0.4, depending on your schedule. Matt On Mon, Mar 19, 2012 at 8:50 PM, Mark Struberg strub...@yahoo.de wrote: yup, jul is shitty but better than having 3rd party deps. +1 LieGrue, strub - Original Message - From: Matthias Wessendorf mat...@apache.org To: dev@bval.apache.org dev@bval.apache.org Cc: Sent: Monday, March 19, 2012 8:46 PM Subject: Re: Logging API +1 On Monday, March 19, 2012, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2012/3/19 Matt Benson gudnabr...@gmail.com Apparently the selection of slf4j might not suit everyone. While I am comfortable enough with its API (I prefer slf5j), it does cause us to impose downstream dependencies on our users that aren't really necessary. As an implementation of an EE specification it would be nice of us to impose dependencies, particularly ones that require a degree of manual intervention like slf4j, on our users only when absolutely necessary. We have 233 .java files in src/main folders, only 10 of which contain the String slf4j by which I guess that we are only logging a very small amount of information, in which case we might consider ourselves better citizens to simply use jul for BVal regardless of how we may feel about it in the context of implementing applications. Thoughts? Matt -- Sent from Gmail Mobile -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
[jira] [Created] (BVAL-102) Convert Apache* classnames in BVal to BVal*
Convert Apache* classnames in BVal to BVal* --- Key: BVAL-102 URL: https://issues.apache.org/jira/browse/BVAL-102 Project: BVal Issue Type: Task Components: jsr303 Affects Versions: 0.3-incubating Reporter: Matt Benson Unless anyone else prefers a different nomenclature, but Apache* is probably a little too broad. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (BVAL-103) switch BVal from slf4j to java.util.logging
switch BVal from slf4j to java.util.logging --- Key: BVAL-103 URL: https://issues.apache.org/jira/browse/BVAL-103 Project: BVal Issue Type: Task Affects Versions: 0.3-incubating Reporter: Matt Benson Assignee: Mohammad Nour Team consensus seems to go that the convenience of slf4j for the bval team doesn't justify the potential inconvenience for users, given the slight amount of logging we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
