Re: svn commit: r553201 - /jakarta/commons/trunks-proper/KEYS
Please do.. Mvgr, Martin Dennis Lundberg wrote: Do I also need to copy the new KEYS file to http://www.apache.org/dist/jakarta/commons/KEYS ? [EMAIL PROTECTED] wrote: Author: dennisl Date: Wed Jul 4 06:31:14 2007 New Revision: 553201 URL: http://svn.apache.org/viewvc?view=revrev=553201 Log: Adding my key. Modified: jakarta/commons/trunks-proper/KEYS Modified: jakarta/commons/trunks-proper/KEYS URL: http://svn.apache.org/viewvc/jakarta/commons/trunks-proper/KEYS?view=diffrev=553201r1=553200r2=553201 == --- jakarta/commons/trunks-proper/KEYS (original) +++ jakarta/commons/trunks-proper/KEYS Wed Jul 4 06:31:14 2007 @@ -1247,3 +1247,39 @@ G1bNzA4f =R1FQ -END PGP PUBLIC KEY BLOCK- +pub 1024D/AF5EC452 2006-08-25 +uid Dennis Lundberg (CODE SIGNING KEY) [EMAIL PROTECTED] +sig 3AF5EC452 2006-08-25 Dennis Lundberg (CODE SIGNING KEY) [EMAIL PROTECTED] +sub 2048g/73A843C2 2006-08-25 +sig AF5EC452 2006-08-25 Dennis Lundberg (CODE SIGNING KEY) [EMAIL PROTECTED] + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.4.6 (MingW32) + +mQGiBETvOwgRBADbar1BLaiJnuVnDEg0aej0Q01fdOnMB8e9fxe3TJZ266LLGljS +FNekCafvn52nx1KyVvkgdgMxqBfw70FKQXdrBBMzowuVAz1ZAcpDjkXeyKa3n/iW +J7VtuhdhIE/+rUiE1go2vkQhdIaad8om/kQDsovbgqxfX6eU2hWL51bJZwCg59D5 +0lXm78y8dlbvGaW0EVdgBesEAJ6rcNAA6rjsi7BUXNIpZe+KF/G/slcLJETgylmw +g0vquZP7n0fVhZZqB68zSmTcukxo36rd0jr9eSlhPj/6j9xs7gpk/UFWLWsziZDO +7kZVLv58v6ktK1Dk8u0F9o75pDBjgxOGR7VPVTblur1dIJ+U14ffJ9fn6wzKY8hx +hZrgA/wIpuJ/aSSns2ccKsErDMPRJP/TGygvrb1Mpfk3tLeGF7owI0sL8L8adKMK +g9kT/8VFoLzeSeEwUDOKDVm2xB/A5pazoUcgxLdwYs6g/XJzA7y4Sbfcac2W5IZ0 +4WGGUobf5Gp/b3NeVuff+V/2UN1YIr/hlOnBOMQDlNie4loQhrQ3RGVubmlzIEx1 +bmRiZXJnIChDT0RFIFNJR05JTkcgS0VZKSA8ZGVubmlzbEBhcGFjaGUub3JnPohg +BBMRAgAgBQJE7zsIAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQM81nM69e +xFLJMQCdF7zrx4SMk6JW9nZSTwHvMR3eNsYAmgKCy/Yq08tAIn9HSddspNIBeXpS +uQINBETvOyQQCACL7yutx3rvWz+FiUfeaA209uZvopjbVrE4oiTCrBV0Wgbmds7l +Kyxb3136dqPpQMn7H6ZsXzNNv7S4WASceWuGMndw5LO5I9nZRj7lfUYmfq2Qc3h7 +2SfJDOgAUo2gJudgfNsyQQTIqnOIPNzIC4UcQqnUmgeFcPjrl5f1v9EVxJppeaO2 +2IafxuMaGACJFcPkYA/8EuQP6dbSmxNstOtoncY/69WRrWTCcM3SLvK+m91KOe02 +LnGz62WMC149uziiBZAF5BXfEUPsbBp1WEf/fIdGUhK4RQ1E78MwrhgWwNiNT7No +EuT6UORrfxCcAiNBjGF7x7KkHwS6I5qsNTd3AAMFB/4oFl87H+IK+49xXcsWJSx4 +04BsXrFFuYCglqqXEjLcTx9fSiK4Sng5UfPxTTYEuwG0fgsimISPb+DIQvHQ/bka +FLdLlS1+Q29wbYB81k602VZbjQYjqCPYrHImo5pcCR9b5Zw8muB36Af70mknNV+h +MnKqSrqvrWvpQ2iBAjaeuGug+O/bblPIDzEW5PJKF2FGjRagw/y2pnEOJZewbN0V +yI9osncY/B69VPh0KlsK9HZceH+9W7K3ALanzg79auH1NShPfld7q9jbOSAaD1p2 +Fd2PjswNkbQFaoWzhMJv7J9Dg9nEuBx09pPNvf2b1mP15IhOdt1nRmhAoheSn9ys +iEkEGBECAAkFAkTvOyQCGwwACgkQM81nM69exFINlgCeJWEyBlANuDYAZ3uxYEC9 +MrUXwYoAnjCUFpe/kmx0wzIm9Bz7G2NeDs5U +=OmtA +-END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r553201 - /jakarta/commons/trunks-proper/KEYS
Doesn't it contain a note on top ? Mvgr, Martin sebb wrote: Might be worth adding a suitable note to the file ? On 04/07/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Please do.. Mvgr, Martin Dennis Lundberg wrote: Do I also need to copy the new KEYS file to http://www.apache.org/dist/jakarta/commons/KEYS ? ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r553201 - /jakarta/commons/trunks-proper/KEYS
Damned.. Read it wrong.. I read it like copy the new key instead of KEYS file.. (although could mean the same in this case). It should probably be on the release page where you need to add your key to which KEYS files, in what directories and why :). Mvgr, Martin sebb wrote: Yes, but the note does not say where to copy the file after it has been updated... On 04/07/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Doesn't it contain a note on top ? Mvgr, Martin sebb wrote: Might be worth adding a suitable note to the file ? On 04/07/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Please do.. Mvgr, Martin Dennis Lundberg wrote: Do I also need to copy the new KEYS file to http://www.apache.org/dist/jakarta/commons/KEYS ? ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorganising JIRA - Switching to new category
Done.. Mvgr, Martin Martin van den Bemt wrote: If no one objects I will create a new category in JIRA called commons and move all commons projects under that category.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorganising JIRA - Switching to new category
Also renamed the notification scheme.. Mvgr, Martin Martin van den Bemt wrote: Done.. Mvgr, Martin Martin van den Bemt wrote: If no one objects I will create a new category in JIRA called commons and move all commons projects under that category.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509265 ] Martin van den Bemt commented on BEANUTILS-285: --- The problem you are describing is actually the current behaviour of betwixt and beanutils. People depend on that and if it was not working for them, there is documentation on how to solve that problem. So if people want to do what you describe they already need to work around that. Based on above I am not creating more issues than I am resolving, I am just making sure everything works as it always did. That the solution in the trunk of beanutils solves a lot of other possible problems (or prevents usage of hacks) and is an improvement over current behaviour, is a different rationale altogether. I am not saying your changes aren't an improvement which can also benefit betwixt users, but I rather have the developer make that choice instead of possibly breaking default behaviour. Don't forget that betwixt is kind of a black box and any behaviour that can change the object-xml mapping by dropping in a new beanutils can an application. To get to your example : if all of a sudden a comma instead of a period will turn up in a value that can break the one who is expecting a period. In any case, this whole reasoning doesn't mean that much when betwixt is released after beanutils is :) Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BETWIXT-58) Empty string bug
[
https://issues.apache.org/jira/browse/BETWIXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin van den Bemt resolved BETWIXT-58.
Resolution: Fixed
Author: mvdb
Date: Sat Jun 30 02:26:22 2007
New Revision: 552123
URL: http://svn.apache.org/viewvc?view=revrev=552123
Log:
Fix BETWIXT-58. Thanx to Kevin Waugh for spotting this.
Modified:
jakarta/commons/proper/betwixt/trunk/src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
jakarta/commons/proper/betwixt/trunk/src/test/org/apache/commons/betwixt/strategy/TestObjectStringConverters.java
Empty string bug
Key: BETWIXT-58
URL: https://issues.apache.org/jira/browse/BETWIXT-58
Project: Commons Betwixt
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: N/A
Reporter: Kevin Waugh
Priority: Minor
Fix For: Nightly Builds
If you create a bean with a string property and set the string to be the
empty string then write the bean to xml using Betwixt upon reading the bean
the string property will be set to null.
The stringToObject method in ConvertUtilsObjectStringConverter does not obey
it's javadoc description. The following patch still violates the
description, but fixes the bug stated.
Index:
src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
===
---
src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
(revision 534335)
+++
src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
(working copy)
@@ -61,7 +61,7 @@
public Object stringToObject(String value, Class type, String flavour,
Context context) {
if (value == null || .equals(value))
{
-return null;
+return value;
}
return ConvertUtils.convert( value, type );
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-58) Empty string bug
[
https://issues.apache.org/jira/browse/BETWIXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509268
]
Martin van den Bemt commented on BETWIXT-58:
Oh forgot to add : since value can be null, I decided to just return instead
of value (since the javadoc says it will not return null)
Empty string bug
Key: BETWIXT-58
URL: https://issues.apache.org/jira/browse/BETWIXT-58
Project: Commons Betwixt
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: N/A
Reporter: Kevin Waugh
Priority: Minor
Fix For: Nightly Builds
If you create a bean with a string property and set the string to be the
empty string then write the bean to xml using Betwixt upon reading the bean
the string property will be set to null.
The stringToObject method in ConvertUtilsObjectStringConverter does not obey
it's javadoc description. The following patch still violates the
description, but fixes the bug stated.
Index:
src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
===
---
src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
(revision 534335)
+++
src/java/org/apache/commons/betwixt/strategy/ConvertUtilsObjectStringConverter.java
(working copy)
@@ -61,7 +61,7 @@
public Object stringToObject(String value, Class type, String flavour,
Context context) {
if (value == null || .equals(value))
{
-return null;
+return value;
}
return ConvertUtils.convert( value, type );
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (BETWIXT-23) [bewixt] null values shown as empty attributes
[ https://issues.apache.org/jira/browse/BETWIXT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin van den Bemt reopened BETWIXT-23: Reopening to resolve it again because jira things it is open. [bewixt] null values shown as empty attributes -- Key: BETWIXT-23 URL: https://issues.apache.org/jira/browse/BETWIXT-23 Project: Commons Betwixt Issue Type: Bug Affects Versions: Nightly Builds Environment: Operating System: Linux Platform: Other Reporter: _matthewHawthorne Priority: Critical When a bean's property value is null, and setAttributesForPrimitives is true, it is shown as an empty attribute. This behavior doesn't seem to be correct, since a value of null is being converted to an empty string. I've looked through the API and the code, and I can't seem to find where the problem is. I've posted this question to commons-user twice, but haven't received a response. Even if you can't provide a fix, could you point me in the right direction so I could perhaps patch it? Thanks for any help or information that you can provide. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BETWIXT-23) [bewixt] null values shown as empty attributes
[ https://issues.apache.org/jira/browse/BETWIXT-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin van den Bemt resolved BETWIXT-23. Resolution: Fixed Was already fixed.. Now JIra also gets that [bewixt] null values shown as empty attributes -- Key: BETWIXT-23 URL: https://issues.apache.org/jira/browse/BETWIXT-23 Project: Commons Betwixt Issue Type: Bug Affects Versions: Nightly Builds Environment: Operating System: Linux Platform: Other Reporter: _matthewHawthorne Priority: Critical When a bean's property value is null, and setAttributesForPrimitives is true, it is shown as an empty attribute. This behavior doesn't seem to be correct, since a value of null is being converted to an empty string. I've looked through the API and the code, and I can't seem to find where the problem is. I've posted this question to commons-user twice, but haven't received a response. Even if you can't provide a fix, could you point me in the right direction so I could perhaps patch it? Thanks for any help or information that you can provide. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (BETWIXT-2) Patch for mixed content
[ https://issues.apache.org/jira/browse/BETWIXT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin van den Bemt reopened BETWIXT-2: --- Jira thinks this is unresolved, even though it is fixed Patch for mixed content --- Key: BETWIXT-2 URL: https://issues.apache.org/jira/browse/BETWIXT-2 Project: Commons Betwixt Issue Type: Bug Affects Versions: 1.1 Final Environment: Operating System: All Platform: All Reporter: Aslak Hellesøy Attachments: patch.diff This patch makes it possible to read/write mixed content with Betwixt. It has been tested with beans that provide their own BeanInfo classes, and not with .betwixt files. Additional work is probably needed in order to make it work with .betwixt. Summary: -- XMLIntrospector -- In addition to adding elements and attributes, this now adds content too. XMLIntrospectorHelper.createDescriptor() now returns a Descriptor (and no longer a NodeDescriptor). -- AddDefaultsRule -- No functional changes, just changed call to XMLIntrospectorHelper.createDescriptor() -- XMLIntrospectorHelper -- When introspecting BeanInfo, this class is now looking for a magic text attribute on all the PropertyDescriptors. If one is found, we consider it to be PCDATA and treat it as mixed content. -- BeanRuleSet -- Added a body method so that xml-bean conversion is done properly -- TestXMLIntrospectorHelper -- Non functional change to make it compile. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (BETWIXT-2) Patch for mixed content
[ https://issues.apache.org/jira/browse/BETWIXT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin van den Bemt resolved BETWIXT-2. --- Resolution: Fixed Resolving again Patch for mixed content --- Key: BETWIXT-2 URL: https://issues.apache.org/jira/browse/BETWIXT-2 Project: Commons Betwixt Issue Type: Bug Affects Versions: 1.1 Final Environment: Operating System: All Platform: All Reporter: Aslak Hellesøy Attachments: patch.diff This patch makes it possible to read/write mixed content with Betwixt. It has been tested with beans that provide their own BeanInfo classes, and not with .betwixt files. Additional work is probably needed in order to make it work with .betwixt. Summary: -- XMLIntrospector -- In addition to adding elements and attributes, this now adds content too. XMLIntrospectorHelper.createDescriptor() now returns a Descriptor (and no longer a NodeDescriptor). -- AddDefaultsRule -- No functional changes, just changed call to XMLIntrospectorHelper.createDescriptor() -- XMLIntrospectorHelper -- When introspecting BeanInfo, this class is now looking for a magic text attribute on all the PropertyDescriptors. If one is found, we consider it to be PCDATA and treat it as mixed content. -- BeanRuleSet -- Added a body method so that xml-bean conversion is done properly -- TestXMLIntrospectorHelper -- Non functional change to make it compile. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BETWIXT-59) NullPointerException on getAttributeDescriptor
[ https://issues.apache.org/jira/browse/BETWIXT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509277 ] Martin van den Bemt commented on BETWIXT-59: Can you give us a testcase showing that behaviour.. That will make it quicker for us to fix this. NullPointerException on getAttributeDescriptor -- Key: BETWIXT-59 URL: https://issues.apache.org/jira/browse/BETWIXT-59 Project: Commons Betwixt Issue Type: Bug Environment: Betwixt 0.8, java 1.5.0_11, windows xp Reporter: Laurent J When writting custom suppression strategy first use of the following method yield NullPointerException : public AttributeDescriptor getAttributeDescriptor(final String name) My attributeList is not null and I want to retrieve an attribute but attributeDescriptors is null. Work around : call method hasAttributes before in order to fill attributeDescriptors Regards, kawas -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reorganising JIRA - Switching to new category
If no one objects I will create a new category in JIRA called commons and move all commons projects under that category.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reorganising JIRA - Switching to new category
See https://issues.apache.org/jira/secure/BrowseProject.jspa, Jakarta section. This contains all commons projects.. I already created the commons category and like to move the commons projects over there. If people adjusted their dashboard to eg just show the jakarta category they will miss some projects... Mvgr, Martin Dennis Lundberg wrote: Martin van den Bemt wrote: If no one objects I will create a new category in JIRA called commons and move all commons projects under that category.. A category is that what is found in the right hand drop-down under All Projects on the start page? It says Show All as the default. https://issues.apache.org/jira/secure/Dashboard.jspa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
This is not a Jakarta thing anymore :) Mvgr, Martin Dennis Lundberg wrote: The results are in: +1 Dennis Lundberg Torsten Curdt Niall Pemberton -0 Rahul Akolkar I will proceed with the release. Dennis Lundberg wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils][Betwixt] Backwards Compatibility of new Converter features
Hi Niall, I completely missed the mail, so sorry for responding so late and thanx for your extensive reply ! After some thought about this, I came to a couple of insights :) - You know the consequences of the change you made to beanutils a lot better than I do, so I leave that responsibility to you. Although I would like to see some form of documentation about this specific case (cannot imagine that betwixt is the only one that will run into this problem). The problem is that the testcode in betwixt looks buggy or at least weird to some extend, so maybe it's a hard case to explain. - The consequence I see now is that people if I adhere to the new way convert works, there will be problems with the currently released versions of beanutils, so : I decided to leave it to the user to use the improved beanutils functionality and solved the build problem by copying the beanutils 1.7 code over to betwixt (see http://svn.apache.org/viewvc?view=revrevision=552049). This gives me the certainty that people don't have any problems deserliazing their objects when beanutils trunk is on their classpath :) Don't know if your changes still serve a purpose, if not, you should be able to revert it without breanking betwixt. Mvgr, Martin Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Noticed the call of toString() on a String during the huntdown of what in beanutils broke the betwixt tests. (in the TestObjectStringConverters) The commit was a bit premature probably, although this is most (read most, so not all) of the time faster that calling toString() on a String. Will revert it (after some sleep) if that is what you are asking (code is more readable without the addition, agreed). Another questions (probably related to BEANUTILS-258) : The failing gump of betwixt is related to the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a default lookup is done for the type String.class and in the new code this is just the case when no converter can be found for the sourcetype, which makes the new beanutils code not a drop in replacement of the old one and not backward compatible. I will see if I can run the beanutils 1.7 testcases against trunk tomorrow (they should pass, or am I being simplistic here?) Was this breakage intended and what are your thoughts on how to handle this ? I only see 6 failures in 2 test cases (and looking at the gump output seems the same) and really its only 3 because one test case extends the other and its the same failures. TestObjectStringConverters (3 failures) - testConvertUtilsConverter - testDefaultOSConverter - testDefaultOSConverterDates Testi18nObjectStringConversion (3 failures) (same failures as above since it inherits from TestObjectStringConverters) The cause is the same in all cases - these tests are effectively testing that ConvertUtils is delegating to the Converter registered for the String.class. This is what I (intentionally) changed. http://issues.apache.org/jira/browse/BEANUTILS-258 The contract for BeanUtils's Converter includes the type you want to convert to. Unfortunately the Converter implementations mostly ignored this and for conversion to String ConvertUtils delegated to the registered String Converter. Makes more sense to me if the Converter registered for the Type handled conversion from the type to String. So for example - the date Converter implementations can now be configured with a pattern ( Locale) and use that pattern to convert from String to Date and from Date to String. The same is true for the improved number converters (which can now also be configured with patterns and a Locale). In light of the betwixt issue I have made one change to the ConvertUtilsBean's new convert() method - if the registered Converter doesn't convert the value to a String it tries the registered String Conveter first - before then defaulting to the object's toString() method. This only partially resolves the compatability issue though and doesn't stop Betwixt tests failing. http://svn.apache.org/viewvc?view=revrevision=551047 On the compatibility issue - I believe the Converter implementations provided by BeanUtils are backwards compatible and its only where people have registered their own implementations that there may be issues. With my change today - if their Converter implementations don't handle conversion to String then it will continue to delegate to the registered String Converter - if their Converter doesn't cope well with that then they have an issue. The solution is fairly straight forward though since I have added a new AbstractConverter implementation that provides a structure to easily add String conversion capability. The question is though whether this is all enough (IMO yes). If not then the one option would for the existing ConvertUtilsBean's convert() methods to revert to their previour behaviour
Re: [BeanUtils][Betwixt] Backwards Compatibility of new Converter features
Niall Pemberton wrote: On 6/29/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi Niall, Betwixt test cases are bizarre - but they do highlight a potential issue. Unfortunately BeanUtils development is slow and I'd rather ponder this some more than take a definite position at this point - a compatbility option in BeanUtils would be good, but I have to find the cycles and motivation to do it :( The testcase gives me a headache indeed :) It seriously looks buggy :) I decided to leave it to the user to use the improved beanutils functionality and solved the build problem by copying the beanutils 1.7 code over to betwixt (see http://svn.apache.org/viewvc?view=revrevision=552049). This gives me the certainty that people don't have any problems deserliazing their objects when beanutils trunk is on their classpath :) The problem/issue with this approach is that you prevent Betwixt users taking advantage of the improved conversion facilities that will be offered by BeanUtils in the next release. Betwixt build issues can be fixed (i have a tested patch) to work for both the new and the old - leaving the compatibility issue open for now (but to be resolved before a BeanUtils release). Nah users can simply override the default by eg calling BeanReader.setBindingConfiguration(their own BindingConfiguration).. If they don't do anything they will get the default with the stable behavior. So people already doing advanced betwixt stuff, probably already don't use the DefaultStringConverter anymore. So no problem from the betwixt side. (although I am interested in your patch) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements
[ https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509223 ] Martin van den Bemt commented on BEANUTILS-285: --- This is what I did at first, but the problem with that approach is that I am fixing the testcase, which in turn doesn't really fix the problem. If conversion changes when using a new beanutils version, people are not able to deserialize their xml anymore (or with weird results), which is the reason of the copypaste of the beanutils 1.7 method. Don't forget that the test is for internal betwixt use. Even if people use beanutils directly the betwixt behaviour will not change if they going to use the new version. If they chose to depend on the new behaviour in beanutils they will hit problems when developing instead of getting into trouble at runtime when someone decides to use the latest and greatest dependencies.. So in short : I prefer a developer to get into trouble when he chooses to (= working on code that depends on betwixt) and not when someone else chooses to (the person that needs this version of beanutils to do something else) Consider options for BeanUtils compatibility in light of Conversion improvements Key: BEANUTILS-285 URL: https://issues.apache.org/jira/browse/BEANUTILS-285 Project: Commons BeanUtils Issue Type: New Feature Components: ConvertUtils Converters Affects Versions: 1.8.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Attachments: betwixt-beanutils-gump-fix.patch The Conversion improvements associated with BEANUTILS-258 potentially create compatibility issues - this was highlighted by Betwixt's tests failing recently in the gump run - see http://tinyurl.com/2mxbv8 for more details. Quite a bit of effort has been put into making the new conversion facilities as painless as possible for existing users. However it is not fully backwards compatible in terms of behaviour (stiil binary compatible). Need to give this some consideration before a BeanUtils release - at the moment there are two options on the table (more welcome!): 1) The compatibility as it stands is good enough (covers most cases) - so do nothing 2) Provide a compatibility option - so that users can choose either the new behaviour or behaviour compatible with BeanUtils 1.7.0. This probably involves quite a bit of work - adding back the old behaviour alongside the new -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils][Betwixt] Backwards Compatibility of new Converter features
Niall Pemberton wrote: On 6/30/07, Martin van den Bemt [EMAIL PROTECTED] wrote: already don't use the DefaultStringConverter anymore. So no problem from the betwixt side. (although I am interested in your patch) I've created a compatibility Jira issue for BeanUtils - and I stuck the betwixt patch there so you could see it: https://issues.apache.org/jira/browse/BEANUTILS-285 Responded to this mail and to the reply to my commit in the issue. Hope you get what I am trying to say.. It's a pain when an application breaks if eg websphere version 10 or something uses beanutils 1.8. Wasted too many hours on these kind of things ;) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
Agree with Niall.. Archives are pretty much unusable with commits messages and jira issues.. Mvgr, Martin Niall Pemberton wrote: On 6/27/07, Torsten Curdt [EMAIL PROTECTED] wrote: snip #=== [1] Mailing List (i) addresses I. [EMAIL PROTECTED] * Henri Yandell[EMAIL PROTECTED] * Jochen Wiedmann [EMAIL PROTECTED] * Mario Ivankovits [EMAIL PROTECTED] * Stephen Colebourne [EMAIL PROTECTED] * Dennis Lundberg [EMAIL PROTECTED] * Niall Pemberton [EMAIL PROTECTED] * Martin van den Bemt [EMAIL PROTECTED] * Oliver Zeigermann[EMAIL PROTECTED] * Jörg Schaible[EMAIL PROTECTED] * Oliver Heger [EMAIL PROTECTED] * Matt Benson [EMAIL PROTECTED] * Martin Cooper[EMAIL PROTECTED] * Phil Steitz [EMAIL PROTECTED] * Torsten Curdt[EMAIL PROTECTED] * Daniel Savarese [EMAIL PROTECTED] * Rory Winston [EMAIL PROTECTED] * Luc Maisonobe[EMAIL PROTECTED] * Joerg Pietschmann[EMAIL PROTECTED] * Dion Gillard [EMAIL PROTECTED] * Brent Worden [EMAIL PROTECTED] * Simon Kitching [EMAIL PROTECTED] * Rahul Akolkar[EMAIL PROTECTED] II. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] NOTE: if possible forward [EMAIL PROTECTED] to [EMAIL PROTECTED] My preference is commits@ is not forwarded to dev - makes searching mail archives easier - also in discussion on splitting the lists in the past we've talked about having an issues@ list as well. Not sure what the consensus was, but thats my preference. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
I don't see a problem in doing the last 2 years, which kind of gives us a nice clean committer base and if we miss people, they simply need to ask for it. Another options is just copy pasting the jakarta committers block from asf-authorization, that way you know everyone who has access, still has access.. Mvgr, Martin Henri Yandell wrote: On 6/27/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/28/07, Henri Yandell [EMAIL PROTECTED] wrote: On 6/27/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/27/07, Henri Yandell [EMAIL PROTECTED] wrote: Personally, my vote would be to say: commons=committers You mean all apache committers? I agree that we should continue the tradition of granting commons karma to any committer who asks for it. I don't know much about how this works in svn or what the risk / downside of auto-granting commons karma to new committers would be, but I agree with the principle that any ASF committer should be welcome here. There are also a lot of current commons committers missing from the list above. My preference would be to have them remain commons committers if that is not too hard to do. In any case, any current commons committer who wants karma should get it. I agree - please lets not remove commit privledge from anyone who currently has it in Commons. Presuming no one recognizes the social genius of my first proposal, then I recommend that we make the list of committers be anyone who has committed in the last 2 years. Why have you gone from proposing to add any remaining ASF Commiters that don't currently have access to now removing access from anyone who hasn't committed in the last two years? This seems a bit random in principle to me to take one position to open things up one minute and then another to make it more restrictive the next. Just looking for something simple. I also dislike arbitrary limits - you choose 2 years - maybe someone else will prefer 1 year and so on. I still think anyone that currently has access should keep it and not loose their commit access to Commons. Pondered that one. We could keep the commons commit list as the jakarta group. Seemed a bit odd though. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549986 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Thanx.. Mvgr, Martin Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Noticed the call of toString() on a String during the huntdown of what in beanutils broke the betwixt tests. (in the TestObjectStringConverters) The commit was a bit premature probably, although this is most (read most, so not all) of the time faster that calling toString() on a String. Will revert it (after some sleep) if that is what you are asking (code is more readable without the addition, agreed). Sorry was grmupy earlier - I leave it up to you. No problem, I kind of deserved that response with that commit :) If I am absolutely certain about a possible performance gain, I'll leave it in else I will revert it. Another questions (probably related to BEANUTILS-258) : The failing gump of betwixt is related to the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a default lookup is done for the type String.class and in the new code this is just the case when no converter can be found for the sourcetype, which makes the new beanutils code not a drop in replacement of the old one and not backward compatible. I will see if I can run the beanutils 1.7 testcases against trunk tomorrow (they should pass, or am I being simplistic here?) Was this breakage intended and what are your thoughts on how to handle this ? I'm not familiar with betwixt - but I will look at this - hopefully sometme this weekend. I'll see if I can make a simple testcase which shows the problem (so you don't have to dig into betwixt itself). We currently have 24 tests failing with beanutils trunk.. I had a quick look at one of the failing tests and understand the issue with that one - I'll look at the rest and write something up later. Niall Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549986 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Niall Pemberton wrote: On 6/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Noticed the call of toString() on a String during the huntdown of what in beanutils broke the betwixt tests. (in the TestObjectStringConverters) The commit was a bit premature probably, although this is most (read most, so not all) of the time faster that calling toString() on a String. Will revert it (after some sleep) if that is what you are asking (code is more readable without the addition, agreed). Sorry was grmupy earlier - I leave it up to you. No problem, I kind of deserved that response with that commit :) If I am absolutely certain about a possible performance gain, I'll leave it in else I will revert it. Another questions (probably related to BEANUTILS-258) : The failing gump of betwixt is related to the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a default lookup is done for the type String.class and in the new code this is just the case when no converter can be found for the sourcetype, which makes the new beanutils code not a drop in replacement of the old one and not backward compatible. I will see if I can run the beanutils 1.7 testcases against trunk tomorrow (they should pass, or am I being simplistic here?) Was this breakage intended and what are your thoughts on how to handle this ? I'm not familiar with betwixt - but I will look at this - hopefully sometme this weekend. I'll see if I can make a simple testcase which shows the problem (so you don't have to dig into betwixt itself). We currently have 24 tests failing with beanutils trunk.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons is TLP
The commons one is probably less straight forward, although could be a lot easier. Since there was a commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc already there), besides setting up the karma for the people, moving over the website, etc,etc.. So probably best to figure out on infrastructure how to approach this specific situation. Mvgr, Martin Torsten Curdt wrote: On 21.06.2007, at 00:57, Martin van den Bemt wrote: Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. ...so where do we start with the TLP move is the question :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons is TLP
Forgot to check this list, feedback enough so it seems :) Mvgr, Martin Martin van den Bemt wrote: The commons one is probably less straight forward, although could be a lot easier. Since there was a commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc already there), besides setting up the karma for the people, moving over the website, etc,etc.. So probably best to figure out on infrastructure how to approach this specific situation. Mvgr, Martin Torsten Curdt wrote: On 21.06.2007, at 00:57, Martin van den Bemt wrote: Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. ...so where do we start with the TLP move is the question :) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r549986 - /jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Noticed the call of toString() on a String during the huntdown of what in
beanutils broke the
betwixt tests. (in the TestObjectStringConverters)
The commit was a bit premature probably, although this is most (read most, so
not all) of the time
faster that calling toString() on a String. Will revert it (after some sleep)
if that is what you
are asking (code is more readable without the addition, agreed).
Another questions (probably related to BEANUTILS-258) : The failing gump of
betwixt is related to
the changes you made to ConvertUtilsBean.convert(Object). In beanutils 1.7 a
default lookup is done
for the type String.class and in the new code this is just the case when no
converter can be found
for the sourcetype, which makes the new beanutils code not a drop in
replacement of the old one and
not backward compatible. I will see if I can run the beanutils 1.7 testcases
against trunk tomorrow
(they should pass, or am I being simplistic here?)
Was this breakage intended and what are your thoughts on how to handle this ?
Mvgr,
Martin
Niall Pemberton wrote:
Is there a reason for this change? AFAIK calling toString() on a
String object just returns a reference to itself - so this just seems
to add clutter in my mind. Also there was discussion on this (i.e.
calling toString() on a String) for this very bit of code in the
following issue ticket - would have been nice to comment before
arbitarily making the change
http://issues.apache.org/jira/browse/BEANUTILS-283
Niall
On 6/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: mvdb
Date: Fri Jun 22 17:58:02 2007
New Revision: 549986
URL: http://svn.apache.org/viewvc?view=revrev=549986
Log:
Prevent calling toString on a String.
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Modified:
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java?view=diffrev=549986r1=549985r2=549986
==
---
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
(original)
+++
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/ConvertUtilsBean.java
Fri Jun 22 17:58:02 2007
@@ -542,7 +542,8 @@
}
converted = converter.convert(targetType, value);
}
-if (targetType == String.class converted != null) {
+if (targetType == String.class converted != null
+!(converted instanceof String)) {
converted = converted.toString();
}
return converted;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
+1 Mvgr, Martin Niall Pemberton wrote: Rahul Akolkar is an existing Jakarta PMC member and Commons Committer. He was against the proposal for Commons to become a TLP. Since that vote passed and the Apache Board has now passed the resolution for Commons to become a TLP I would like to invite Rahul to join the new Apache Commons PMC. It would be a tragedy IMO if we lose valuable members of the Commons Community just because they were originally against the TLP proposal. [ ] +1, don't let Rahul get away - lets try to get him to join the new PMC [ ] -1, no leave him out Niall P.S. Anyone else in the same situation, then I suggest we do the same - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Simon Kitching to join the Apache Commons PMC
+1 Mvgr, Martin Niall Pemberton wrote: Simon Kitching is an existing Jakarta PMC member and Commons Committer. He was against the proposal for Commons to become a TLP. Since that vote passed and the Apache Board has now passed the resolution for Commons to become a TLP I would like to invite Simon to join the new Apache Commons PMC. It would be a tragedy IMO if we lose valuable members of the Commons Community just because they were originally against the TLP proposal. [ ] +1, don't let Simon get away - lets try to get him to join the new PMC [ ] -1, no leave him out Niall P.S. Anyone else in the same situation, then I suggest we do the same - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons is TLP
Hi everyone, The new Commons TLP was established today, with Torsten Curdt as Vice President. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons TLP Resolution
Please see http://mail-archives.apache.org/mod_mbox/jakarta-general/200705.mbox/[EMAIL PROTECTED] for the vote. Mvgr, Martin Establish the Apache Commons project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of Java focused reusable libraries and components. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Commons Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Commons Project be and hereby is responsible for the creation and maintenance of Java focused reusable libraries and components; and be it further RESOLVED, that the office of Vice President, Commons be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Commons Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Commons Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Commons Project: * Henri Yandell[EMAIL PROTECTED] * Jochen Wiedmann [EMAIL PROTECTED] * Mario Ivankovits [EMAIL PROTECTED] * Stephen Colebourne [EMAIL PROTECTED] * Dennis Lundberg [EMAIL PROTECTED] * Niall Pemberton [EMAIL PROTECTED] * Martin van den Bemt [EMAIL PROTECTED] * Oliver Zeigermann[EMAIL PROTECTED] * Jörg Schaible[EMAIL PROTECTED] * Oliver Heger [EMAIL PROTECTED] * Matt Benson [EMAIL PROTECTED] * Martin Cooper[EMAIL PROTECTED] * Phil Steitz [EMAIL PROTECTED] * Torsten Curdt[EMAIL PROTECTED] * Daniel Savarese dfs at apache.org * Rory Winston rwinston at apache.org * Luc Maisonobe[EMAIL PROTECTED] * Joerg Pietschmann[EMAIL PROTECTED] * Dion Gillard [EMAIL PROTECTED] * Brent Worden [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Torsten Curdt be appointed to the office of Vice President, Commons, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Commons Project be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Commons Project; and be it further RESOLVED, that the initial Apache Commons Project be and hereby is tasked with the migration and rationalization of the Apache Jakarta Project's Commons; and be it further RESOLVED, that all responsibility pertaining to the Commons sub-project encumbered upon the Apache Jakarta Project are hereafter discharged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r545184 - /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/distribution/PoissonDistributionImpl.java
If the intention is to have a NullPointerException when null is passed, declare
it and throw it
specifically (that way you are in control of the exception). I think every
undocumented nullpointer
exception is a bug.
Mvgr,
Martin
Luc Maisonobe wrote:
[EMAIL PROTECTED] wrote:
+/**
+ * Modify the normal distribution used to compute normal approximations.
+ * The caller is responsible for insuring the normal distribution has
the
+ * proper parameter settings.
+ * @param value the new distribution
+ * @since 1.2
+ */
+public void setNormal(NormalDistribution value) {
+normal = value;
}
Should we check for null parameters here and throw a NPE ourselves or
simply allow null parameters and let the JVM throw the NPE when the
distribution is used ?
I am fine with the current choice of letting the JVM handle this by
itself, I only wondered what others think about this.
Luc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MATH] Initial ideas for adding naive prime algorithms
I'll help out with that if the time comes, he is a co-worker of mine.. Mvgr, Martin Bill Barker wrote: Roy van Rijn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While browsing through the Commons Math API today I noticed there aren't any prime algorithms in it. Then I noticed the request for these algorithms on the wiki WishList. Is anybody working on this yet? If not, could this be a good start? http://www.redcode.nl/tmp/PrimeUtils.rar I'm somewhat interested, but for those of us that don't use a mac, could you publish in more universal format (e.g. .tar.gz/.zip)? Of course, this will need all of the legal IP clearance if it gets accepted, so in the meantime, you should probably look at http://www.apache.org/licenses/#grants. Roy (new to ASF) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] io failed.
You suck at betting :) Mvgr, Martin Henri Yandell wrote: Bet this doesn't happen again tonight. On 5/11/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070511/io.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] io failed.
I suck at saying you suck at betting.. Should have checked the dates :) Mvgr, Martin Martin van den Bemt wrote: You suck at betting :) Mvgr, Martin Henri Yandell wrote: Bet this doesn't happen again tonight. On 5/11/07, Phil Steitz [EMAIL PROTECTED] wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070511/io.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
+1 to you :) Mvgr, Martin Torsten Curdt wrote: On 06.05.2007, at 19:51, Henri Yandell wrote: On 5/1/07, Henri Yandell [EMAIL PROTECTED] wrote: On 5/1/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 5/2/07, Henri Yandell [EMAIL PROTECTED] wrote: (http://wiki.apache.org/jakarta-commons/TLPResolution) and secondly, anyone want to volunteer to chair things? As you are one of the most active persons here and also the one who is pushing this forward: How about yourself? :-) A bunch of projects do a one year term, which I think is probably a very healthy thing. I'm happy to do the chair bit if no one else wants to, but I'll happily support anyone if they're interested. No one interested in volunteering as Commons chair? I would also do it (How come I am not in the list? Did I miss the call?) cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CSV] A few questions and comments
Hi Stuart, Just a clarification upfront : Currently csv has 2 codebases : the on in the writer package is what I have written (don't remember if someone else has worked on that though) and the main o.a.c.csv package is what the codebase started with. Because of like of time and the fact that people seemed to be more interested in what was at the main package, I just continued doing the writer package for private use. My focus is configurability and simple patterns to be able to easily integrate csv in web applications and front end applications. Afaik there is no interaction between the 2 packages :) Stuart Robertson wrote: I just looked over the codebase and have a few questions. First, I'm wondering if some simple invalid format detection might be added as a configuration option. Something to detect whether a given input might even be theoretically parseable. I'd like to be able to detect, for instance, that this is a binary file, or maybe if it doesn't seem to contain a consistent separator pattern (line 1 has 10 columns, line 2 only 6). Basically anything to detect upfront an invalid file condition rather than have garbage be passed into the file using CSVParser. The ConfigGuesser could be reused to achieve this. The main goal for ConfigGuesser is to limit user configuration. Second, any thoughts on how guessFieldSparator can infer if it's TDF or CSV? Or maybe what flavor of CSV format the file might be using (Excel or otherwise). I see the CSVConfigGuesser attempts to determine whether the file is fixed width. And the method guessFieldSeperator() seems to have a placeholder for guessing the file separator, but currently that portion is an empty for loop. It's far from finished and very buggy :) It's the concept I wanted to draw attention too. Thinking about how that might be implemented, what if a regex counted the occurrances of common separators in each of the guess input lines. A reasonable hueristic might be that the separator guess is that separator that has a common occurrance count in each line, and we could go with that. Does this sound reasonable? Or maybe there's a better way to do it? There are a lot of problems with guessing the format :) In general, I think it'd be a valuable feature for the guesser to be as robust as possible for a range of input types. Even if it weren't possible to make it perfect, for uses where the application can't completely control the format comming in, being fairly robust in the face of a variety of types would be outstanding. Robust would be nice, but pretty hard to achieve. Maybe some way of setting the configguesser strategy can make the thing more robust for the scenario you are using it for. My usage scenario is that I don't have a clue what people want to use as their text format (and I don't care). So guessing should be most flexible. By usage a of eg a wizard, people are able to change the behavior of the configgueser like stating that this csv file has 10 fields, you can make your system more robust. So eg 1010101 probably means that the separator will be 0 (1 is the start and the end, so is most likely a value). If the user specifies that the csv file only has one field, we know 0 is not the separator. So I prefer no to limit the options out of the box, but have some kind of strategy to be able to limit the options (in my case that is users who specify that the csv has 10 fields), but we could make standard strategies, like the default excel export format. One last observation. CSVConfigGuesser looks intended to uses the first 10 lines of input if available for inferring the right config. But looking at the code, it looks to me like it will actually read in the entire file. Here's the code (from SVN) I'm writing about: Yeah the code is bad, very bad :) I just committed the guesser as a concept. Almost every line is bad to be honest :). Fixed the while loop in subversion.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
A group of people that care about the same things under one umbrella, with it's own power of making decisions. Jakarta isn't that, c.a.o will for commons. Mvgr, Martin Jochen Wiedmann wrote: I've got a question: If we have commons.apache.org, what will be the difference to jakarta.apache.org, apart from the missing projects? Why do we expect that c.a.p will work, although we assume that j.a.p didn't? Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Going TLP?
+1 for c.a.o, since I think it is right thing for commons. Jakarta PMC Chair hat on I really regret this step is necessary and is the beginning of the end of Jakarta. Even though this process started earlier than this proposal, this process will make the end of Jakarta unavoidable. I always hoped flattening commons would be the new Jakarta, but the thought crossed my mind I could well be the last Jakarta PMC Chair. Please understand that this proposal is *not* about Jakarta, but about commons, so instead of voting -1 on this proposal to prevent Jakarta to end, I prefer that everyone will continue to keep involved at Jakarta to move Jakarta to it's new role, whatever that may be. There are still a lot of projects that here that need your expertise, experience and spirit. /Jakarta PMC Chair hat on Mvgr, Martin Henri Yandell wrote: I think the end should be nigh for Jakarta (those on private@ will have seen a thread in which I side-topic'd with the feeling that the end should be nigh for Jakarta). Previously I've suggested that Commons should flatten into Jakarta and that Jakarta should become a general 'Java components' project; however there are some negatives to that that I think are critical. Firstly, it leaves the future Jakarta with a lot of dead projects that are going nowhere. That's not going to change in the short to medium term, so it just becomes a millstone for the project's neck. Secondly, the Jakarta PMC will always remain a big group of people who care about the brand name and the various legacies, rather than a small focused PMC. I think this isn't desirable for any active community that are a part of Jakarta currently - trying to have a PMC that are acting as one community when not being one community doesn't work. Thirdly, I think by being here we are helping to delay the inevitable and keeping the old, broken umbrella going. Moving to TLP will help things move along, and will provide a place for things to move to. So with that said - I'd like to propose that we move to commons.apache.org. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] jci out of sandbox
+1.. Mvgr, Martin Torsten Curdt wrote: As already announced I would like to move http://jakarta.apache.org/commons/sandbox/jci/ out of the sandbox so I can then prepare a first RC. Please cast your votes for the graduation! cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
+1.. Mvgr, Martin Stephen Colebourne wrote: Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [ ] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Seeking opinion RE IP issues
IANAL, so not going to give you advise on this scenario :) I tend to prevent this scenario, by starting an open source for such things. Most employers will say yes to this, especially if you invest a lot of your own time in creating this :) I started doing it like this, since at a certain point in time, I was promised I could use that code base in any way I wanted and couldn't get permission when leaving that company. (my project xulux is an example of this, although sadly enough I lack the time to work on it) Just some thoughts ;) Mvgr, Martin Matt Benson wrote: First, my apologies for the cryptic subject line. I am woefully ignorant of the relevant legal jargon. Next, note that this email is NOT related to my various twitchings regarding bringing the Morph project to Apache. Moving on... I should qualify that I am a US citizen, so the relevant IP laws would apply AFAIK. Now let's say I write a Java library at work, but it's something that is (a) useful and (b) fairly unique, and I think it would make a nice commons component. Time passes, I change jobs, and based--no bullshit--entirely on my recollection of the functionality I had implemented before, I re-implement something extremely similar in the commons sandbox for eventual consideration for the commons proper. I've heard various things to the effect that you can't be held responsible for what you remember (unless you're Ben Affleck in Paycheck); can anyone comment on experience with this type of question wrt the ASF? What does it take to prove that I in no way referred to the original code beyond what remained in my head? The resulting code would probably be similar though not identical to the original, but the functionality would be nearly identical unless I totally freaked out in some way. fwiw, I've subscribed to [EMAIL PROTECTED] in case having done so in the past would have made me a better-informed citizen to begin with. :| -Matt Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announce: Commons Fileupload 1.2
Jochen, Please update the http://wiki.apache.org/jakarta/JakartaBoardReport-current (section releases and the section of the fileupload component, with some more details about the release) Mvgr, Martin Jochen Wiedmann wrote: Hi, the Jakarta Commons team is glad to announce the availability of commons-fileupload 1.2. Commons Fileupload is a framework for handling HTTP file upload requests in servlets, portlets, and similar server side Java applications. Compared to the previous version 1.1.1, the following notable changes have been made: - A streaming API has been added. The streaming API allows to handle arbitrarily large files without intermediary files while still keeping an extremely low memory profile. - The presence of a content-length header is no longer required. - Added support for progress listeners. - Added support for header continuation lines. - Added support for limiting the actual file size, as opposed to the request size. Commons Fileupload 1.2 is available from http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi Jochen Wiedmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Status of components
If you could add that to the board report, me will be very happy ;) Mvgr, Martin Matt Benson wrote: --- Henri Yandell [EMAIL PROTECTED] wrote: I made a stab of defining the current status for Commons for the Jakarta board report: http://wiki.apache.org/jakarta/JakartaBoardReport-current [SNIP] JXPath seems to have been effectively abandoned, but is overall quite stable. It is, IMHO, very close to being ready for a 1.3 release (a couple of JIRA issues still need attention). After 1.3 is released it can likely languish in the maintenance mode that IIRC was proposed by Niall on this thread. My intent is to act as curator for this project. However all that condenses into a summary status. ;) -Matt Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Adding the dbutils-1.1 source to the repository
I think the source jars are very useful and since everything looks ok, go ahead.. Mvgr, Martin Henri Yandell wrote: I've put together a -source.jar for dbutils 1.1 by hand. Any complaints if I add that to the Maven repository? It's attached to the issue it was requested in: http://issues.apache.org/jira/browse/DBUTILS-35 I imagine the next DbUtils release will use Maven2, so I'm not bothering to work on the maven.xml or build.xml to make this happen in Maven1 and Ant. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LICENSE and NOTICE in javadoc jar (Was: [VOTE] IO 1.3 (RC3))
-1 to dropping that, since a javadoc jar is a release too, which needs a license and notice. If we haven't done that in the past, doesn't mean we have to continue not to do that. Mvgr, Martin Jochen Wiedmann wrote: On 1/26/07, Henri Yandell [EMAIL PROTECTED] wrote: 2) Javadoc jar for Maven includes LICENSE and NOTICE. It is news to me, that that's a requirement. I am unaware of any build script that ensures it. Please note, we are talking about the javadocs jar file. not the actual meat (source and binaries). Couldn't we drop that for the future, please? Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LICENSE and NOTICE in javadoc jar (Was: [VOTE] IO 1.3 (RC3))
Agreed.. Mvgr, Martin Jörg Schaible wrote: Then you need'em also in the artifactId-version-sources.jar ... Martin van den Bemt wrote on Friday, January 26, 2007 9:38 AM: -1 to dropping that, since a javadoc jar is a release too, which needs a license and notice. If we haven't done that in the past, doesn't mean we have to continue not to do that. Mvgr, Martin Jochen Wiedmann wrote: On 1/26/07, Henri Yandell [EMAIL PROTECTED] wrote: 2) Javadoc jar for Maven includes LICENSE and NOTICE. It is news to me, that that's a requirement. I am unaware of any build script that ensures it. Please note, we are talking about the javadocs jar file. not the actual meat (source and binaries). Couldn't we drop that for the future, please? Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira reporting
That sounds nice, but than the vote needs to be on general :) I would be an favor of that.. Mvgr, Martin Dennis Lundberg wrote: Why not move all JIRA notifications to [EMAIL PROTECTED] ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] when are svn commit mails generated ?
I am doing user, general, private, cvs, etc (and need to find the gaps that are currently at Jakarta). Also a couple of non jakarta lists though.. 98% is spam and nicely marked as such :) So if someone else can also step up that would be great (I don't mind another list though) Mvgr, Martin Henri Yandell wrote: I want to quit the moderating scene tbh. It's a pretty easy thing to do, so I'm hoping I can hand them off to others. I think I'm doing: commons-dev@ commons-user@ general@ Would be nice to get off those. Hen On 1/16/07, Martin van den Bemt [EMAIL PROTECTED] wrote: You can add me, although I am not as quick as you are :) Mvgr, Martin Henri Yandell wrote: On 1/16/07, Martin Cooper [EMAIL PROTECTED] wrote: On 1/16/07, Luc Maisonobe [EMAIL PROTECTED] wrote: Hello, I just realized recently that not all commits to the subversion base generated mails to the dev list. Not true. Since the repository is also shared by other Apache projects outside of commons, I thought there was some filter for commons, based for example on directories tree structure. However, I performed a small commit for three files in [math] yesterday which bumped version to r496489 and no mail was generated. Since it was my very first commit, I am a little affraid I can have done something wrong. Most likely, since it was your first commit, the commit message is sitting in the moderation queue, waiting for a moderator to approve it (and add your address to the allowed posters). It was in the queue and I've been on the end of a bad connection for a few days. If anyone feels like becoming a mailing list moderator :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] when are svn commit mails generated ?
You can add me, although I am not as quick as you are :) Mvgr, Martin Henri Yandell wrote: On 1/16/07, Martin Cooper [EMAIL PROTECTED] wrote: On 1/16/07, Luc Maisonobe [EMAIL PROTECTED] wrote: Hello, I just realized recently that not all commits to the subversion base generated mails to the dev list. Not true. Since the repository is also shared by other Apache projects outside of commons, I thought there was some filter for commons, based for example on directories tree structure. However, I performed a small commit for three files in [math] yesterday which bumped version to r496489 and no mail was generated. Since it was my very first commit, I am a little affraid I can have done something wrong. Most likely, since it was your first commit, the commit message is sitting in the moderation queue, waiting for a moderator to approve it (and add your address to the allowed posters). It was in the queue and I've been on the end of a bad connection for a few days. If anyone feels like becoming a mailing list moderator :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
+1 to both, assuming the project documentation on the main site has nothing to do with the skin, since I think we don't want that menu on the main site. Mvgr, Martin Dennis Lundberg wrote: I have laid the finishing touches to commons-skin and feel that it is ready for prime time. Therefor I would like to propose two votes: 1. Promote commons-skin from commons sandbox to commons proper. [ ] +1 Do it [ ] -1 No not yet, because... 2. Release commons-skin 1.0 based on revision 495809. I have not created an RC for it, since it is in the sandbox. If that is needed, I'll do it once the move to commons proper has been completed. Examples of how it looks can be found at the address below, where the entire sandbox has been staged. Note that the staged sites have been built with Maven components that were built from SVN and have not yet been released. http://people.apache.org/~dennisl/commons-sandbox/ [ ] +1 Do it [ ] -1 No not yet, because... The votes will be open for at least 72 hours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Matt Benson as a Jakarta committer
+1.. Mvgr, Martin Henri Yandell wrote: As you can see on the list, Matt would like to help out with JXPath. Matt's been an Ant committer since Feb 2004. He's been active on the dev/user lists over the last couple of years, so not a new face here either. [ ] +1 [ ] -1 Will end the vote on Tuesday morning. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC10
Even though I like to see the record breaking effort of RC, while we are at it, really at an unbreakable level like 50 ;) However, there doesn't seem to be a reason to get you started on the 11th one, so +1 :) Mvgr, Martin Mario Ivankovits wrote: Hi! Please don't laugh ... I don't know if there ever was a to be released Jakarta project with so many RCs. Be patient with me, I hope in the future we can go more straight forward. Changed: * The ant build succeeded, but in the resulting jar the LICENSE.txt was missing (only NOTICE.txt is copied to META-INF). Please find the RC at http://people.apache.org/~imario/vfs The site can be reviewed at http://people.apache.org/~imario/vfs-1.0/site [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Thanks for your time! --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Luc Maisonobe as Jakarta Commons committer
+1 Mvgr, Martin Phil Steitz wrote: I would like to nominate Luc Maisonobe as a Jakarta Commons committer. Luc has made a major contribution to commons-math in the Mantissa library and has also contributed to discussion and Jira tickets related to other parts of [math]. His openness to feedback and diligence in resolving IP-related issues as we went through the incubator IP clearance process demonstrated his commitment to open development @apache. I think Luc will make a great addition to the apache committer community. Here is my +1. Votes, please. This vote will close end of (GMT) day, 23-Dec-06. Thanks! Phil 8--- [ ] +1 Let him commit! [ ] +0 [ ] -0 [ ] -1 No, because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-ssl-0.3.4 alpha released
I asked to start a proposal on [EMAIL PROTECTED] about this, that way we can
have a discussion on
where it should end up.. I'll await that proposal and to decrease confusion I
like to ask Julius to
withhold announcements for the time being.
Mvgr,
Martin
Henri Yandell wrote:
Hi Julius,
What's the status with regards to this bit on the website:
Commons-SSL was originally developed by Credit Union Central of
British Columbia. It was donated to the Apache Software Foundation in
August 2006 and is now slowly starting the Apache
Incubation Policy.
In terms of the CLA - it doesn't look like you're an Apache committer
yet. Was there a particular project you were joining when you sent the
CLA?
In terms of the CCLA - have you requested a signed copy? I don't think
they're sent by default. However I don't see a CCLA on record for
CUBC.
I've no problem with this ending up in Commons someday - but so far
this seems like something for which the subject should be more about
Jakarta sponsoring in the Incubator, than starting in Commons-Sandbox.
[I did the latter for CSV, and I think with hindsight it would have
been better to go through the Incubator].
Hen
On 11/29/06, Julius Davies [EMAIL PROTECTED] wrote:
Hi,
I'm writing to announce the alpha release of commons-ssl-0.3.4. I'm
writing to commons-dev@jakarta.apache.org because I think
commons-sandbox would be a great home for this library. The library
itself is derived from some HttpClient code originally written by Oleg
Kalnichevski.
http://juliusdavies.ca/commons-ssl/
Here are a few features of note:
1. This library gives you the ability to read OpenSSL style private
keys using only pure Java. It even works with Java 1.3. I tried to
encrypt the same RSA private keys in as many ways as possible (106 so
far!) with OpenSSL to test this:
http://juliusdavies.ca/commons-ssl/samples/rsa_result.html
2. The library automatically does CRL checking. (We hope to add
support for OCSP soon!).
3. All options can be toggled on a per-socket-factory basis. So for
one SSLSocketFactory you might have setCheckHostname( false ), and on
another you might have setCheckExpiry( false ) if you like.
4. Can be dropped into any project easily because we extend
SSLSocketFactory and SSLServerSocketFactory. For example, to use as
an ldaps:// client you just define your own extremely basic
sub-class:
=
package my.special.package;
public class LDAPSocketFactory extends SSLClient {
public static SocketFactory getDefault() { return instance; }
private final static LDAPSocket instance;
static {
try { instance = new LDAPSocket(); }
catch ( Exception e ) { throw new RuntimeException( e ); }
}
private LDAPSocket() throws GeneralSecurityException, IOException {
TrustMaterial tm = new TrustMaterial(
/path/to/corporate/ldap.pem );
setTrustMaterial( tm ); // We ONLY trust our ldap.pem. cacerts
ignored!
KeyMaterial km = new KeyMaterial( /path/to/pkcs12.der,
secret.toCharArray() );
setKeyMaterial( km ); // Maybe our ldaps:// requires client certs?
}
}
=
And then tell Java to use it like so:
env.put( java.naming.ldap.factory.socket,
my.special.package.LDAPSocketFactory );
Java looks for the static getDefault() method when you provide a
SocketFactory like that to the LDAP stuff.
I already have a personal CLA on file with Apache. I'm not sure
what's up with the Corporate CLA / Software Grant my employer (Credit
Union Central of British Columbia) sent in August. Last time I
checked, CUCBC has yet to recieve a signed copy for their own records.
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] please check RC1
Thanx for beating me to it :) (very swamped atm).. I ran the tests and had a look at the rc and it looks good :) Mvgr, Martin Thomas Dudziak wrote: On 11/8/06, Martin van den Bemt [EMAIL PROTECTED] wrote: I'll have a look tomorrow evening (and testrun on ddlutils).. Sorry for being unresponsive.. Sorry, I meant to response, too. I've checked DdlUitls against the RC, and it looks good. I've updated DdlUtils with the RC jar so that I can put a DdlUtils RC sometime this week. cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] please check RC1
I'll have a look tomorrow evening (and testrun on ddlutils).. Sorry for being unresponsive.. Mvgr, Martin robert burrell donkin wrote: http://people.apache.org/~rdonkin/commons-betwixt - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] Propose 0.8 Release
Looks good Robert.. Mvgr, Martin robert burrell donkin wrote: i've taken a good look at the code base, tidied up some legal issues and some bad speiling. looks good. so, i've created a minimal release plan here: http://wiki.apache.org/jakarta-commons/Betwixt/0.8ReleasePlan. unless there are any other volunteers, i'll act as release managers. sound ok? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Security patch
Not yet.. I'll see if I can find some cycles tomorrow.. (Still on a holiday though and internet is not very stable over here) Mvgr, Martin Nick Lothian wrote: Did this get applied? I don't think I've seen the commit email On 10/12/06, Martin van den Bemt [EMAIL PROTECTED] wrote: I will apply the patch when no one beats me to it.. Mvgr, Martin Nick Lothian wrote: I'm aware that FeedParser is a dormant project, but the attached patch will fix the same problem in the Apache-Commons project version. FeedParser def isn't dormant http://code.tailrank.com/feedparser I just haven't officially announced that I'm moving it out of Apache. Just been to busy with official work to be a good maintainer :-/ Sorry - I didn't mean to imply that you aren't working on it - I know you've made the Tailrank stream available. All I meant was that FeedParser is listed in http://jakarta.apache.org/commons/dormant/index.html, which I believe means that no one is actively maintaining the Apache version. Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] What's needed for a 0.8 release ?
Highly appreciated Robert.. Mvgr, Martin robert burrell donkin wrote: On Sun, 2006-10-15 at 13:57 -0700, Thomas Dudziak wrote: Hi folks, hi thomas as we're reading the 1.0 release of DdlUtils, Martin noticed that we currently use a SVN build of commons-betwixt. Since we very much would like to have a proper released betwixt version instead, I wanted to ask what needs to be done for a 0.8 release. makes sense. i don't recall anything in particular that was really needed for a release (but i've been really busy and haven't really done any betwixt development for months) I'd be happy to help getting these things done, if someone could e.g. mark the issues necessary for 0.8 in JIRA ? i'll try to find some time in the next day or two - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Security patch
I will apply the patch when no one beats me to it.. Mvgr, Martin Nick Lothian wrote: I'm aware that FeedParser is a dormant project, but the attached patch will fix the same problem in the Apache-Commons project version. FeedParser def isn't dormant http://code.tailrank.com/feedparser I just haven't officially announced that I'm moving it out of Apache. Just been to busy with official work to be a good maintainer :-/ Sorry - I didn't mean to imply that you aren't working on it - I know you've made the Tailrank stream available. All I meant was that FeedParser is listed in http://jakarta.apache.org/commons/dormant/index.html, which I believe means that no one is actively maintaining the Apache version. Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons JEXL 1.1
I'll check it this weekend :) Mvgr, Martin Rahul Akolkar wrote: Ran the usual gamut of checks, looks good to me. snip/ --- [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I oppose this release because... snap/ -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Andrew Shirley as committer?
Any news on this ? Or did I completely overlook something ? Mvgr, Martin Henri Yandell wrote: On 8/4/06, Henri Yandell [EMAIL PROTECTED] wrote: I'd like to propose Andrew Shirley as a committer. Andrew's been doing tons for the CLI component - answering user questions, commenting on jira issues and serving up patches and unit tests to both his issues and other peoples issues. The only reason I've hesitated until recently is because CLI didn't have a clear direction (now it does). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. Vote passes. Binding +1s Davanum Srinivas Niall Pemberton Craig McClanahan Rahul Akolkar Oliver Heger Martin van den Bemt Phil Steitz Mario Ivankovits (I really need to remember to vote +1 from me too). Non-binding +1s Jörg Schaible - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Andrew Shirley as committer?
Thanx for clearing that up Andrew :) I was worried that something in the process somewhere went wrong :) Mvgr, Martin Andrew Shirley wrote: On Fri, Sep 01, 2006 at 08:57:30AM +0200, Martin van den Bemt wrote: Any news on this ? Or did I completely overlook something ? Hi, Firstly, apologies for not thanking the list for voting for this. Unfortunately due to some overly harsh procmail rules I didn't see the vote and only found out about this when Henri emailed me off list later. I have a signed CLA on my desk but havn't had a chance to fax it yet. Hopefully I will be able to do that this weekend and can progress from there. Thank you once again. Andrew Shirley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache SVN pointers
My sincere apologies .. Mvgr, Martin Henri Yandell wrote: Try again. There was a missing comma in the configuration file. Hen On 8/25/06, Kris Nuttycombe [EMAIL PROTECTED] wrote: Also, running svnpasswd also directs one to the same site, so my password *should* be okay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Component Versions
Every PMC should be able to do this, so enough people on this list. (just added dennisl to the jakarta-administrators) Mvgr, Martin Dennis Lundberg wrote: Rory Winston wrote: Hi guysAnyone got any idea how to add a new version to a JIRA component (so I can assign issues against it in the roadmap)? Cheers R On the project start page in JIRA, i.e. http://issues.apache.org/jira/browse/NET there should be a link Administer Project below the Create a new issue in project nn link. If you don't see the link you don't have enough rights in JIRA - ask a JIRA admin if you need more rights. To find out what rights you currently have click the Profile link in the top right corner. Your rights are listed in the left column under Groups. Once you get to the admin page just click on Manage versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Component Versions
What's the user you login with ? I found someone with the same name :) (if you found in the groups you are a jakarta-developer, than something is wrong with our permissions scheme, since it should allow you to add versions) Mvgr, Martin Rory Winston wrote: Could someone add me to the admins list so I can create new versions? I dont seem to have the appropriate privileges at present Thanks in advance ROory Martin van den Bemt wrote: Every PMC should be able to do this, so enough people on this list. (just added dennisl to the jakarta-administrators) Mvgr, Martin Dennis Lundberg wrote: Rory Winston wrote: Hi guysAnyone got any idea how to add a new version to a JIRA component (so I can assign issues against it in the roadmap)? Cheers R On the project start page in JIRA, i.e. http://issues.apache.org/jira/browse/NET there should be a link Administer Project below the Create a new issue in project nn link. If you don't see the link you don't have enough rights in JIRA - ask a JIRA admin if you need more rights. To find out what rights you currently have click the Profile link in the top right corner. Your rights are listed in the left column under Groups. Once you get to the admin page just click on Manage versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Component Versions
Added you to jakarta-administrators. I created a test user to see what it could do, but indeed no possibility to add versions.. Mvgr, Martin Rory Winston wrote: Thanks for the reply Martin. I can create new issues, but I dont see the Administer project link anywhere. I'm logging on as [EMAIL PROTECTED] Thanks Rory Martin van den Bemt wrote: What's the user you login with ? I found someone with the same name :) (if you found in the groups you are a jakarta-developer, than something is wrong with our permissions scheme, since it should allow you to add versions) Mvgr, Martin Rory Winston wrote: Could someone add me to the admins list so I can create new versions? I dont seem to have the appropriate privileges at present Thanks in advance ROory Martin van den Bemt wrote: Every PMC should be able to do this, so enough people on this list. (just added dennisl to the jakarta-administrators) Mvgr, Martin Dennis Lundberg wrote: Rory Winston wrote: Hi guysAnyone got any idea how to add a new version to a JIRA component (so I can assign issues against it in the roadmap)? Cheers R On the project start page in JIRA, i.e. http://issues.apache.org/jira/browse/NET there should be a link Administer Project below the Create a new issue in project nn link. If you don't see the link you don't have enough rights in JIRA - ask a JIRA admin if you need more rights. To find out what rights you currently have click the Profile link in the top right corner. Your rights are listed in the left column under Groups. Once you get to the admin page just click on Manage versions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Kris Nuttycombe as committer?
+1.. Mvgr, Martin Henri Yandell wrote: I'd like to nominate Kris as a committer. Kris has been active on the developer mailing list concerning the pipeline component for over a year, and has been involved on other threads as well (notably digester). I think he's been around long enough to have picked up the way of doing things and it'll be good for pipeline (and ultimately commons). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Andrew Shirley as committer?
+1 Mvgr, Martin Henri Yandell wrote: I'd like to propose Andrew Shirley as a committer. Andrew's been doing tons for the CLI component - answering user questions, commenting on jira issues and serving up patches and unit tests to both his issues and other peoples issues. The only reason I've hesitated until recently is because CLI didn't have a clear direction (now it does). [ ] +1 [ ] -1 Vote ends Wednesday 9th August. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[blog] Observations :)
Hi everyone, I have been following the blog closely and it's a nice concept (and probably usable outside commons as well). Although I can see the humor in Interviewing myself again, it would be nice if someone else did that :) To give to right example, I would like to interview Rahul Akolkar about SCXML. I will ping Rahul (unless he really doesn't want to), when I have the questions (currently have a deadline, so will probably do that after wednesday).. If preferred we can also wait till version 0.5 has been released :) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Splitting the mailing list
+1 on both.. Although I would also like to see the wiki notifications moved to the commits list. The only thing that needs to be done to actually make this work, is to actually advertise the mailinglist splitup. I missed the fact at some projects (don't remember which ones though), there was a seperate commit / jira list. So we need to adjust the docs of all projects, the mail2 page and regenerate the site when we do the move. I am in favour of autosubscribing everyone who is currently on dev. Mvgr, Martin Henri Yandell wrote: A while back Maven moved to having the commits and issues on different mailing lists and it seems to be going well. So I'd like to suggest: [EMAIL PROTECTED] - reply-to to commons-dev [EMAIL PROTECTED] - reply-to to commons-dev I think the wiki notifications should stay on the dev list as they're relatively low in number and they don't require any kind of restricted authentication to get involved with. Any contributor can hop in and fix a spelling mistake. The obvious worry is over new committers not subscribing to those lists. Firstly we can obviously make a point of mentioning that to new committers - but mostly I think the number of Re: svn commit and Re: [JIRA] emails that will appear will make them wonder what they're missing. Another advantage of the above just happened on the Tomcat list. A mistake by a committer caused 2700 svn commits to be sent out (to nearly 1000 subscribers). The ASF mail server took a good many hours to recover - most of the day I think. So both those kind of errors, and the large JIRA reorgs we've been doing would be hitting less people. One question: Do we automatically subscribe everyone on dev@ and let them unsubscribe. Or start the lists empty. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DONE] Re: Bugzilla-Jira migration
Done.. Only added for rwinston at eircom dot net, not for rwinst at checkfree dot com. If you need it on the latter account to, let me know.. Mvgr, Martin Rory Winston wrote: Can someone give me rights to administer issues on the [net] Thanks Rory Oliver Heger wrote: Henri Yandell wrote: On 5/27/06, Oliver Heger [EMAIL PROTECTED] wrote: On 5/16/06, Henri Yandell [EMAIL PROTECTED] wrote: The current structure is such that there are two groups. 'jakarta developers' and 'jakarta administrators'. I'm setting it so that the former maps onto committers, the latter onto PMC members. Thus the PMC can administer any Jakarta project - including adding people to the relevant groups etc. Hi, my jira account (oliver.heger at t-online.de) seems to have only rights of the jira user group, so I can't edit bugs. Can you give me more rights (or even better: create a new account for oheger at apache.org, for my mail address has changed anyway)? More rights added. If you create a new user I can transfer the rights over, will leave that to you though. Hen Many thanks, Hen! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
FYI maven 2 also has a commons-attributes plugin, written by (presumable) Carlos Sanchez (at least from the website). http://mojo.codehaus.org/commons-attributes-maven-plugin/ Maybe Carlos is interested to get involved ? (cc-ed him) Mvgr, Martin Henri Yandell wrote: On 7/9/06, Leo Sutic [EMAIL PROTECTED] wrote: Getting 2.2 out would be a nice endcap, and if you could just get the thing out in accordance with specs, that would be absolutely fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do the release manager stuff. Which build system is the most used with attributes, Ant or Maven? Are we releasing the Plugin as well as the two jars? Currently the build is maven install-snapshot maven install-plugin because the plugin depends on the snapshot 2.2 versions. Should the plugin update to 2.2 dependencies? The ant dist creates the 3 zips. Do you then zip that up as the release, and zip up a source tree as the source release? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [attributes] Planning a release
Meant you may be interested in maintaining commons-attributes, because of the maven2 plugin :) (assuming you are actually using commons-attributes).. Mvgr, Martin Carlos Sanchez wrote: mmm, were you talking about getting commons-attributes maven 1 plugin released? the truth is that I never used it On 7/10/06, Carlos Sanchez [EMAIL PROTECTED] wrote: It's as easy as adding plugin groupIdorg.codehaus.mojo/groupId artifactIdcommons-attributes-maven-plugin/artifactId version1.0/version executions execution configuration includes !-- here you include the classes you want to process -- include**/metadata/*.java/include /includes /configuration goals goalcompile/goal /goals /execution /executions /plugin On 7/10/06, Martin van den Bemt [EMAIL PROTECTED] wrote: FYI maven 2 also has a commons-attributes plugin, written by (presumable) Carlos Sanchez (at least from the website). http://mojo.codehaus.org/commons-attributes-maven-plugin/ Maybe Carlos is interested to get involved ? (cc-ed him) Mvgr, Martin Henri Yandell wrote: On 7/9/06, Leo Sutic [EMAIL PROTECTED] wrote: Getting 2.2 out would be a nice endcap, and if you could just get the thing out in accordance with specs, that would be absolutely fantastic. I'll stick around to get 2.2 out if $SOMEONE_ELSE (you) do the release manager stuff. Which build system is the most used with attributes, Ant or Maven? Are we releasing the Plugin as well as the two jars? Currently the build is maven install-snapshot maven install-plugin because the plugin depends on the snapshot 2.2 versions. Should the plugin update to 2.2 dependencies? The ant dist creates the 3 zips. Do you then zip that up as the release, and zip up a source tree as the source release? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SANDBOX-71) [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest
[ http://issues.apache.org/jira/browse/SANDBOX-71?page=comments#action_12419269 ] Martin van den Bemt commented on SANDBOX-71: Maybe this is some interesting story : http://www.wmware.com/psf/vmware_timekeeping.pdf (If I am not mistaking we (ehh gump) are running on vmware and not on solaris zones (else this doc is pretty much useless). Gump runs on debian btw. In short : a kernel option : clock=pit and in the vmx file the setting tools.syncTime=true (fixed our timing problems on some vmware servers.) Maybe pining infrastructure to see if this is an option that they can set ? [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest --- Key: SANDBOX-71 URL: http://issues.apache.org/jira/browse/SANDBOX-71 Project: Commons Sandbox Type: Bug Components: Id Environment: Operating System: other Platform: All Reporter: Joerg Schaible Assignee: Joerg Schaible Attachments: TimeBasedAIGTest.patch The unit tests for TimeBasesAlphanumericIdentifierGenerator fail with Gump sometimes for unknown reason. Unfortunately it seems, that the exactly test reports are unavailable. Nevertheless I suspect timing problems that interfere and may fail running the fixtures of the test within the same time slice. Therefore was in setUp() a sleep(50) call that might fail to create a unique operation environment for each test fixture depending on the OS/hardware environment. This synchronization has been replaced with an explicit loop waiting for the next time slice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r418646 - /jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
Thanx for a more rigid explenation :) Mvgr, Martin Luc Maisonobe wrote: Martin van den Bemt wrote : I read somewhere that linux will speed up doing encryption when eg the keyboard is used (those tokens are used in the linux SecureRandom generator. It is true when the generator is based on bytes read from the /dev/random device, false when /dev/urandom device is used. The former can block read access when the entropy pool gathering environmental noise is empty. This pool is replenished when events caused by keyboard use, mouse motion and interrupts from disk or other devices. This is the price to pay for cryptographically secure randomness except if you motherborad has some hardware-based random generator chip supported by the kernel (I think there are some) ... However this is far beyond the scope of this list. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r418646 - /jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
Don't laugh :)
I read somewhere that linux will speed up doing encryption when eg the keyboard is used (those
tokens are used in the linux SecureRandom generator.
Disclaimer : I ain't no expert on this, just read something somewhere..
Mvgr,
Martin
[EMAIL PROTECTED] wrote:
Author: psteitz
Date: Sun Jul 2 13:31:25 2006
New Revision: 418646
URL: http://svn.apache.org/viewvc?rev=418646view=rev
Log:
Suspended setSecureAlgorithm test, since it takes several minutes on Ubuntu.
Modified:
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
Modified:
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java?rev=418646r1=418645r2=418646view=diff
==
---
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
(original)
+++
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/random/RandomDataTest.java
Sun Jul 2 13:31:25 2006
@@ -419,7 +419,7 @@
!hex.equals(randomData.nextSecureHexString(40)));
/* remove this test back soon,
- * since it takes about 4 seconds */
+ * since it takes about 4 seconds
try {
randomData.setSecureAlgorithm(SHA1PRNG,SUN);
@@ -443,6 +443,7 @@
} catch (NoSuchProviderException ex) {
;
}
+*/
// test reseeding without first using the generators
RandomDataImpl rd = new RandomDataImpl();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
urs hardegger wrote: netcetera suggests the following changes to commons csv: 1) CSVPartser.java: StringBuffer.append(StringBuffer) is no supported in JDK 1.3. It would be a pitty to have an incompatibility because of this issue. In case this is performance critical, we surround this with an if statement for the JDK version. It is supported in jdk1.3.. Just cast the stringbuffer passed in to an object, so like StringBuffer.append((Object) StringBuffer)). Much more efficient than an if... Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
Nicolas De Loof wrote: It is supported in jdk1.3.. Just cast the stringbuffer passed in to an object, so like StringBuffer.append((Object) StringBuffer)). Much more efficient than an if... Surely a StringBuffer is already an Object? Or am I missing something here? StringBuffer has a new method in Java 1.4 to append another Stringbuffer without invoking it's toSring() method. Code that uses StringBuffer.append(stb) and compiled by a JDK 1.4 will not work on Java 1.3. I miself recommand Using StringBuffer.append(stb.toString()) that looks better than an apparently useless (Object) cast : checkstyle or IDE may warn for unecessary cast. Also may be a solution, which looks more readable. Though I fixed all these StringBuffer issues I had personally by adding the not very useless Object cast (this way you prevent the usage of the overloaded method which takes a StringBuffer). This way I don't have to worry whats under the covers , which in this case is according to you a toString(). Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] j2se1.3 compatibility / header line writer
That just works when compiling on jdk1.3 and will not work on jdk1.3 when compiled on jdk1.4 To prevent this, you specifically have to cast it to object to say use the append which takes an object or as Nicolas suggested a toString(), but the last one is not my favorite solution.. Mvgr, Martin sebb wrote: On 22/05/06, Nicolas De Loof [EMAIL PROTECTED] wrote: It is supported in jdk1.3.. Just cast the stringbuffer passed in to an object, so like StringBuffer.append((Object) StringBuffer)). Much more efficient than an if... Surely a StringBuffer is already an Object? Or am I missing something here? StringBuffer has a new method in Java 1.4 to append another Stringbuffer without invoking it's toSring() method. Code that uses StringBuffer.append(stb) and compiled by a JDK 1.4 will not work on Java 1.3. I miself recommand Using StringBuffer.append(stb.toString()) that looks better than an apparently useless (Object) cast : checkstyle or IDE may warn for unecessary cast. But that won't work so well on Java 1.4+. Can't one just use: sb1.append(sb2); for both 1.3 and 1.4, and let the method do the work as needed? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][all] Switch to Jira
They need to be migrated over when Atlassian has a way to accomplish this (at least I heard there was no option yet to export a project and reimport it again in another jira instance) Mvgr, Martin Felipe Leme wrote: On 5/2/06, Henri Yandell [EMAIL PROTECTED] wrote: I'd like to call a vote that we switch to Jira. Here's the loose migration plan: +1 * For each of the 37 components ** Create new project - name: Commons Xxxx, key . What would happen with projects already on Jira, like Jelly? -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][all] Switch to Jira
+1.. Mvgr, Martin Henri Yandell wrote: I'd like to call a vote that we switch to Jira. Here's the loose migration plan: * Make Bugzilla read-only * Import Commons project in Bugzilla into Commons project in JIRA This will pull over users, components, versions etc. * Setup notification scheme * Setup permission scheme * Setup group * For each of the 37 components ** Create new project - name: Commons Xxxx, key . ** Assign notification, permission and group ** Create relevant versions ** View component, bulk move all issues to new project * Cleanup Commons project (we'll still use it as a catch-all). Delete components/versions. The 37 components don't all have to be set up at the same time, we can take our time to move things out of the Commons project and into the individual Commons Foo projects. [ ] +1 [ ] -1 Vote to last 72 hours, 3 +1s required, 3/4 of active vote being +1. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] Migration effect Was: [VOTE][all] Switch to Jira
Sorry for the confusion, thought it was running on codehaus... Mvgr, Martin Henri Yandell wrote: We're going to be in the same Jira as Jelly, so no ned for migrating etc. Hen On 5/3/06, Martin van den Bemt [EMAIL PROTECTED] wrote: They need to be migrated over when Atlassian has a way to accomplish this (at least I heard there was no option yet to export a project and reimport it again in another jira instance) Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Jira?
Big +1 on a move to jira.. Mvgr, Martin Henri Yandell wrote: I know Jelly are on Jira already, and Struts have just moved over to Jira. Wondering what the view is nowadays on Commons moving to Jira? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][bugzilla] New component SCXML
Added.. Mvgr, Martin Rahul Akolkar wrote: BZ admins, Given the move of [scxml] to Proper and some of the recent feedback on the component name, I'd like to request a new Component under Commons -- SCXML (upper case). Thanks, -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][bugzilla] New component SCXML
Renamed.. Just for future knowledge : first you need to rename the component to eg chain2 and then change it back to Chain. Straight renaming from chain to Chain doesnn't work.. Mvgr, Martin Henri Yandell wrote: BZ admins - while you're in there could you change attributes to Attributes and chain to Chain? It messes the order up in some of the reports. Unsure if we can just go changing component text or not. Thanks, Hen On 4/20/06, Rahul Akolkar [EMAIL PROTECTED] wrote: BZ admins, Given the move of [scxml] to Proper and some of the recent feedback on the component name, I'd like to request a new Component under Commons -- SCXML (upper case). Thanks, -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote SCXML to Proper
+1, since all my concerns I had in the last vote are handled (besides the activity, now alos support from developers seems to be there by Craig and Dion). Mvgr, Martin Rahul Akolkar wrote: I propose, for the second time, that we move [scxml] to Commons Proper. As a quick reminder, the first vote [1] called three months ago was -1'ed for lack of developer support. -- [ ] +1 Move [scxml] to Commons Proper [ ] +0 I am fine with this move [ ] -0 I am not too keen, because ... [ ] -1 I am against this move, because ... -- This VOTE will remain open for a minimum of 72 hours. Why this proposal? Some data points, in no particular order (worth stressing that sentences prefixed by IMO are my opinions): * Repository-wise, [scxml] remains the most active component in the Commons sandbox. Most activity is building in new features, rather than iterating over any existing core (see commit messages in dev archives). * [scxml] is the most active sandbox component on the user list. Many users are keen on using it, reminders about the sandbox status of the component are handed out frequently (see user list archives). User demand has driven many of the latest changes to the code. * IMO, there is enough interest in the concept amongst Commons developers (see CommonsPeople wiki page). The code has been looked at critically by more than one Commons developers (see Tim's bugathon in BZ). * A [scxml] release will pave the way for a RDC 1.1 (its parent project) which is overdue in Taglibs, and already incorporates a SCXML-based dialog management strategy. IMO, [scxml] can add value to other projects within the ASF. Outside projects have also shown interest in using Commons SCXML as well (see this reference [2] in Eclipse land). * IMO, [scxml] brings in new ideas and people to Commons, and in the long run, its existence may also prove beneficial to its upstream Commons components such as JEXL. -Rahul [1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=113709951301607w=2 [2] http://dev.eclipse.org/mhonarc/lists/vtp-dev/msg00151.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Maven 1.0 vs. 2.0
I have a vote in my mailbox somewhere about a move of proxy, but I never saw a vote result, so by this I assume the vote never passed or have not received the vote result. Any pointers ? Mvgr, Martin James Carman wrote: All, What's the standard build system for Jakarta Commons right now? I know folks have been trying to move to M2, but is it stable enough and does it support all we need currently (like sshdeploy and the like)? I'd like to move Commons Proxy to the proper, but my M2 build isn't quite working the way I want it. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] redux: include jdk logger in API jar?
I am in favor of putting it back (don't consider this binding though). Being able to be a drop in replacement of previous versions is pretty important for logging I think.. Mvgr, Martin robert burrell donkin wrote: remy ran a regression test for RC6 (thanks :) we no long ship the jdk logger in API jar. however, tomcat uses jdk logger as it's default. so, by excluding the jdk logger, JCL 1.1 is no longer a drop in replacement at least for tomcat. so, i thought it'd be a good time to reconsider the decision to exclude the jdk logger. opinions? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release IO 1.2
+1.. With a note : I like to see a cleanup of issues. Where there is a request for eg a testcase, maybe just close the issue and if issues (most of the enhancements) could be applicable for this release, some note on why not added to the current release. This can be done after the release, but this can prevent from issues being open forever.. Mvgr, Martin Stephen Colebourne wrote: This is a vote for the release [io] v1.2 RC2 is here: http://people.apache.org/~scolebourne/commons-io/ Site here: http://people.apache.org/~scolebourne/commons-io/site/ Release notes here: http://people.apache.org/~scolebourne/commons-io/site/upgradeto1_2.html [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] csv writer..
Sorry for the very late reaction, I am trying to catch up with everything atm See inline.. Stefan Rufer wrote: Sometimes one has to knock twice :-) Basically I think it's a fine idea to have a csv writer with fixed width / separators configurable! Additionally, my thoughts about the code: IMO it's desirable to integrate CSVWriter and CSVPrinter - already the names state that they do very similar things and escaping/setting delimiters and so on is coded twice. Either use inheritance to extend CSVPrinter or (maybe even better) a delegation approach to add the additional functionality. For exaample methods like CSVPrinter.println(String[]) could be used to print in the fixed order given in the input array (with padding according to the config) and CSVWriter.writeRecord(Map) would only delegate to the CSVPrinter. I agree it needs integrating, but since the code in there is (at least in my view) pretty immature, the extra time involved in integrating and not knowing for sure if someone depended on the code that was in there, I chose to add a seperate package.. There was also talk about adding dependencies to speed up things (by Henri if I remember correctly), but I would like to focus on a good API and later make things better.. Then having a CSVConfig to set the different parameters looks good - especially with the load of parameters that are available. That's a thing the CSVPrinter could use as well. CSVConfig insn't a one on one mapping with the CSV stuff that already was in subversion at the time. So the real question is : do you depend on the original code in subversion or can we start breaking things ? Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [csv] Priorisation of enhancements
My problem was the same.. Currently catching up. I thing preformance is that last on the list. Premature optimization is most of the time a waste of time and it is better to have a good API, which allows easy optimization... My goal is the first shoot for a no dependency solution btw, in short : as lightweight as possible. Still not sure if our goals of commons-csv are a match though, so still in doubt if I should move the stuff I did to my own cvs tree on mvdb.org.. Feedback appreciated.. Mvgr, Martin Henri Yandell wrote: On 2/22/06, Stefan Rufer [EMAIL PROTECTED] wrote: Henry proposed a series of enhancements for the commons-csv, including: - performance (poor for current implementation) - features - naming/design (introduce Csv instead of String[][], introduce CsvStrategy class) For details of the tests and feature list see http://people.apache.org/~bayard/commons-csv/ IMO a possible priorisation of these tasks is: 1) naming/design 2) performance 3) features Given the slow performance of the current codebase, I'm tempted to think that 2) should be moving in parallel with 1). Either by hand-optimising the current one via a tool like YourKit or JProfiler; or by leaping over to generating a parser via a parser generator and making the assumption that it'll give us a performance improvement. Sorry for not replying to your previous emails; I'm right at the end of organizing a move to a new city, so my spare time has been demolished for the past few weeks. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] toMap conversion (bug)
David Graham wrote: We don't use LinkedHashMap because we depend on Java 1.3 not 1.4. Nobody really uses 1.3 anymore I beg to differ.. Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jar signing with jarsigner
Yep I used it on a regular base, although it's been a year or so, since I last did this.. I just took the short path : (re) sign all the jars that go into a webstarted application. All signatures in a/each jnlp file should be the same. So eg if all external dependencies are signed by the creator, you need to create a seperate jnlp (include like) file per unique cert, which can kind of suck from a release manager perspective. So my preferred way is to just (re) sign everything with the same cert.. Mvgr, Martin Paul Libbrecht wrote: Paul Libbrecht wrote: I suppose that, with Java Web Start, the jar-signing mechanism may request at least one authorization for each signing key... Has anyone tested a java-web-start application where jars are from different originators? If, indeed as I fear, there are several requests for trust presented to the user, I think ASF jar-signing would help nothing for JNLP deployments... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] jar signing with jarsigner
Paul Libbrecht wrote: To me this just means that the signature is, for JNLP deployers, a job of the deployer, or the end-developer and that a signature of Apache Foundation would not help. Correct with that ? From my point of view you are correct, though my opinion is not necessarily the opinion of everyone else. Can you tell a bit more ? E.g. is there a comparison between the fields of the JNLP and the fields of the certificate? I don't know of the internals of webstart on how it checks the certs in the jars Assume you have one jnlp file. The webstart client assumes that ALL jars are signed with the same cerficate, else it will stop with an error. This it to prevent users having to accept different certifacates. A way to use eg apache signed jars, is to add an extension jnlp file in the main jnlp file. There is one rule though : The extensions may not contain code from the same packages as contained in the main (I don't know the exact rules for this, but that is probably in the jnlp spec). In short : it gives the ASF extra burden to sign the jars (and release every ones in a while, since those certs actually expire at some point in time) and I don't see the real benefit users and the ASF is getting out of that. If people want to sign their application, just let them also sign all the other stuff along with it. Hope this helps :) Mvgr, Martin thanks paul Martin van den Bemt wrote: Yep I used it on a regular base, although it's been a year or so, since I last did this.. I just took the short path : (re) sign all the jars that go into a webstarted application. All signatures in a/each jnlp file should be the same. So eg if all external dependencies are signed by the creator, you need to create a seperate jnlp (include like) file per unique cert, which can kind of suck from a release manager perspective. So my preferred way is to just (re) sign everything with the same cert.. Mvgr, Martin Paul Libbrecht wrote: Paul Libbrecht wrote: I suppose that, with Java Web Start, the jar-signing mechanism may request at least one authorization for each signing key... Has anyone tested a java-web-start application where jars are from different originators? If, indeed as I fear, there are several requests for trust presented to the user, I think ASF jar-signing would help nothing for JNLP deployments... paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r384127 - in /jakarta/commons/proper/cli/trunk: maven.xml project.properties
The source of the images are in svg..
I just fixed the svg plugin for this purpose, but haven't released it yet.. (was kind of swamped
with job changing etc..)
Mvgr,
Martin
[EMAIL PROTECTED] wrote:
Author: bayard
Date: Tue Mar 7 22:05:02 2006
New Revision: 384127
URL: http://svn.apache.org/viewcvs?rev=384127view=rev
Log:
Removed the pdf and svg bits - not sure why [cli] would have these, yell at me
if there's a reason
Modified:
jakarta/commons/proper/cli/trunk/maven.xml
jakarta/commons/proper/cli/trunk/project.properties
Modified: jakarta/commons/proper/cli/trunk/maven.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/maven.xml?rev=384127r1=384126r2=384127view=diff
==
--- jakarta/commons/proper/cli/trunk/maven.xml (original)
+++ jakarta/commons/proper/cli/trunk/maven.xml Tue Mar 7 22:05:02 2006
@@ -54,15 +54,6 @@
tofile=target/test-classes/org/apache/commons/cli2/resource/TestBundle.properties/
/postGoal
- postGoal name=xdoc:transform
- attainGoal name=pdf:pdf/
- /postGoal
-
- preGoal name=pdf:prepare
- attainGoal name=svg:init/
- attainGoal name=svg:convert/
- /preGoal
-
preGoal name=dist:prepare-bin-filesystem
attainGoal name=ant:generate-build/
/preGoal
Modified: jakarta/commons/proper/cli/trunk/project.properties
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/cli/trunk/project.properties?rev=384127r1=384126r2=384127view=diff
==
--- jakarta/commons/proper/cli/trunk/project.properties (original)
+++ jakarta/commons/proper/cli/trunk/project.properties Tue Mar 7 22:05:02 2006
@@ -31,12 +31,3 @@
maven.jar.manifest.attribute.Implementation-Vendor-Id=org.apache
maven.jar.manifest.attribute.X-Compile-Source-JDK=${maven.compile.source}
maven.jar.manifest.attribute.X-Compile-Target-JDK=${maven.compile.target}
-
-maven.pdf.navigationFile=navigation-pdf.xml
-
-# Used in conjuction with the maven-svg-plugin.
-# see http://www.mvdb.org/maven/plugins/svg on howto install the plugin.
-# You need version 1.2
-maven.svg.target=all
-maven.svg.type=all
-maven.svg.onload=true
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Elect Sandy McArthur As Committer
Sorry for the late reaction.. +1... Mvgr, Martin robert burrell donkin wrote: Sandy McArthur has been contributing high quality patches for commons-pool for a few months now and has been the main driving force towards both fixing current issues and pushing the component forwards. He has demonstrated a deep knowledge of pool and has become involved in the general commons community. I therefore propose that he is elected a committer i'll tally the votes no earlier than 2400 GMT one week hence (Tuesday the 21st). Here's my +1 - robert --8-- [ ] +1 Elect Sandy [ ] +0 Tentative support but can't make informed judgement [ ] -0 Tentative opposition but can't make informed judgement [ ] -1 Do not elect Sandy -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Outstanding Commons bugs
Probably a good thing to ask Sandy McArthur wade through the pool issues.. Mvgr, Martin Henri Yandell wrote: I figure I can make myself useful by joining Martin and slowly going through the bugs. The following url shows a summary of the outstanding issues; wish I could find a way to include the creation date, but doesn't seem to be a way to graph by time in Bugzilla. http://issues.apache.org/bugzilla/report.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Commonsx_axis_field=bug_statusy_axis_field=componentwidth=700height=450action=wrapformat=table (minor note, need to change 'chain' to 'Chain') BeanUtils is the clear bug holder; with 77 open bugs. Lang + DBCP next on 39. --- Any plan of attack Martin? Figured I might try and hit CLI first as I'm looking at that code and pondering 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Outstanding Commons bugs
Thanx :) If you are going astray, people will probably reopen the issue.. Just ping us if you are in serious doubt.. Mvgr, Martin Sandy McArthur wrote: On 2/10/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Probably a good thing to ask Sandy McArthur wade through the pool issues.. I'll see what I can add to the pool bug reports. Not being an apache developer I don't feel right closing out issues unless it's really obvious it should be closed. I'll be a little agressive this time since you asked me to look into them. Just let me know if I'm going astray. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
