Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
On Wed, Dec 9, 2009 at 11:54 PM, Jörg Schaible joerg.schai...@gmx.de wrote: Paul Benedict wrote at Mittwoch, 9. Dezember 2009 20:16: I hope to see org.apache.commons:commons-lang:3.0 No, not if it is no longer backwards compatible to 2.0 APIs. 2.0 is: commons-lang:commons-lang:3.0. So it'll be a change of groupId and you could put both in the same pom without issues (afaik). Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
Ted Dunning wrote: Similarly, https://issues.apache.org/jira/browse/MATH-310 had code from a contributor and got totally shot down basically with We don't care what you think, we don't want it. Extensive attempts on my part to find common ground just got shot down by Phil with -1 and essentially no more discussion than don't like it. Sorry you feel that way. My objections were to the design, not in any way personal or dismissive. I did indicate alternative ways to get the desired functionality implemented. I also explained, I think, pretty clearly why I did not like it and I stand behind my comments. Phil Mahout has some unusual requirements and definitely can't use Math as is. It is also fast moving and needs changes to actually happen. The experience has been that only totally trivial non-changes get accepted ( https://issues.apache.org/jira/browse/MATH-267 and https://issues.apache.org/jira/browse/MATH-222 are examples). Anything more interesting seems to get bogged down in NIH or endless alternations of not-now we are about to have a major release and can't be distracted and not-now because we aren't doing a major release and have stay compatible. On Wed, Dec 9, 2009 at 11:58 AM, Jake Mannix jake.man...@gmail.com wrote: On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.com wrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All
Re: [dbcp] 1.3/1.4 RC1 available for review
Jörg Schaible wrote: Hi Phil, Phil Steitz wrote: I have prepared release candidates for DBCP 1.3 and 1.4. Please all interested parties have a look and test. If all goes well, I will kick off a release VOTE based on these artifacts in the next couple of days. I see these as really two sets of artifacts associated with one release, so I am inclined to just do one VOTE including both versions. If anyone disagrees with this, please speak up. I am happy to run two VOTEs. 1.3 (JDBC 3) version: http://people.apache.org/~psteitz/dbcp-1.3-rc1 http://people.apache.org/~psteitz/dbcp-1.3-rc1/site http://people.apache.org/~psteitz/dbcp-1.3-rc1/maven http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_3_RC1/ Like Nial I changed geronimo-jta_1.1_spec to version 1.1. My compiler zoo fails though for blackdown-jdk-1.4.2.03, jrockit-jdk-1.4.2.16 and sun- jdk-1.4.2.19. IMHO you must update the xerces version to a release that contains the driver implementation in the Java-SPI (META-INF/services): Thanks, Jorg. I really appreciate your running this through the zoo. Can you identify a suitable Xerces version? I am going to make this and the jta spec change and cut another RC. Thanks all for testing. Phil == % Test set: org.apache.commons.jocl.TestJOCLContentHandler --- Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.047 sec FAILURE! testObject(org.apache.commons.jocl.TestJOCLContentHandler) Time elapsed: 0.006 sec testPrimitives(org.apache.commons.jocl.TestJOCLContentHandler) Time elapsed: 0 sec testParse(org.apache.commons.jocl.TestJOCLContentHandler) Time elapsed: 0.028 sec ERROR! org.xml.sax.SAXException: System property org.xml.sax.driver not specified at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:90) at org.apache.commons.jocl.JOCLContentHandler.parse(JOCLContentHandler.java:339) at org.apache.commons.jocl.JOCLContentHandler.parse(JOCLContentHandler.java:271) at org.apache.commons.jocl.TestJOCLContentHandler.testParse(TestJOCLContentHandler.java:255) == % Using IBM-JDK 1.4.2.13 the build and all tests with Ant 1.6.5 succeed, but I get nevertheless those exceptions, I do not see, when running the other JDKs with Maven: == % [junit] org.apache.commons.dbcp.AbandonedTrace$AbandonedObjectException: DBCP object created 2009-12-08 23:03:07 by the following code was never closed: [junit] at org.apache.commons.dbcp.AbandonedTrace.setStackTrace(AbandonedTrace.java:138) [junit] at org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:81) [junit] at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) [junit] at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044) [junit] at org.apache.commons.dbcp.TestAbandonedBasicDataSource.testAbandoned(TestAbandonedBasicDataSource.java:65) == % == % [junit] org.apache.commons.dbcp.AbandonedTrace$AbandonedObjectException: DBCP object created 2009-12-08 23:03:07 by the following code was never closed: [junit] at org.apache.commons.dbcp.AbandonedTrace.setStackTrace(AbandonedTrace.java:138) [junit] at org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:81) [junit] at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) [junit] at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044) [junit] at org.apache.commons.dbcp.TestBasicDataSource.getConnection(TestBasicDataSource.java:44) [junit] at org.apache.commons.dbcp.TestAbandonedBasicDataSource.testAbandonedClose(TestAbandonedBasicDataSource.java:75) == % == % [junit] org.apache.commons.dbcp.AbandonedTrace$AbandonedObjectException: DBCP object created 2009-12-08 23:03:07 by the following code was never closed:
Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
On Thu, Dec 10, 2009 at 11:29 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Dec 9, 2009 at 11:54 PM, Jörg Schaible joerg.schai...@gmx.de wrote: Paul Benedict wrote at Mittwoch, 9. Dezember 2009 20:16: I hope to see org.apache.commons:commons-lang:3.0 No, not if it is no longer backwards compatible to 2.0 APIs. 2.0 is: commons-lang:commons-lang:3.0. So it'll be a change of groupId and you could put both in the same pom without issues (afaik). Maven and how its organised is irrelevant - its what you need in your classpath that matters and if you have different dependencies requiring different versions that are incompatible then you're in trouble if they share the same package names. Niall Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Lang package name change. Was: [(LANG-561) unescapeHtml has been dropped without going through deprecation]
On Thu, Dec 10, 2009 at 11:53 AM, Niall Pemberton niall.pember...@gmail.com wrote: On Thu, Dec 10, 2009 at 11:29 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Dec 9, 2009 at 11:54 PM, Jörg Schaible joerg.schai...@gmx.de wrote: Paul Benedict wrote at Mittwoch, 9. Dezember 2009 20:16: I hope to see org.apache.commons:commons-lang:3.0 No, not if it is no longer backwards compatible to 2.0 APIs. 2.0 is: commons-lang:commons-lang:3.0. So it'll be a change of groupId and you could put both in the same pom without issues (afaik). Maven and how its organised is irrelevant - its what you need in your classpath that matters and if you have different dependencies requiring different versions that are incompatible then you're in trouble if they share the same package names. Doh, forget this, had a brain fart. I agree :) Niall Niall Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] Closed: (LANG-392) Improve javadoc samples
On 10/12/2009, Henri Yandell (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/LANG-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-392. -- Resolution: Fixed Fix Version/s: (was: 3.0) I'm closing this as WONTFIX. It's very desirable, but no one has done anything on the subject and I don't see us considering this a release blocker. Most importantly - nothing points to which samples most need improving. Surely LATER would be better in this case? Improve javadoc samples --- Key: LANG-392 URL: https://issues.apache.org/jira/browse/LANG-392 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell This was in the STATUS.html. The first step would seem to be to identify the javadoc that is missing example code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jira] Closed: (LANG-392) Improve javadoc samples
On Thu, Dec 10, 2009 at 4:04 AM, sebb seb...@gmail.com wrote: On 10/12/2009, Henri Yandell (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/LANG-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-392. -- Resolution: Fixed Fix Version/s: (was: 3.0) I'm closing this as WONTFIX. It's very desirable, but no one has done anything on the subject and I don't see us considering this a release blocker. Most importantly - nothing points to which samples most need improving. Surely LATER would be better in this case? It's a Bugzilla import status - I've never looked at LATER issues in JIRA :) My general thinking is that we'll deal with issues on an individual basis - i.e. their own JIRA issues, rather than an optimistic make things nicer type ticket. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
Btw, useful link that shows you the patches (or at least attachments) you currently have on open tickets: https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=-1issueStatus=openselectedProjectId=12310485reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=Next On Wed, Dec 9, 2009 at 12:46 PM, Luc Maisonobe luc.maison...@free.fr wrote: Jake Mannix a écrit : On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.comwrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. I had these patches in my backlog and considered them accepted. I should have commited them before, sorry for that. I'll take care of them right now. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. The discussion was not entirely hostile as we get some intermediate consensus at some points. I understand your feelings after several patches that did not get committed fast enough. Please accept my apologizes for this. Luc In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have probably seen have been rather silent since 2.0 release. For my part, I really, really need help. I would like to fix the problems in the eigen decomposition and
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
Luc Maisonobe wrote: Jake Mannix a écrit : On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.comwrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. I had these patches in my backlog and considered them accepted. I should have commited them before, sorry for that. I'll take care of them right now. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. The discussion was not entirely hostile as we get some intermediate consensus at some points. I understand your feelings after several patches that did not get committed fast enough. Please accept my apologizes for this. I have to apologize as well here for lack of cycles to help get [math] patches in recently. That should improve shortly. Phil Luc In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have probably seen have been rather silent since 2.0 release. For my part, I really, really need help. I would like to fix the problems in the eigen decomposition and SVD but need a good kick to get on it, and having only requests and no help is not really motivating. Luc If that problem were solved, then it would be great to depend on commons math. If that problem isn't solved, then there
Re: [math] getting changes included into commons-math (was Re: Home for the colt fork)
Jake Mannix wrote: On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies bimargul...@gmail.comwrote: This is interesting. We have a raft of mathematically qualified committers on Mahout, and this message asking for help on commons-math, and a raft of code marooned at mahout that wants to be in commons math. If I were one of those mathematically competant individuals, I'd be off attaching a patch or three to a JIRA or two The commons-math linear APIs have been described as effectively locked until 3.0, due to back-compat requirements. This means that any code contributed into c-math would live in a parallel (no pun intended) to the linear primitives which exist already in there. Adopting something like MTJ or Colt in Mahout turned out to be easier, because we are on release 0.2 (heading for 0.3 now), and have less stringent back-compat requirements, so we are overhauling our linear apis (read: even user-facing interface changes) to take advantage of useful parts of Colt, and are planning on using our Colt fork as the underlying implementation. Commons-math expressed that changing linear APIs is not something they can do, given the maturity of their library, so where would Colt *go* in c-math? It's own submodule, having its own eigendecompositions and svd and so forth, running parallel to the current c-math impls? Why? Who would maintain it and write tests for it, and how do you explain to end-users which they should use? On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe luc.maison...@free.fr wrote: Ted Dunning a écrit : Actually, the reason that we have Colt in Mahout is it has proven impossible to get changes into commons math. We really, really wanted to use commons math rather than have our own linear algebra package, but it just proved impossible and we didn't want to wait forever. If you really, really wants to use commons math and want changes to be included, contribute them. I have submitted patches for the following tickets: MATH-312 (and acceptance of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none of which have appear to have had much progress on. All of my patches come with unit tests for new functionality. On the other hand, when I opened the discussion about extending the functions package to enable composable functions (MATH-313), I got an entirely hostile response, which only tempered as far as +0 on adding it after discussion. In particular, my first step at making commons-math something Mahout could standardize on for linear work was MATH-312, which I did submit a patch for, and revised it many times after discussion about what is acceptable practice in c-math. Not yet applied, months later. It's probably far out of date now... Similarly, when I tried to ask what the status on decisions on whether to adopt MTJ or Colt, the statement by Phil was basically that commons-math would not adopt anything which had any external dependencies or not-easily-human-readable java source (which ruled out MTJ because of f2j produced code), and which had to be fully tested and maintained prior to adoption (which rules out Colt which has no unit tests yet). We agreed early on that commons-math was going to be self-contained. It is fine to reopen that discussion. I stated my opinion, which is to stay away from *required* external dependencies. I have been wrong before, and will be wrong again. Clear arguments can enlighten me. I also feel obligated to support the code that we ship. Others may disagree with this and feel that it is OK to ship code that we - the committers voting on the release - cannot debug or understand. It will take some very enlightening arguments to get me to agree to releasing code that I can't understand. Regarding unit tests, the answer is simple - volunteer to write them and include them in patches. Code without unit tests is not complete code. If I commit it, it means that *I* am going to have to write the unit tests and I am going to do that before committing. Patches without unit tests will therefore take longer to commit. Phil Ted and I weren't making requests for other people to do work, we were wondering whether even offers to do some of the work would be accepted, and for many of the questions/suggestions we had, it seems the desires and requirements of the Mahout community were incompatible with those of commons-math. -jake I think the only change that was proposed and not done because of lack of consensus was the inclusion of MTJ (and I don't consider the discussion closed on that topic either, so it may still happen some day). All the other changes that are desired are simply lacking someone to do the work. There were proposals to extend the linear algebra API, proposals to add more support for sparse matrices, proposals to get partial decomposition ... But sparse contributions (pun intended). I try to do what I can, but as you have
Re: [VOTE] Apache Commons to sponsor agimatec-validation incunbation
OK, I'll kick-off the discussion later today. -Donald Niall Pemberton wrote: On Wed, Dec 9, 2009 at 12:35 PM, Donald Woods dwo...@apache.org wrote: Sorry guys. Guess using my Yahoo mail and Thunderbird for list subscriptions was a bad idea I've been seeing other posts to the d...@commons list and directly to me, but none about this thread until today for some reason Niall, let me know if you need any help collecting the source tar to post with the SGA. I have checked the foundation records and found the SGA (its recorded now as keba-agimatec.pdf). I don't think we need to do anything with the source until the proposal has been accepted by the incubator. So the next thing is to post the proposal to gene...@incubator. Give an opportunity for discussion - once thats complete then call a vote. I was hoping you would do that, but if not then I can. Niall Thanks, Donald Niall Pemberton wrote: On Wed, Dec 9, 2009 at 12:03 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Dec 7, 2009, at 9:00 PM, Niall Pemberton wrote: On Mon, Dec 7, 2009 at 8:16 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: So Niall, whats next and please if there is anything I can help in let me know about it. I was waiting for Donald to take the lead. Hes posted a couple of message about the vote which I responded to but he doesn't seem to be around much. Its ready AFAIC to post the proposal to gene...@incubator. I think Donald must be having subscription problems with this mailing list. Don't think he's seen either response (or the other notes). I've nudged him off-list. I tried that and got no response :( Niall --kevan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r889313 - in /commons/proper/jexl/trunk: pom.xml xdocs/index.xml
On 10/12/2009, hen...@apache.org hen...@apache.org wrote: Author: henrib Date: Thu Dec 10 16:30:31 2009 New Revision: 889313 URL: http://svn.apache.org/viewvc?rev=889313view=rev Log: documentation fixes; bsf beta3 as dependency Why have you reverted to BSF beta3? Modified: commons/proper/jexl/trunk/pom.xml commons/proper/jexl/trunk/xdocs/index.xml Modified: commons/proper/jexl/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/jexl/trunk/pom.xml?rev=889313r1=889312r2=889313view=diff == --- commons/proper/jexl/trunk/pom.xml (original) +++ commons/proper/jexl/trunk/pom.xml Thu Dec 10 16:30:31 2009 @@ -106,7 +106,7 @@ dependency groupIdorg.apache.bsf/groupId artifactIdbsf-api/artifactId -version3.0/version +version3.0-beta3/version scopecompile/scope /dependency /dependencies Modified: commons/proper/jexl/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/commons/proper/jexl/trunk/xdocs/index.xml?rev=889313r1=889312r2=889313view=diff == --- commons/proper/jexl/trunk/xdocs/index.xml (original) +++ commons/proper/jexl/trunk/xdocs/index.xml Thu Dec 10 16:30:31 2009 @@ -90,8 +90,8 @@ a href=apidocs/org/apache/commons/jexl2/JexlContext.htmlJexlContext/a. An Expression is created using a href=apidocs/org/apache/commons/jexl2/JexlEngine.html#createExpression(java.lang.String)JexlEngine#createExpression()/a, -passing a String containing valid JEXL syntax. A JexlContext can be created using a -a href=apidocs/org/apache/commons/jexl2/MapContext.htmlnew MapContext.Mapped()/a; +passing a String containing valid JEXL syntax. A simple JexlContext can be created by instantiating a +a href=apidocs/org/apache/commons/jexl2/MapContext.htmlMapContext/a; a map of variables that will be internally wrapped can be optionally provided through its constructor. The following example, takes a variable named foo, and invokes the bar() method on the property innerFoo: /p - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r889313 - in /commons/proper/jexl/trunk: pom.xml xdocs/index.xml
Because 'mvn site' fails otherwise; the repo seems to only publish
beta{1,2,3}.
This occurred on the 2 environments I'm using (Mac WinXP).
sebb-2-2 wrote:
...
Why have you reverted to BSF beta3?
...
--
View this message in context:
http://n4.nabble.com/Re-svn-commit-r889313-in-commons-proper-jexl-trunk-pom-xml-xdocs-index-xml-tp957142p957232.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] bsf-api dependency version (was: svn commit: r889313 ...)
On Thu, Dec 10, 2009 at 1:03 PM, henrib hen...@apache.org wrote:
Because 'mvn site' fails otherwise; the repo seems to only publish
beta{1,2,3}.
This occurred on the 2 environments I'm using (Mac WinXP).
snip/
Right, the build will fail since 3.0 isn't in the m2 repos [1, 2].
I remembered a related discussion so I went back to the archives,
there was a vote [3] on the corresponding m2 repo artifacts about a
month back, I will ping the bsf list for status.
-Rahul
[1]
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/bsf/bsf-api/
[2] http://repo2.maven.org/maven2/org/apache/bsf/bsf-api/
[3] http://markmail.org/message/hudungthcgoykr2l
sebb-2-2 wrote:
...
Why have you reverted to BSF beta3?
...
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r889313 - in /commons/proper/jexl/trunk: pom.xml xdocs/index.xml
On 10/12/2009, henrib hen...@apache.org wrote:
Because 'mvn site' fails otherwise; the repo seems to only publish
beta{1,2,3}.
This occurred on the 2 environments I'm using (Mac WinXP).
I see. I think we need to wait until this is sorted (hopefully only a few days).
sebb-2-2 wrote:
...
Why have you reverted to BSF beta3?
...
--
View this message in context:
http://n4.nabble.com/Re-svn-commit-r889313-in-commons-proper-jexl-trunk-pom-xml-xdocs-index-xml-tp957142p957232.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
where is dbcp-1.4RC1 repository?
hi all: I need run dbcp-1.4RC1 by maven in OSGi envirement. Please tell me where I can get it. what is dbcp-1.4 release schedule? thanks!
Re: where is dbcp-1.4RC1 repository?
tommy wang wrote at Freitag, 11. Dezember 2009 06:17: hi all: I need run dbcp-1.4RC1 by maven in OSGi envirement. Please tell me where I can get it. It's not an official release, therefore it's not publicly available anywhere. You can build it from the tagged source if you really want to use it. what is dbcp-1.4 release schedule? Depends on Phils schedule, but it might very well happen this year. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
Hi Phil, Phil Steitz wrote at Donnerstag, 10. Dezember 2009 12:42: Jörg Schaible wrote: Hi Phil, Phil Steitz wrote: I have prepared release candidates for DBCP 1.3 and 1.4. Please all interested parties have a look and test. If all goes well, I will kick off a release VOTE based on these artifacts in the next couple of days. I see these as really two sets of artifacts associated with one release, so I am inclined to just do one VOTE including both versions. If anyone disagrees with this, please speak up. I am happy to run two VOTEs. 1.3 (JDBC 3) version: http://people.apache.org/~psteitz/dbcp-1.3-rc1 http://people.apache.org/~psteitz/dbcp-1.3-rc1/site http://people.apache.org/~psteitz/dbcp-1.3-rc1/maven http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_3_RC1/ Like Nial I changed geronimo-jta_1.1_spec to version 1.1. My compiler zoo fails though for blackdown-jdk-1.4.2.03, jrockit-jdk-1.4.2.16 and sun- jdk-1.4.2.19. IMHO you must update the xerces version to a release that contains the driver implementation in the Java-SPI (META-INF/services): Thanks, Jorg. I really appreciate your running this through the zoo. Can you identify a suitable Xerces version? Actually I tried that yesterday. I've upgraded to xercesImpl-2.9.1 that contains the SPI entry for sure, but the test still fails. After looking into the code I've seen that the test explicitly sets the system property already. Even after moving that code from constructor into setUp the failure still occurs. This left be somewhat baffled, but I ran out of time to have a further look :-/ I am going to make this and the jta spec change and cut another RC. Thanks all for testing. Did you also see those: [snip] I do not see those using IBM-JDK 1.5.0.10. With this I had a casually 1 failure, but no test reports are generated with Ant nor could I see on the console which test actually failed. Is there a failure in the Ant build that prevents the junit reports to be written? Additionally the Ant build filters-out the JDBC4 stuff ?!? I thought it's not there in 1.3. Simply wondering, nothing serious. [snip] 1.4 (JDBC 4) version: http://people.apache.org/~psteitz/dbcp-1.4-rc1 http://people.apache.org/~psteitz/dbcp-1.4-rc1/site http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 and Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it fails with IBM 1.6.0.6: == % --- Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource --- Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.398 sec FAILURE! testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) Time elapsed: 0.066 sec FAILURE! junit.framework.AssertionFailedError: Expecting SQLException - XAResources orphaned at junit.framework.Assert.fail(Assert.java:47) at org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) == % Seems that the IBM JDK is behaving differently. The build setup itself looks good though, except a minor nit: == % [WARNING] While downloading xml-apis:xml-apis:2.0.2 This artifact has been relocated to xml-apis:xml-apis:1.0.b2. == % xml-apis-2.0.2 is simply a wrong release and we should refer the correct one. I've replaced it with the latest release 1.3.04. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
