Re: [configuration][all] Support for OS environment variables
Hi Oliver, Oliver Heger wrote: Hi all, for [configuration] we have a feature request for supporting environment variables [1]. I searched the archives and found that this topic has been discussed before [2]. I was wondering whether situation has changed since then. My personal opinion is expressed in the Jira ticket in [1]. What do others think? Please note that the ticket contains an attachment with a simple implementation for accessing environment variables. Thanks Oliver [1] http://issues.apache.org/jira/browse/CONFIGURATION-284 [2] http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325 Well, the deprecation of System.getenv() has been removed with JDK 5 again ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
+1 Henri Yandell wrote: I've updated the release notes to match the website page: http://people.apache.org/~bayard/commons-cli/1.0-rc3/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (RC2)
+1 Builds and runs tests on my compiler zoo. - Jörg Henri Yandell wrote: I believe the RC1 issues have been taken care of, so here goes with a second try: http://people.apache.org/~bayard/commons-cli/1.0-rc2/ with the site in: http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/ One quirk to note. The site is from trunk while the release is from the 1.0.x branch. [ ] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons Modeler 2.0.1 RC2
+1 Tests succeed with my JDK zoo on Linux. - Jörg Niall Pemberton wrote: I have created a second release candidate for Modeler 2.0.1 following the problem Phil found in the first RC. Commons Modeler 2.0 didn't include the ant.properties file in the jar which is causing problems in Tomcat. Modeler 2.0.1 is a minor bug fix release fully backwards compatible to fix that issue and a few other build problems - full details in the release notes. Release Notes: http://people.apache.org/~niallp/modeler-2.0.1-rc2/RELEASE-NOTES.txt The artifacts being voted on are here: http://people.apache.org/~niallp/modeler-2.0.1-rc2/ Site: http://people.apache.org/~niallp/modeler-2.0.1-rc2/site/ RAT Report: http://people.apache.org/~niallp/modeler-2.0.1-rc2/rat-commons-modeler-2.0.1-src.txt [ ] +1 [ ] -1 - 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 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]
Re: [VOTE] Invite Simon Kitching to join the Apache Commons PMC
+1 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]
RE: [VOTE] Release commons-parent 3
Hi Phil, Phil Steitz wrote on Sunday, May 20, 2007 5:53 PM: On 5/20/07, Jörg Schaible [EMAIL PROTECTED] wrote: [snip] Right. Therefore we need to nail down the plugin versions. And yes, the settings from the pluginManagement in the parent is inherited. Should have been more clear in my question. If you partially configure a plugin in the parent, can you then just add stuff, such as the version, in a child without repeating the things specified in the parent config? If the answer to that is no then there is no value in partially configuring plugins in the parent. Configuration is merged from pluginDependency and plugins defined directly in the build section. Unfortunately it is not merged for plugins in the report section (which prevents setting source version for javadoc plugin in the configurtation of the parent anhd set individual links to external javadocs in the projcets). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
Stephen Colebourne wrote: I would expect a JDK change to be a major version number change. It not that you can commons-io no longer use with JDK 1.3 it is inly that you simply can no longer use any part of it. This works for other libs quite perfectly, why should c-io be an exception? - Jörg BTW: +1 on JDK 1.4, but use target 1.3 as compiler option - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3
Phil Steitz wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: On 18.05.2007, at 10:44, Jochen Wiedmann wrote: On 5/18/07, Torsten Curdt [EMAIL PROTECTED] wrote: Ehm... could we first sort out the repository question I brought up? ...and preferably also the related release process? We should also add the version numbers to the plugins. I'd say: let's work this out over the weekend and re-start the vote in a couple of days. I do think, that introducing a new deployment mechanism is a larger disruption than the changes made so far in 3-SNAPSHOT. In other words, I'd prefer to see this in a separate release. Apart from that, what prevents us from publishing version 3 now and a version 4, if the above questions are resolved? I do not understand this oh, just wait until I've got my favourite feature in whenever it comes to a release of the commons-parent. This thing doesn't need exhaustive QA or something like that, and it's not like we weren't able to manage 12 releases of it every year. I am with you on the release often ...but I on the other hand fixating the plugin versions and a working release setup is a bit of blocker for me ATM. So if you want to release now - fine. But I'd like to have another release that fixes those things ASAP anyway. So I was just wondering whether waiting a few more days would make such a big difference. I agree that we need to specify the plugin versions. If not in the parent, then the individual poms are going to have to do it (in which case, I don't know if there is value in specifying things in the parent. Could be ignorance here - are the plugin settings merged somehow?) The important requirement IMO is that anything that we release has a (perpetually) repeatable source build, both from the source distro and the svn tag. If we release something that has only an m2 build and does not specify plugin versions, we risk breaking that. Right. Therefore we need to nail down the plugin versions. And yes, the settings from the pluginManagement in the parent is inherited. But remember, currently you also need the exactly same Maven version to repeat a build. This will get better with newer versions, but currently this still applies. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A problem creating Java VM using JNI_CreateJavaVM
Hi Sagi, sagi nachum wrote on Saturday, May 12, 2007 10:21 AM: [snip] Any one have a solution? I cannot see that your problem has anything to do with any component of Apache Jakarta Commons. Therefore I doubt that you will receive an answer - even if you continue to post this question again - since it is simply off topic. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Roadmap
Hi Emmanuel, do you think 2.x is worth it simply because of dropping JDK 1.3? You might still introduce Preferences in JCC 1.x - it is simply not usable in JDK 1.3. However, the plan looks good for the addressed topics. - Jörg Emmanuel Bourg wrote on Thursday, April 19, 2007 10:46 AM: Hi, I was thinking lately about the orientation for the next releases. I focused on the design choices, some features like new configurations could be added at any moment. Here is what we could do, feel free to add your points to the list. Commons Configuration 1.5.x Java 1.3 compatible Deprecate everything to be removed in 2.x Backport of bug fixes until Configuration 3 is out Commons Configuration 2.x Java 1.4 compatible API cleanup, but no major refactoring Remove the deprecated methods and classes (HierarchicalXMLConfiguration, ConfigurationFactory ?) Remove the dependency on Commons Logging PreferencesConfiguration, ConfigurationPreferences Implement the Locators ? Add the generic get methods to the Configuration interface Backport of bug fixes after the release of Configuration 3 Commons Configuration 3.x Java 5 compatible New package : org.apache.commons.config Remove the dependency on Commons Collections In deepth refactoring of the API Make all configurations hierarchical by default Nodes are Configurations, like java.util.Preferences Generification of the API Pluggable converters (Morph, Beanutils ?) Emmanuel Bourg - 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: [configuration] Roadmap
nicolas de loof wrote on Thursday, April 19, 2007 11:44 AM: I agrea with Jörg : having some classes depend on java 1.4 should not make all the lib depend on java 1.4 when possible. This can be handled in maven2 with some compiler configuration (two executions with includes/excludes), just by having some naming convention (or deticated package) for java 1.4classes. Apart from the fact that using JDK 1.3 with M2 is really a pain ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Roadmap
Hi Niclas, nicolas de loof wrote on Thursday, April 19, 2007 11:58 AM: I'm using JDK 1.3 with M2 with no issue. To be clear, I'm TARGETING java 1.3 runtime, but my M2 runs over jrockit5. I'm using the compiler bootclasspath to point to SUN java 1.3 rt.jar to ensure compatibility. Yeah. And where does the JDK 1.3.1_xx RT came from? Everybody will have to put it into his own local repo (or use a provate remote one). For OSS this is a pain. Even more if you actually try to run the tests with a 1.3 JRE. Different story though ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Roadmap
Hi Emmanuel and Niclas, nicolas de loof wrote on Thursday, April 19, 2007 12:34 PM: sorted TOFU 2007/4/19, Emmanuel Bourg [EMAIL PROTECTED]: nicolas de loof a écrit : I agrea with Jörg : having some classes depend on java 1.4 should not make all the lib depend on java 1.4 when possible. This can be handled in maven2 with some compiler configuration (two executions with includes/excludes), just by having some naming convention (or deticated package) for java 1.4classes. I'm a bit reluctant to rely on Maven to manage a mixed build correctly. We have test cases that don't run on Java 1.3 for classes that do work on Java 1.3, it's getting weird. I feel it'll be easier to manage 2 branches than fine tuning Maven to build both Java 1.3 and Java 1.4 versions. We use a CI installation for XStream to manage such a setup. The XStream itself is compiled with JDK 1.5 (currently) for the release, but for CI we also use Ant to produce a (limited) JDK 1.3 version. What's missing so far is to compile and run the tests with JDK 1.3 only using the standard version... You're right about beeing easier to have multiple branches for various JRE, but from a user point of view, having the same jar working on java1.3 as minimal but having support for java 1.4 classes and maybe tiger is great. Same experience in XStream land. I have the same use case for some common-code in my corporate work. I had to setup such a multi-compiler conf for maven2, but using some simple convention made it work fine (example : java1.4 classes have java14 or jdbc3 prefix.). http://fisheye.codehaus.org/browse/~raw,r=1089/xstream/trunk/xstream/pom.xml, it's missing the rt.jar part though I'm not sure if testing under multiple JRE with various includes/excludes is possible/simple with maven. This would require not only the rt.jar but a fully installed JRE. If you're interested in such a build process I can give help. Me too. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] JCL in SLF4J flavour - a demo for discussion
Hi Boris, Boris Unckel wrote on Tuesday, April 03, 2007 6:50 PM: Hello Simon, Simon Kitching wrote: Would you both mind explaining what benefits you see in a new JCL implementation that cannot be obtained via java.util.logging? this is possible already today with x4juli, it does have a JCL native implementation. I'm no fan of the j.u.l design, but it seems to me less effort to use it than to fight it. What have I not understood? [snip] One last point: The extension of JUL always requires classes on the system classpath. This is especially annoying if you have application specific dynamic filters in a container because you cannot deploy everything together, you must change the container config. Yeah. That was one of my traps when I naively implemented a much more useful formatting. IMHO this is the main reason why JUL fails to attract people. And what would a new JCL do for anyone that they could not do by just using SLF4J via its JCL API? The SLF4J team have already done a lot of hard work; what benefit would there be to duplicating that? The benefit is to have the same way of control as SLF4J. Maybe the need for bridging is heavily reduced. I personally do not like the JCL - SLF4J - CurrentUnderlyingLibrary or the SLF4J - JCL - CurrentUnderlyingLibrary way. It seems better to me to have both wrappers directly sending to the underlying library. This code has been presented to be discussed, to get away from theoretical thoughts without any prove of concept or similiar - thanks for participating the discussion. What is your prefered way of underlying library discovery? Configuration. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Going TLP?
+1 Oliver Zeigermann wrote on Tuesday, April 03, 2007 9:18 AM: +1 to all said. I could even help. -0 to waiting until we have a clear idea about the rest of Jakarta as this is likely to never happen. Maybe a clearer idea will form after commons leaves Jakarta. Oliver 2007/4/3, Henri Yandell [EMAIL PROTECTED]: On 4/2/07, Phil Steitz [EMAIL PROTECTED] wrote: On 4/2/07, Henri Yandell [EMAIL PROTECTED] wrote: So with that said - I'd like to propose that we move to commons.apache.org. +1 We have talked about this lots of times before and some discussions have had us breaking commons itself apart into pieces. My +1 is for the whole of commons as an Apache TLP. To answer some other questions that have come up before and will resurface: +1 for only Java components (flame away, this is just my HO) Yep - though in reality this means: We'll do whatever the community wants to do. If someone proposes a Ruby library and we have a community interested in creating and supporting a Ruby library, then it would of course be strongly considered. The argument here is going to be in what we put in our resolution. Do we explicitly state Java, or do we leave things language agnostic and rely on the fact that it is our community, and generally our community is going to want to do Java and Java related things. +1 for bringing sandbox along And dormant. +1 for welcoming small components from other Jakarta subprojects +0 for waiting to do this until we have a clear idea of where the rest of the Jakarta subprojects are going. Once we go TLP, I imagine a few would head in our direction, whereas until we go TLP there won't be much of a decision made either way. I know I plan to suggest that the RDC taglib moves to Commons so it can be with SCXML (they're fairly tied aren't they?), and then the other parts of Taglibs can be put gently to sleep (unsure on JSTL). 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]
RE: [all] Going TLP?
Henri Yandell wrote on Tuesday, April 03, 2007 10:36 PM: On 4/3/07, Jochen Wiedmann [EMAIL PROTECTED] 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? I had three answers to this in my first email, here's a rewording/summary to see if I can explain them better: 1: The inactive parts of Jakarta is a millstone around the neck of the active parts. Trying to reorganize such things is a battle that I don't think is worth fighting (so your missing projects difference above). 2: Even if Jakarta does flatten down somewhat, it'll still have a huge umbrella type PMC who care for the name and history, but aren't involved in the remaining projects. So a c.a.p will have a much more focused PMC. 3: I believe that hanging around is just keeping the old broken system alive, us moving to c.a.p would be a big step in driving a Jakata solution along. The other solution is the 'promote all of Commons up to Jakarta Subprojects, and groupings and all that jazz' that we talked over a year ago; but I just don't think that's going to happen. I never got why things like ECS, ORO, regexp are not part of commons. What makes them different to logging or digester? I can understand the separation for something like POI, but not necessarily for components I would describe as utitlity libs. Maybe I'm lacking simply historical reasons though ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [parent-pom] versions
Torsten Curdt wrote on Sunday, April 01, 2007 2:17 PM: I've noticed that the plugin versions are not specified in the commons parent pom. From my experience this is a *really* bad idea as maven then picks the most recent from local repository. Which again can easily lead to inconsistent site builds across the team. So if no one objects I will add the latest version information to the plugins. For a reproducible site build. +1 I had once the situation, that a plugin was updated while I did a release shrug/. Therefore using fixed plugin versions are absolutely recommended. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] jci out of sandbox
+1 Torsten Curdt wrote on Thursday, March 29, 2007 1:27 AM: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons DBCP 1.2.2 (reprise)
+1, docs look good and my complete compiler zoo was successful. - Jörg Phil Steitz wrote: I have fixed the JRockit test compatibility issue raised during the first DBCP 1.2.2 release vote and would like to kick off a new release vote based on RC3, with links provided below. Since RC2, the following changes have been made; * Fixed JRockit test compatibility issue (tested with Linux versions of jrockit-R27.1.0-jdk1.5.0_08, jrockit-R27.1.0-jdk1.4.2_12, and jrockit-jdk1.5.0_06) * Added a note to release notes and README calling out the lack of JDK 1.6 / JDBC 4.0 support * Fixed 'Built-By' manifest attribute The release zips/tarballs are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/ Please note that, despite the release names, these distributions are *not* official apache releases, so should be used only for inspection/verification during the duration of this VOTE. Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/RELEASE-NOTES.txt http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/docs/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/docs/ The svn tag is DBCP_1_2_2-RC3. Assuming a successful VOTE, I will copy the tag to DBCP_1_2_2 and move the distributions above to the mirrors. Votes, please. The vote will close end of day (GMT) 28-March-2007. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] New committer - Stephen Kestle
+1 Stephen Colebourne wrote on Wednesday, March 21, 2007 12:27 AM: 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: [cli] findings...
Oliver Heger wrote: Henri Yandell wrote: On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: snip/ 3) Let's remove the commons-configuration-integration and RESEARCH_CLI_2_ROXSPRING branch. There was no activity within the past 20 months unless I am mistaken. So I think we can safely say these tries were dead-ends. Let's check with Oliver on the commons-configuration-integration. I know that was a subject that's come up a few times (last time I needed a cli type thing, I went with configuration and much preferred it; it just needs a cli like option). I had a short glance at this branch (I was not aware that it existed before). There are the two classes ConfigurationCommandLine and CommandLineConfiguration that implement the integration in both directions. They are pretty simple (probably because the APIs of cli and configuration are similar), but seem to be functional. I am not sure how to proceed here. The code of the CommandLineConfiguration class could be added to CONFIGURATION-211 (enhancement request for a command line configuration). But should configuration declare another dependency to cli? It's optional ... why not? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Hi Oliver, +1 build from source with Ant on Linux with Sun JDK 1.4, 1.5, and 1.6, with IBM JDK 1.4, Blackdown JDK 1.4 and JRockit 1.4. however, there were some problems with the build. Maven does not work, since it does not find its deps: = % === [EMAIL PROTECTED] ~/java/commons-transaction-1.2-src $ maven clean test __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 Attempting to download geronimo-j2ee-connector_1.5_spec-1.1.jar. WARNING: Failed to download geronimo-j2ee-connector_1.5_spec-1.1.jar. Attempting to download geronimo-jta_1.0.1B_spec-1.1.jar. WARNING: Failed to download geronimo-jta_1.0.1B_spec-1.1.jar. Attempting to download geronimo-servlet_2.4_spec-1.1.jar. WARNING: Failed to download geronimo-servlet_2.4_spec-1.1.jar. Attempting to download commons-codec-1.2.jar. 29K downloaded Attempting to download commons-logging-1.1.jar. 51K downloaded The build cannot continue because of the following unsatisfied dependencies: geronimo-j2ee-connector_1.5_spec-1.1.jar geronimo-jta_1.0.1B_spec-1.1.jar geronimo-servlet_2.4_spec-1.1.jar Total time: 10 seconds Finished at: Fri Mar 09 04:33:03 CET 2007 = % === The IBM JDK 1.5.0.3 and JRockit 1.5.0.6 compiler tries to open the .pom file as archive that it finds on the classpath and fail with an error: = % === build: [javac] Compiling 37 source files to /home/joehni/java/commons-transaction-1.2-src/build/classes [javac] error: error reading /home/joehni/java/commons-transaction-1.2-src/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom; Error opening zip file /home/joehni/java/commons-transaction-1.2-src/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom = % === build: [javac] Compiling 37 source files to /home/joehni/java/commons-transaction-1.2-src/build/classes [javac] error: error reading /home/joehni/java/commons-transaction-1.2-src/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom; Could not find End Of Central Directory = % === You should use a pattern in the file set. Nothing that prevents the vote to be cancelled though. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons-Attributes 2.2 Corrupted Manifest
Hi Nico, nicolas de loof wrote on Tuesday, March 06, 2007 10:00 AM: I already asked for a 2.2.1 release to remove those -Extension in manifest, as they break running my app under tomcat 4. Those libs are only required by the compiler jar, not the api (runtime) jar, tho they can be removed from the manifest. This manifest is hand-writen and is included during the ant build. Building with maven doesn't include it. @see http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg 88665.html OK, so the entries itself are OK regarding manifest spec, but they cause the java runtime to start further actions that fail. According the spec these entries are used to define the dependencies for applets ... so I wonder also why they are present in this manifest at all. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-Attributes 2.2 Corrupted Manifest
Leo Sutic wrote: Hi all, the Commons-Attributes 2.2 jars have corrupted manifest.mf files. This is apparently causing a bit of problems for users. The issue is in the extension properties: ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5. jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1 .5.jar As you can see, there are spaces and cr/lfs in the URLs. This causes maven 2 etc. to fail. AFAICS the manifest is OK according the spec (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Name-Value%20pairs%20and%20Sections) by respecting the line length of 72 bytes. Longer lines violate the manifest ... Frankly, I have no desire nor time to get a new release out. What I wonder, however, is if we can treat this as a corrupted file issue and I can just fix the jars in the distribution directory by replacing or deleting the manifest.mf file in them. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons-Attributes 2.2 Corrupted Manifest
Henri Yandell wrote on Monday, March 05, 2007 9:45 PM: On 3/5/07, Leo Sutic [EMAIL PROTECTED] wrote: On 3/5/07, Jörg Schaible [EMAIL PROTECTED] wrote: Leo Sutic wrote: Hi all, the Commons-Attributes 2.2 jars have corrupted manifest.mf files. This is apparently causing a bit of problems for users. The issue is in the extension properties: ant-Implementation-URL: http://www.ibiblio.org/maven/ant/jars/ant-1.5. jar qdox-Extension-Name: qdox qdox-Implementation-Version: 1.5 qdox-Implementation-URL: http://www.ibiblio.org/maven/qdox/jars/qdox-1 .5.jar As you can see, there are spaces and cr/lfs in the URLs. This causes maven 2 etc. to fail. AFAICS the manifest is OK according the spec (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Name-V alue%20pairs%20and%20Sections) by respecting the line length of 72 bytes. Longer lines violate the manifest ... Heh. Thanks - I had no idea. Well, that explains where those line breaks came from. I guess the ball is in the other court then. I'm aiming to make a 2.2.1 release at some point for this - but low energy towards it currently. The above is good to know, said manifest was generated by a Sun JDK (1.4 I presume) on a Linux box, so nothing out of the ordinary. Is there an issue raised with Maven for this? Don't think so. What exactly is the reported problem? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dormancy proposals
Henri Yandell wrote on Wednesday, February 21, 2007 8:43 AM: On 2/20/07, Jörg Schaible [EMAIL PROTECTED] wrote: Henri Yandell wrote on Wednesday, February 21, 2007 3:33 AM: I'd like to propose that the following be moved from the Sandbox into Dormant. * i18n I am using an older snapshot in production and I have added contributions to JIRA - it's just that I never committed directly. If nobody else cares I can do something and you may give it also a 3 month review ... Sure. I'll consider that a -1 and add to the three month review. If I remember in 3 months. And I find this thread :) Hehehe :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons DBCP 1.2.2
Hi Phil, Phil Steitz wrote: On 2/15/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Phil, sorry I am late and I downloaded the source package, compiled and run all tests in Gentoo Linux with Maven for Sun JDK 1.4.2, Sun JDK 1.5.0, Blackdown JDK 1.4.2_03, IBM JDK 1.4.2.7, and IBM JDK 1.5.0.3 and all tests run fine for these. It fails for JRockit 1.4.2.11 and 1.5.0.6 though with: == % == Testsuite: org.apache.commons.dbcp.TestBasicDataSource Tests run: 33, Failures: 1, Errors: 0, Time elapsed: 4,364 sec Testcase: testCreateDataSourceCleanupThreads( org.apache.commons.dbcp.TestBasicDataSource): FAILED expected:1 but was:2 junit.framework.AssertionFailedError: expected:1 but was:2 at org.apache.commons.dbcp.TestBasicDataSource.testCreateDataSourceCleanupThreads (TestBasicDataSource.java:334) at jrockit.reflect.VirtualNativeMethodInvoker.invoke( Ljava.lang.Object [Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) == % == Ugh. The test that is failing is to confirm the fix for DBCP-93, which is essentially a thread leak. In retrospect, it was probably not a good idea to include a check of the form assertEquals(threadCount, Thread.activeCount()), as appears in this test, since Thread.activeCount is not really guaranteed to be accurate. In the case of JRockit, the docs mention something to the effect of monitoring threads being spawned periodically. Before the fix, the test case would have orphaned 10 threads, post fix JRockit is reporting one extra thread. I think it is best to do something to fix this, but am not sure what would be best. Eliminating the test is one option, or changing the test to allow one or two extra threads would also work. I see this as a blocker, since this test was introduced in 1.2.2 and the build should succeed on JRockit. Any suggestions? When I try to run the tests from within Eclipse with the JRockit JDK, anything works. OTOH when I tried to run the tests yesterday with Maven under heavy load of my machine (compiling KOffice), the test succeeded also, but two others were failing :-/ Nevertheless, the test above fails on normal terms always on my machine with Maven/JRockit, so it at least repeatable. I looked at the test, but it seems I don't grok from a quick look enough of the internals of dbcp to say anything useful. Since I have some experience with other concurrent tests, what about joining the evictor thread and wait for it to stop (at least for a reasonable time)? If it has a unique name, you can address it from the test ... Additionally, you've realized that the complete package is no longer compatible with JDK 6? I don't know what we can really do about it, since the new JDBC version defines a lot of new methods for java.sql.Statement and java.sql.Connection and - even worse - some of those methods have arguments or return values only avalable in JDK 6. This is being tracked as DBCP-191. We can discuss this post 1.2.2, at which time we may want to create a separate 1.6 branch and version. OK, I did not recognized this. Unless someone comes up with a really clever solution, there's nothing we can do about it and this is not even documented somewhere in the release. Yes, should probably have included DBCP-191 in the significant open issues in the release notes. I will do that. Thanks for the feedback and testing. Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dormancy proposals
Henri Yandell wrote on Wednesday, February 21, 2007 3:33 AM: I'd like to propose that the following be moved from the Sandbox into Dormant. * i18n I am using an older snapshot in production and I have added contributions to JIRA - it's just that I never committed directly. If nobody else cares I can do something and you may give it also a 3 month review ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status of the Sandbox?
Henri Yandell wrote on Monday, February 19, 2007 5:58 AM: I'm interested in knowing where things are with each of the non-dormant sandboxes. ie) Convince me why I shouldn't be proposing that a component be moved to dormant. -- [snip] id - Jörg seems to be working on this. Any plans Jörg? Due to lack of time currently in maintaining mode i.e. I am anwering questions, but it is on my TODO list ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Stephen Colebourne wrote: Jochen Wiedmann wrote: On 2/16/07, Jörg Schaible [EMAIL PROTECTED] wrote: (1) The md5 files do not contain the file name, which is standard for commons components (see section 2 of [1]). This is the way Maven 2 generates *and* checks it. So if you change those, I am quite sure, that every M2 user will get always a warning because of the checksum! I believe that Olivers and your concerms can be resolved by proposing that the files that go into /www/www.apache.org/dist are distributed as proposed by Oliver. OTOH, the files that go into the Maven repository won't have a file name. See commons-io in the maven2 repository: http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/1.3/commons-io-1.3.jar.md5 The *filename part is present. Does it cause any issues? I don't know, I don't use maven 2. I doubt it though as no ones ever complained. Well, I said *if* any user gets a warning I am -1 to such a change. Honestly I don't know either, but M2 is not the only software anymore accessing the public repos. Interfering in the way the deploy plugin works is at current stage a major hassle and IMHO not worth to prevent a release. If we wanna have such a change, we have to change the way the plugin works. - Jörg - Jörg Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
Oliver Heger wrote: Two minor points: (1) The md5 files do not contain the file name, which is standard for commons components (see section 2 of [1]). This is the way Maven 2 generates *and* checks it. So if you change those, I am quite sure, that every M2 user will get always a warning because of the checksum! [snip] (2) In the jar generated by the ant build the LICENSE is missing. (2) is probably less important for components that use maven as preferred build tool. I am not sure how important (1) is. Otherwise everything looks good. So I am +1 when (1) is fixed. If every user gets a warning when this is fixed, I am -1 on this fix :D [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-fileupload 1.2 (4th attempt)
+1 building from source in Gentoo Linux with Maven 1, all tests pass for all my JDK's (1.3.1 to 1.6 from various vendors). - Jörg Jochen Wiedmann wrote: Hi, this is going to kill me, but I'd like to call for a release of commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is available from http://people.apache.org/~jochen/commons-fileupload/dist The generated site is at http://people.apache.org/~jochen/commons-fileupload/dist The SVN tag is commons-fileupload-1.2rc4 Compared to rc3, the following things have been changed: * The LICENSE.txt and NOTICE.txt files are now added to all jar files. (They had been added before, but been overwritten when the assemblies have been created.) * A workaround for a bug in the maven-site-plugin has been added. This bug prevented static resources being added. In particular, the logo of the commons-fileupload project was missing. * The RAT report is now added to the projects reports. * The clirr report is now also added to the project reports. (No idea why this wasn't the case before.) Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3.1 (RC3)
Henri Yandell wrote: On 2/15/07, Jörg Schaible [EMAIL PROTECTED] wrote: Oliver Heger wrote: For the protocol: I think I know now what is going on: Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. Now I am on windows, but I happen to have some unix commands in my path (these are windows ports of some typical unix commands), including chmod. So the execution of chmod is successful, but obviously the command does not have the desired effect: the files can be deleted, and no exception is thrown. This causes the tests to fail. I guess this is a rather unusual scenario. Well, IMHO not *that* unusual. A lot of people use Cygwin (incl. myself), MKS Toolkit, Microsoft's Posix Tools, MingW32 or software that installs such things to run. On a Windows box c-io should not try to run chmod. Agreed. Could someone add it to JIRA? Done. IO-115. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3.1 (RC3)
Oliver Heger wrote: For the protocol: I think I know now what is going on: Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. Now I am on windows, but I happen to have some unix commands in my path (these are windows ports of some typical unix commands), including chmod. So the execution of chmod is successful, but obviously the command does not have the desired effect: the files can be deleted, and no exception is thrown. This causes the tests to fail. I guess this is a rather unusual scenario. Well, IMHO not *that* unusual. A lot of people use Cygwin (incl. myself), MKS Toolkit, Microsoft's Posix Tools, MingW32 or software that installs such things to run. On a Windows box c-io should not try to run chmod. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: m2 groupIds
Hi Carlos, Carlos Sanchez wrote on Wednesday, February 14, 2007 8:25 AM: right a relocate pom for ALL versions is required to avoid duplication on classpath BUT as I said almost everybody will have cached previous versions of commons so they won't see the relocation until they delete local repo and the poms with relocation info get downloaded. Maven should give here better support. If it ever downloads a relocation POM it should keep the relocation information in a separate DB/storage and take it always into account when resolving aritfacts no matter which version. Scenario 1 would be completely the the enough then. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: m2 groupIds
Carlos Sanchez wrote on Wednesday, February 14, 2007 8:40 AM: iirc you have very different jars in the two groupids, that's not relocation, that would actually change the binaries for users This was for one single release only (because we did not realize, that the M1 and M2 repos are completed automatically with the missing artifacts), but not for all the old releases where I also adjusted the POMs with the relocation section. Nevermind it is history now, but the complete discussion shows, that the process is still not clear and that there's no optimal solution either. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: m2 groupIds
nicolas de loof wrote on Wednesday, February 14, 2007 9:19 AM: That would'nt work anyway If you allready downloaded commons-cc:1.1 and get (maybe transitiviely) a dependency on org.apache.commons:cc:1.2, you will get both in your classpath as maven will not kwon those tow groupIds are for the same artifact. We can't expect maven to reload the 1.1 POM that is allready present in local repository (an other cache/mirror/proxy) We could only expect maven to know from the 1.2 POM that what the old groupId was to establish the two artifacts are same. This requires some changes in the POM format to include a section about artifact history in maven repo. Yep. You're right. Another missing gap. If the new POM contains some information, that it had been relocated from a different place, Maven could take it into account. Currently Maven knows about the relocation only, if you try to download an uncached version from the repo with the old groupId. If the dep is referenced with the new groupId already, Maven is as blind as reading old POMs from the cache. I fear switching the groupId for commons will create some real disruptions :-/ - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] svn commit: r506585 [1/2]
Luc Maisonobe wrote on Monday, February 12, 2007 11:01 PM: Rahul Akolkar wrote : On 2/12/07, Luc Maisonobe [EMAIL PROTECTED] wrote: Yes, it seems many files have strange settings. I use a Linux box and on a fresh checkout, I get some files with DOS-like line endings. If I set them to a line ending compliant with my local host, then set the property to native and then commit the change, this will create (hopefully only once) a huge diff. If I understand correctly, after that change, further commits will not depend on contributor platform. Do you want me to do that or is there a smarter way ? Sounds good, I had earlier missed that you also corrected the svn:eol-style! I will reset the svn:eol-style property for a number of files soon. It seems 38 text files in the [math] repository do not have any eol-style property set. In my local worspace, they show up as 22 with DOS-like eol (which is wrong in my box) and 16 with Unix-like eol (which is right in my box). I will try to fix everything in two steps for clarity in a few minutes. You should expect a huge diff when the 22 DOS files will be checked in, sorry for inconveniance. BTW: svn will do the conversion automatically if you set the svn:eol-style ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: m2 groupIds
Hi Hen, Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM: Second try - having had it explained to me on #maven why relocating is important [so commons-lang:commons-lang 2.1 and org.apache.commons:commons-lang 3.0 are considered the same and a transitive clash can be recognized]. So, second suggestion: We declare a point after which we won't do any more m1 releases. We'll move wholesale over to m2. On that day (or as near as we can), we run a script on all commons-*/ to do the relocation for all of them ( http://maven.apache.org/guides/mini/guide-relocation.html ). I know I'm clueless - so please change this to whatever the clueful one is. I think it's time for us to drop m1 and move to m2. you cannot change the old POMs anymore, in that case this description is obsolete. The only valid option is to use the new groupId with a new release and provide for this new release a relocation POM at the former location. This was Carlos' advice after a two week hassle to do such a transition with XStream. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: m2 groupIds
Hi Carlos, Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM: you can change the old poms to relocate to a new location as long as the new location has the same old jars and poms (just groupId change). IIRC your case was different. So, I' see two options for relocation: 1) when new version is out with new groupId add relocation pom in old location just for that new version. + Users updating version in old location will get a warning + easy to do - users may end having old versions and new versions in the classpath, that they would have to solve with exclusions 2) relocate all versions to new groupId + all users will only notice the warnings when using old group + no classpath problems in builds from scratch - harder to implement, will need to write some code - people with commons artifacts cached (almost everybody) will experience same problems as in 1, possibly getting two versions in the classpath I don't know whether I should laugh or cry because you offered option 2 at all. I took option 2 and adjusted all the old releases of XStream on the Codehaus repo, but they do not get synced to the public repo, since the space for the relocation POMs is already occupied by the old files. It was you who said, nothing can be done about this. Why should the synchronization of the Apache repo be different to the one of Codehaus? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Heads-up: svn commit: r506158 - /jakarta/commons/proper/pool/trunk/pom.xml
[EMAIL PROTECTED] wrote: Author: bayard Date: Sun Feb 11 14:42:50 2007 New Revision: 506158 URL: http://svn.apache.org/viewvc?view=revrev=506158 Log: M2 build Added: jakarta/commons/proper/pool/trunk/pom.xml (with props) Added: jakarta/commons/proper/pool/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/pool/trunk/pom.xml?view=autorev=506158 == --- jakarta/commons/proper/pool/trunk/pom.xml (added) +++ jakarta/commons/proper/pool/trunk/pom.xml Sun Feb 11 14:42:50 2007 @@ -0,0 +1,191 @@ +?xml version=1.0? +!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the License); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- +project +xmlns=http://maven.apache.org/POM/4.0.0; +xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; +xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; [snip] The license header should go into the prpject tag - otherwise it is cleared by the relase plugin and the released version does not contain it anymore ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
Hi Niall, Niall Pemberton wrote: I tried running the RAT[1] tool over the RC but invalid characters in conf/testEncoding.xml caused RAT to fail[2] :-( Removing that file it higlighted a licensing issue - MockStaticMemoryInitialContextFactory has a Copyright The Spice Group and indicates that a copy of its license should be in LICENSE.txt - I checked LICENSE.txt and it didn't have one (just the ASF license). yes and no. The code is in use for unit tests but does not belong to the core distribution i.e. users of commons-configuration do not inherit this code and do therefore have to add only the ASF license. How did we handle such cases earlier? [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3.1 (RC3)
Henri Yandell wrote: Going with RC3: http://people.apache.org/~bayard/commons-io/1.3.1-rc3/ The only change is that I've fixed the manifest to say 1.3.1 and not 1.3. [ ] +1 [ ] -1 Hen +1 from me - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi Jochen, Jochen Wiedmann wrote: On 2/9/07, Jörg Schaible [EMAIL PROTECTED] wrote: testProgressListener(org.apache.commons.fileupload.ProgressListenerTest): FAILED expected:-128 but was:-128 This sounds like two different kinds of objects with same values, for example (short) -128 as opposed to (int) -128. Yeah, but it does not make sense. The error message indicated, that an assertion failed and in that code I cannot see anywhere a call with an Object, assertXXX it is always called with the native types. Could you please be so kind to add some logging code that checks this? well, I tried hard to find the cause for this, but failed so far. If you look at the stack trace, it simply does not make sense also. Nevertheless when I run the test from within Eclipse with the JRockit 1.5 runtime, the ProgressListenerTest fails every 2nd execution in exactly the reported way. Due to some sysouts I know now, that it happens when the runTest is called the 2nd time *after* the first call to the listener. Unfortunately if you try to debug it, everything seems to work well. OTOH I am quite unfamiliar with the code ... Maybe you wanna try it youself, JRockit can be freely downloaded at http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
Niall Pemberton wrote: On 2/10/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Niall, Niall Pemberton wrote: I tried running the RAT[1] tool over the RC but invalid characters in conf/testEncoding.xml caused RAT to fail[2] :-( Removing that file it higlighted a licensing issue - MockStaticMemoryInitialContextFactory has a Copyright The Spice Group and indicates that a copy of its license should be in LICENSE.txt - I checked LICENSE.txt and it didn't have one (just the ASF license). yes and no. The code is in use for unit tests but does not belong to the core distribution i.e. users of commons-configuration do not inherit this code and do therefore have to add only the ASF license. How did we handle such cases earlier? Since its in the source distro then IMO we need to comply with their license as we are re-distributing their code. In their code it says the license should be included in the LICENSE file: http://spice.codehaus.org/jndikit/license.html So it looks to me like you need to add it into LICENSE.txt and put a line in NOTICE.txt saying something like the following: This product includes software developed by The Spice Group (http://spice.codehaus.org/). This might be case for the source distro, but not for the binary one ... which makes this tricky. Maybe it should be added with the additional comment, that this only applies with the test code of c-c. Having said that I'm no legal expert - to get a proper opinion then you should ask on legal-discuss@apache.org IANAL also ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Jochen Wiedmann wrote:
Hi, Jörg,
On 2/10/07, Jörg Schaible [EMAIL PROTECTED] wrote:
well, I tried hard to find the cause for this, but failed so far. If you
look at the stack trace, it simply does not make sense also. Nevertheless
when I run the test from within Eclipse with the JRockit 1.5 runtime, the
ProgressListenerTest fails every 2nd execution in exactly the reported
way. Due to some sysouts I know now, that it happens when the runTest is
called the 2nd time *after* the first call to the listener. Unfortunately
if you try to debug it, everything seems to work well. OTOH I am quite
unfamiliar with the code ...
Maybe you wanna try it youself, JRockit can be freely downloaded at
http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
Could you please replace line 93 in the ProgressListenerTest with the
following:
/**
* This used to be
* assertEquals((byte) j, (byte) istream.read());
* but this seems to trigger a bug in JRockit, so
* we express the same like this:
*/
byte b1 = (byte) j;
byte b2 = (byte) istream.read();
if (b1 != b2) {
fail(Expected + b1 + , got + b2);
}
That seems to work for me, for whatever reason.
Same here. Strange. Well, so this is definitely nothing that should prevent
this release
+1
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
Hi Hen, Henri Yandell wrote: [snip] Unpacking the source, the ant and m1 builds work fine, but the m2 build fails because it can't find: javax.sql:jdbc-stdext:jar:2.0 There's nothing we can do about this. Sun does not allow redistribution without click-through. OTOH, it is only necessary for older JDKs ... but I cannot remember for which ones. With what JDKs is c-configurations compatible? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lang 2.3 problems Was: [VOTE] Lang 2.3 (RC2)
Hi Hen,
Henri Yandell wrote:
On 2/8/07, Jörg Schaible [EMAIL PROTECTED] wrote:
[snip]
It seems that we cannot format correctly also if the JDK fails. :-/
Ack :(
What kind of environment are you in? timezone/platform/jdk version/locale?
CET/Gentoo Linux/Sun JDK 1.5.0_10/de_DE
Same with Sun JDK 1.6.0, Sun JDK 1.4.2_11, Blackdown JDK 1.4.2_3, IBM JDK
1.4.2_5, IBM JDK 1.5.0_3, JRockit 1.4.2_11 and JRockit 1.5.0_6.
Additionally my JDK zoo reveiled more failing tests. The following tests
fail additionally with IBM JDK 1.4.2_5 (one 'anormality' with this JDK is,
that the fields returned by reflection are in reverse declaration order, if
the class was compiled with this JDK):
= % ==
Testsuite: org.apache.commons.lang.builder.BuilderTestSuite
Tests run: 263, Failures: 8, Errors: 0, Time elapsed: 0,451 sec
Testcase:
testReflectionHierarchyHashCode(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:11785967 but was:1276487
junit.framework.AssertionFailedError: expected:11785967 but was:1276487
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHierarchyHashCode(HashCodeBuilderTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHashCodeExcludeFields(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:862547 but was:865283
junit.framework.AssertionFailedError: expected:862547 but was:865283
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHashCodeExcludeFields(HashCodeBuilderTest.java:480)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchyArrayList(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
junit.framework.ComparisonFailure:
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchyArrayList(ToStringBuilderTest.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchy(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...a=a,transientA=t... but was:...transientA=t,a=a...
junit.framework.ComparisonFailure: expected:...a=a,transientA=t... but
was:...transientA=t,a=a...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchy(ToStringBuilderTest.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
junit.framework.ComparisonFailure:
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
at
org.apache.commons.lang.builder.ToStringBuilderTest.testSelfInstanceTwoVarsReflectionObjectCycle(ToStringBuilderTest.java:543)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSimpleReflectionStatics(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...String=staticString,staticInt=12345... but
was:...Int=12345,staticString=staticString...
junit.framework.ComparisonFailure:
expected:...String
Re: Lang 2.3 problems Was: [VOTE] Lang 2.3 (RC2)
Henri Yandell wrote: Wow, lots of failing tests. Thanks Jörg. If only we had as many JDKs being tested on the nightly builds. Any chance you could get these in JIRA? I agree with you that they shouldn't hold up the build [and the Konqueror bit is something to add under the Commons All JIRA project]. LANG-318 LANG-319 (more or less for the record) LANG-320 COMMONSSITE-14 [In the meantime, I'll continue building RC3] Hard times :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3.1 (RC2)
+1 Built from source under Gentoo Linux and all tests pass with - Sun JDK 1.5.0 - Sun JDK 1.6.0 - IBM JDK 1.5.0 - JRockit JDK 1.5 - Blackdown JDK 1.4.2 Cheers, Jörg Henri Yandell wrote: I screwed up rc1 (release notes bad. So here we are with RC2: http://people.apache.org/~bayard/commons-io/1.3.1-rc2/ The only change is that I've fixed the release notes. [ ] +1 [ ] -1 Hen On 2/8/07, Henri Yandell [EMAIL PROTECTED] wrote: I screwed up the 1.3 release, so here's a 1.3.1 release: http://people.apache.org/~bayard/commons-io/1.3.1-rc1/ The only differences are the following two issues: http://issues.apache.org/jira/browse/IO-112 http://issues.apache.org/jira/browse/IO-113 IO-113 is the reason for the release. We'd like to get 1.3.1 out quickly so the fact that 1.3.1 is not binary compatible with 1.3 will not inconvenience many people. [ ] +1 [ ] -1 Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Release commons-fileupload 1.2 (3rd attempt)
Hi Jochen, I've running the tests from the sources in Gentoo Linux with Maven 1 and the JDKs: - Sun JDK 1.6.0 - Sun JDK 1.5.0 - Blackdown JDK 1.4.2 - IBM JDK 1.5.0 - JRockit JDK 1.5.0 Nevertheless JRockit fails half of the time here with an obscure failure. I also see the IBM JDK with an extreme long duration time (3-4 times longer than Sun) for this test (although it succeeds in the end). The test seems somewhat brittle. = % Testsuite: org.apache.commons.fileupload.ProgressListenerTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 11,019 sec Testcase: testProgressListener(org.apache.commons.fileupload.ProgressListenerTest): FAILED expected:-128 but was:-128 junit.framework.AssertionFailedError: expected:-128 but was:-128 at org.apache.commons.fileupload.ProgressListenerTest.runTest(ProgressListenerTest.java:85) at org.apache.commons.fileupload.ProgressListenerTest.testProgressListener(ProgressListenerTest.java:81) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object [Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) = % - Jörg Jochen Wiedmann wrote: Hi, I have prepared commons-fileupload-1.2rc3. Compared to 1.2rc2, the following changes have been made: - The sources are now available as tar.gz and .zip file. - The build has been made with JDK 1.5.0_11, rather than 1.6.0rc1. Please note, that this release (like all releases) requires, in particular, 3 positive votes from PMC members. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC3)
Hi Hen, Henri Yandell wrote: Here's the 3rd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc3/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Difference from RC2 is that the sources and javadoc jars now have LICENSE/NOTICE files and the test for LANG-312 is commented out as it's still an open bug (and fails on some platforms). The pom.xml is NOT in the src bundle, because I forgot and I don't want to do all that again :) I'll make that change in svn now so it'll be in a future RC if one happens. +1 from me Regarding the POM we should think about it anyway. IMHO we either deliver project.xml for M1 or pom.xml for M2 but not both. Especially since we wanted to switch the groupId with M2 IIRC. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Configuration 1.4 based on RC1
Oliver Heger wrote: The files of the first release candidate for Configuration 1.4, including the site and a Clirr report, are available for inspection at http://people.apache.org/~oheger/commons-configuration-1.4rc1/ [ ] +1 Go ahead and release it [ ] -1 Don't release it because... Vote will close on Saturday night (CET). Oliver +1 Looks good, used the source package to run all tests with M1 on Gentoo Linux for JDKs: - Sun 1.3.1 - Blackdown 1.4.2 - Sun JDK 1.5.0 - Sun JDK 1.6.0 - IBM JDK 1.5.0 - JRockit JDK 1.5.0 Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Dennis, Dennis Lundberg wrote on Wednesday, February 07, 2007 9:39 PM: [snip] I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. Yes, I tried to use this description for a M1 - M2 situation. In the end Carlos' advice was to ignore all the old versions and simply start with the new M2 releases also to use the new groupId and add for those releases only a relocation POM. That is a much easier way to do it. I'm starting to think that this is the way to go for Commons. Just change the groupId when we release with M2 and don't relocate older versions. Yep. If we agree all on this, we can immediately start to use the new groupId. It's just, that the release deploy process will not automatically create those relocation POMs. The problem with adjusting the old releases is, that the location for the relocation POMs is already occupied by the automatically generated POMs for M2 on the global M2 repo (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/ commons-logging/1.1/). And since they're already published, they cannot be changed anymore. I think you are allowed to add a relocation section to an already published pom. I vaguely remember discussing this with Carlos back then. Well, it seems, they become more strict since then. I got definitely a negative answer from him as to replace the old POMs from ibiblio with the ones including the relocation section available on a synchronized site. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] RCs and version numbers
Phil Steitz wrote on Wednesday, February 07, 2007 9:05 PM: [snip] Could be this is the direction that we need to go for the heavily reused components. I cut an RC1 for [dbcp] a couple of weeks ago and published the RC1 snap to the snapshot repo so people could download and test. I was afraid to do what I would have liked to - make it a public RC as we used to do, announcing it on tomcat-user, Jakarta general, etc, but I really think that is the right way to go. Testing RCs is an important part of getting to GA, IMHO and if it offends the gods to put RCs out for general consumption, then I think we need to move to the initial release, GA labelling. I don't like the idea of having people download and test *different* jars with the same names / artifact ids and I don't like releasing components that have not been tested. The problem with the release-then-fix approach is it leads to lots of dot-different release jars out in production use, some of them potentially bugged, and I don't see that as good in a mavenized world or for heavily reused libraries in general. It works OK for top predators like Struts, Tomcat, HTTPd, but could get dicey lower down in the food chain, IMHO. I could be cracked here - pls let me know if I am the only one thinking this way. I'm strongly in favour of 2). It's safer and it makes the release easier. The only negatives are: 1) There's a chance that someone might take a jar from the rc1/ directory in ~bayard and charge off to use it. So be it - that's there risk. 2) I don't like leaving svn in a state of having a release version, so I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the release. An alternative might be to branch 1.4 off for the release and have a 1.4-release branch for preparing the release on, but that a) still makes me uncomfortable to have a release version in and b) will be messy having one of those for every release. If we have to do things this way, I would use a release branch, but I still don't yet see the compelling need to reverse history - i.e., what problem exactly are we needing to solve here? What exactly is illegal about publishing release candidates and having people test them? We publish nightlies now and the RC designation, which is clear and in all of the names, tells users that the artifacts are not yet official releases. I am not trying to be difficult here, just want to understand what the issue is. +1 It should not be a problem to make a final release after a RC has passed the vote. If you don't trust your build tool to (re)create the same artifact now with the final revision number, it seems it is more a question of trusting that build tool ... :D - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 (RC2)
Hi Hen, Henri Yandell wrote: Here's the 2nd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc2/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Saturday if it gets that far. DateFormatUtils.testLang312 still fail for me, now at the last assert: === % Testsuite: org.apache.commons.lang.time.TimeTestSuite Tests run: 62, Failures: 1, Errors: 0, Time elapsed: 11,174 sec - Standard Output --- WARNING: JDK test failed - testLang312() - --- Testcase: testLang312(org.apache.commons.lang.time.DateFormatUtilsTest): FAILED expected:...9... but was:...8... junit.framework.ComparisonFailure: expected:...9... but was:...8... at org.apache.commons.lang.time.DateFormatUtilsTest.testLang31 (DateFormatUtilsTest.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) === % It seems that we cannot format correctly also if the JDK fails. :-/ BTW: What happened with the navigation? http://people.apache.org/~joehni/navi.gif - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Dennis, Dennis Lundberg wrote: Henri Yandell wrote: On 2/5/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. I put together this document when I was trying to pull through the whole groupId change last time: http://maven.apache.org/guides/mini/guide-relocation.html There is never a good time to change the groupId. My view is that we should do it when we move to M2, both as a build tool and as the target repository. Yes, I tried to use this description for a M1 - M2 situation. In the end Carlos' advice was to ignore all the old versions and simply start with the new M2 releases also to use the new groupId and add for those releases only a relocation POM. The problem with adjusting the old releases is, that the location for the relocation POMs is already occupied by the automatically generated POMs for M2 on the global M2 repo (see http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logging/1.1/). And since they're already published, they cannot be changed anymore. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Henri Yandell wrote: On 2/5/07, Jörg Schaible [EMAIL PROTECTED] wrote: [snip] from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. My understanding was that once we started doing m2 builds we would be changing group ids. What I really mean here is deploying to an m2 repository rather than doing m2 builds. So if Jochen's plan is to do an m2 build and send it to the m2 repository, then this point is moot. M2 will publish to the M2 repo. The location is simply defined by the groupId ... whatever it is. We can use commons-xxx as well as org.apache.commons, there's no technical restriction. It is simply our decision. [snip] We've definitely been shifting in the last few Commons releases to building the actual 1.2 release and then voting on it, rather than building releases with -rc2 in the jar name etc. It's just been a tribal change on the lists currently (Craig kicked off a thread about it a few months ago). I know, but it is not yet supported by the current (released) tool chain of Maven. [snip] Please also ensure, that you build from the labeled source code in Subversion. That's the main advantage for me using reelase plugin. By labeled, do you mean the svn tag? Yes. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Initial impressions.
Hi Tom, [EMAIL PROTECTED] wrote on Wednesday, February 07, 2007 1:01 AM: Hi, Henri Yandell schrieb: [snip] Once Lang 2.3 is out, I want to start thinking about 3.0 and suggesting the shocking idea of moving the support up to 1.5+. Although moving forward is good most of the times. Such central components like lang should stay behind the current JVM release as long as possible IMHO because other project who are depended on it might not always upgrade to the latest and greatest JVM-Release immediately. I think it is better for these projects to stay at same JVM for a long time and than make a bigger step as proposed by you here. One more thing people might take into consideration (I don't know if applies here) is that java programs are not always running desktop JVMs but also ones for embedded devices, ... and not all classes are available everywhere! Well, lang-2.3 will not suddenly vanish from earth, even if we start with lang-3.0 ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] Status of components
Hi Hen, Henri Yandell wrote on Wednesday, February 07, 2007 2:07 AM: [snip] Sandbox - Nothing that looks like moving to proper anytime soon. Some for dormancy (finder, id). id is still on my todo list, it's simply a time/prio problem. Nevertheless I answer activly any questions about the component here. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2 (WAS: [VOTE] commons-fileupload 1.2 (rc2))
Hi Jochen, Jochen Wiedmann wrote on Monday, February 05, 2007 9:03 AM: I'm thinking: * Change group id? Couldn't we do that *after* the release, please? I would clearly prefer *not* to introduce any incompatible changes in that stage. +1 from my personal experience with a different project all I can say is that changing the groupId is a task that is not very well supported by M2. The available docs are spare, do not work as they are described or are out of date. So changing the groupId is a task that should be done for a reference project that volunteers to go through all the hassle with a direct helping hand from some Maven folks. * How do we build a 2.0 release and vote on that rather than voting on the release manager's ability to do a release? Is there a way to deploy known files to an m2 repository rather than having to rebuild? I never intended to publish the exact distributables that we voted on. For example, I never intented to change version numbers within the binary distributables from 1.2rc2 to 1.2. How do others do that? This seems currently a process in flux. It seems clear that the standard functionality of M 2.0.4 released plugins does not match the necessary steps for Apache releases. M2 folks have developed and improved some plugins now that support signing and staging, but nothing is released yet. In the mean time you either live with it or you'll process some manual steps. Afar from that, I never intended to use the release manager. To be honest, I never got it working. What's the problem here? I use it all the time (although never for an Apache release yet). I was thinking along the lines of mvn -Drelease clean install site assembly:assembly deploy Which is (apart from the deploy) exactly what I did to build the current files. Please also ensure, that you build from the labeled source code in Subversion. That's the main advantage for me using reelase plugin. If you insist, I can omit the deploy and do the deployment manually. (In other words, omit rebuilding the files.) That said, I spent a lot of time in an automatic build exactly for *not* requiring any manual interventions, because I trust my build system more than myself. * How much of the release code can be shared - I can see stuff in the pom.xml, can that stuff be in the parent pom? Yes, but my clear intention was *not* to wait for a release of commons-parent again (I already did so last year for several months), rather than learning from this release and then move the stuff up later. (Note, that I did all changes in a branch, to allow me for careful integration into either trunk or commons-parent later.) +1 there's always room for improvement and we should rather use a project's POM to introduce new parts to a build then to add all stuff immediately to the parent. If the release went fine and the extension has shown to be useful, we might propagate the improvement to the parent *afterwards*. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Lang 2.3 RC1
Hi Hen, Henri Yandell wrote on Thursday, February 01, 2007 9:33 PM: [snip] Minor: I understand that the proposal is a historical document, but it claims that c-lang is build on top of JDK 1.2 ... that might be confusing. What do people think - update PROPOSALs or delete them? IMHO update is better (maybe with a special remark for the updated parts). What I like in the proposal is that is explains the focus of the library. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Latest 2.0 RC Ready
Rory Winston wrote: Hi Jörg Thanks for the info about the Maven repo - I'm a bit confused with this one however, as when I leave out the snapshot repo that I have defined, it cant find the Maven changes plugin. Possibly I need to define a different repo? I'll need to check. For the release you may not even use the SNAPSHOT parent. Keep in mind, that the release plugin will ensure, that you do not! As far as docs are concerned, [net] has never been too docs-heavy, but they were never really needed - usage is relatively basic. However, it may be a good idea to add a getting started page or such to the docs/site. Yeah. Definitely. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Latest 2.0 RC Ready
Hi Rory, Rory Winston wrote: (Resending as I left out commons-user) Hi all I have cut a new RC, with some changes and fixes, many of which were distribution-related and suggested by Niall earlier (thanks Niall). RC (minus MD5s etc for now) is here: http://people.apache.org/~rwinston/commons-net-2.0/ Some users have been testing out this 2.0 branch for a while, so I'm going to kick off a vote pretty soon. Any comments welcome. Cheers Rory I've checked the src-tar.gz and I can build the package with M2 and all tests using Sun JDK 5 in Linux ... but The POM triggers SNAPSHOT versions of plugins! You cannot release this. The POM should also not define a SNAPSHOT repo at all. Also there is a big lack of docs. Not even a simple introduction. Minor topics: - Javadoc: example packages? - JIRA Report: Missing images Cheers, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 RC1
+1 Rebuild from the src package with Sun JDK 5 under Linux. Minor: I understand that the proposal is a historical document, but it claims that c-lang is build on top of JDK 1.2 ... that might be confusing. - Jörg Henri Yandell wrote: Next up - Lang 2.3. Here's the release candidate: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc1/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Monday if it gets that far. There is an open issue in JIRA currently: http://issues.apache.org/jira/browse/LANG-69 I'm keeping it open for a little bit longer in case anyone has any opinions on my fix to this. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Lang 2.3 RC1
Correction: Tests did *not* run: = % $ ant ... [junit] Tests run: 224, Failures: 0, Errors: 0, Time elapsed: 0,11 sec test.time: [junit] Running org.apache.commons.lang.time.TimeTestSuite [junit] Tests run: 61, Failures: 1, Errors: 0, Time elapsed: 8,094 sec [junit] Test org.apache.commons.lang.time.TimeTestSuite FAILED test: [echo] Running tests ... BUILD SUCCESSFUL = % Building with M1 fails therefore. Test report: = % Testsuite: org.apache.commons.lang.time.TimeTestSuite Tests run: 61, Failures: 1, Errors: 0, Time elapsed: 8,938 sec Testcase: testLang312(org.apache.commons.lang.time.DateFormatUtilsTest): FAILED expected:...9... but was:...8... junit.framework.ComparisonFailure: expected:...9... but was:...8... at org.apache.commons.lang.time.DateFormatUtilsTest.testLang31 (DateFormatUtilsTest.java:230) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) = % It's the part of the fixture that tests the JDK ... maybe this should not be asserted and better be replaced by a simple sysout? In the end you cannot know what was changed/fixed by Sun in which JDK version (and if the assumption is valid for other JDKs) and it does not make sense to rely our tests on such a behavior. - Jörg Jörg Schaible wrote: +1 Rebuild from the src package with Sun JDK 5 under Linux. Minor: I understand that the proposal is a historical document, but it claims that c-lang is build on top of JDK 1.2 ... that might be confusing. - Jörg Henri Yandell wrote: Next up - Lang 2.3. Here's the release candidate: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc1/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Vote to close on Monday if it gets that far. There is an open issue in JIRA currently: http://issues.apache.org/jira/browse/LANG-69 I'm keeping it open for a little bit longer in case anyone has any opinions on my fix to this. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] exceptions and localization
Hi Luc, Luc Maisonobe wrote on Sunday, January 28, 2007 10:06 PM: Stephen Colebourne a écrit : I disagree strongly with the whole concept of localized exception messages. Localization for users yes, but developers no. [snip] IMO, a localized application actually means localization for users, and implies nothing for developers. I agree with both your rationale and your conclusion, but not with the implications. For me, error messages are users oriented, not developers oriented. Here are the few rules experience has teached me in the past 20 years: [snip] If I understand your remark correctly, you do make the same strong difference between users and developers, but you seem to consider exceptions are for the latters. What do you provide to the formers for error messages ? And to what purpose do you use logging ? Although you have also some valid points in your summary, one point I learnt in the last 20 years of programming is, that you cannot build a common library with meaningful exception messages (or log entries) that really makes sense for a user in the context of an application that builds on it. For logging see also http://wiki.apache.org/avalon/AvalonNoLogging (IIRC it was Leo Simon's article). We have some global players as customers and they all have very specific needs for logging and error messages (e.g. every logged entry has to be defined and must have an ID and has fields with fixed length, exceptions have to be reported as part of the return value of service calls again with special identifiers and filled-in parameter values for the error). My bottom line: If you build an application, you have to do localization (of exception and logging) at the application layer, because only there you can give the user a context, that is really useful. This implies catching exceptions from libraries and wrapping them with your own and it implies also, that you should have access to the basic parts of the exception (e.g. the file name) easily i.e. usign the exeption's API. This part can be provided by a common lib (and the JDK fails here often enough badly), but it cannot serve the requirements of an application it has no knowledge of. - Jörg - 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))
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]
Re: [VOTE] IO 1.3 (RC3)
+1 Henri Yandell wrote: I've made a third release candidate of IO 1.3, tagged IO_1_3_RC3. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc3/ Various build files, clirr/jardiff reports and the proposed site. [ ] +1 [ ] -1 Vote to end on Monday (if it makes it that far). The only difference from RC2 are the two build issues Stephen found: 1) MANIFEST contains 1.3 and not 1.2. 2) Javadoc jar for Maven includes LICENSE and NOTICE. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] IO 1.3 (RC2)
Henri Yandell wrote: I've made a second release candidate of IO 1.3, tagged IO_1_3_RC2. Available at: http://people.apache.org/~bayard/commons-io/1.3-rc2/ Various build files, clirr/jardiff reports and the proposed site. [X] +1 [ ] -1 Vote to end on Friday (if it makes it that far). Builds fine from src with Ant and M1 in Linux with JDK 1.5. Site looks good, although the links to the Javadocs on the Overview do not work ... might be a staging problem. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
Hi Phil, Phil Steitz wrote: I have created a release candidate for DBCP 1.2.2. The tarballs/zips are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/ Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/docs/ Clirr report: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/dbcp-1.2.2-RC1-clirr.txt The jar is deployed in the apache snapshot repo: http://people.apache.org/repository/commons-dbcp/jars/commons-dbcp-1.2.2-RC1.jar Thanks in advance for your comments! tried to build from the src package, but the Ant build does not work ... it references ../pool. Shouldn't the src package be self-contained? Building with M1 in Linux using JDK 1.5 works fine though and also the site doc look good. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
Niall Pemberton wrote: On 1/23/07, Jörg Schaible [EMAIL PROTECTED] wrote: [snip] tried to build from the src package, but the Ant build does not work ... it references ../pool. Shouldn't the src package be self-contained? I built OK using ant, but you have to configure the dependencies using a build.properties (theres a build.properties.sample). OK, so +1 then ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote commons-site to proper and release it
+1/+1 :) 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: [io] Inner class exception
Niall Pemberton wrote on Friday, January 12, 2007 1:44 AM:
On 1/12/07, James Carman [EMAIL PROTECTED] wrote:
Sorry, but this doesn't seem like a very good argument to me - on
this basis you could argue against the whole existance of IO - since
it provides stuff thats not in the JDK
I don't know if I agree with this point, Niall. The stuff that's
in IO wasn't left out of the JDK because of coding style, which is
the reason Stephen (I believe that's who said it) is saying we
shouldn't use nested exception classes. I would agree that nested
exception classes should be avoided. I wouldn't want to have to
qualify my exceptions in my catch blocks:
Sorry, the existance of IO comment was a bad attempt at tongue in
cheek humour :-(
catch( DirectoryWalker.CancelException e )
That just looks ugly/weird to me and people just usually don't do
that. I would agree, however, that it does group stuff logically.
OK but CancelException is primarily there to control the processing
flow internally within DirectoryWalker - its a class designed to be
extended and implementations that do extend it don't have to qualify
the exception. When thrown it unwinds from the recursive depths and
causes the handleCancelled() lifecycle method to be called.
So IMO your more likely to see an implementation that does
something like
public class MyWalker extends DirectoryWalker {
protected void handleStart() throws IOException { if
(...) { throw new CancelException(...);
}
}
protected void handleCancelled(...) {
// my cancel processing here
}
}
The default implementation of that method does re-throw it and we have
2 scenrios for this class - cancelling internally by the process
itself or cancelling by an external process. Where users handle
cancellation outside of the implementation then yes they will have to
use the DirectoryWalker.CancelException notation (I personally don't
agree its ugly btw) - but if they don't like it they can easily
re-throw their own.
Niall
[snip]
Looks reasonable for me in this case.
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sandbox] Using commons-skin for all components
Rahul Akolkar wrote on Tuesday, January 09, 2007 4:23 PM: On 1/9/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Rahul, Rahul Akolkar wrote on Monday, January 08, 2007 8:47 PM: snip/ In trunks-sandbox, more specifically: https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbo x/pom.xml IMHO it makes more sense to have an own commons-sandbox-parent trunk (like any other sandbox component). That way you don't have to checkout the complete sandbox and additionally you get the possibility to create a release for the POM ... or is that not supposed to happen for the sandbox parent POM ? snap/ Its possible to just check out the top level svn folder, if you want (svn -N co). I don't mind if its moved around. I favor no releases (might help ensure sandbox deploys don't accidentally end up in a sync'ed/non-snap repo). I know, but you cannot release it from there ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sandbox] Using commons-skin for all components
Dennis Lundberg wrote on Tuesday, January 09, 2007 7:51 PM: [snip] As I said in the first mail in this thread, I would like to move the sandbox parent to be a sibling to the other sandbox components, and thereby have it's own trunk. There are still a couple of more things to do before I feel that we are ready to make that move though. Sorry, I missed this. Big +1 though ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sandbox] Using commons-skin for all components
Hi Dennis, Dennis Lundberg wrote: [snip] - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. I tried to look at this, but where's the commons-sandbox parent pom? % [EMAIL PROTECTED] ~/src/Jakarta/sandbox/id $ mvn test [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.commons ArtifactId: commons-sandbox Version: 1-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.commons:commons-sandbox:pom:1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [snip] % and % [EMAIL PROTECTED] ~/src/Jakarta/sandbox/id $ svn list https://svn.apache.org/repos/asf/jakarta/commons/sandbox commons-skin/ compress/ csv/ exec/ finder/ i18n/ id/ javaflow/ jci/ js2j/ openpgp/ pipeline/ project-template/ proposal/ proxy/ % There's no sandpox-parent project and neither proposal nor project-template seems to contain the parent ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons id package code issue
Hi Pradeep, Pradeep Arumalla wrote: Hi all, I am trying to downloadthe commons id package found at http://jakarta.apache.org/commons/sandbox/id/ , and write java program for generating UUID's , but how do I get the code ? jar , zip ? It takes me to a folders page , I guess I need to download from a repository ? , can some body point me in the right direction. Sorry for sending personal mail, I tried sending it to the groups , but not sure it went through. there has been no release yet, but you may also download from the nightly snapshots: http://people.apache.org/builds/jakarta-commons/nightly/commons-id/ Yes, we're aware, that we need to update the site ... it will happen as soon as the jakarta commons build with M2. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sandbox] Using commons-skin for all components
Hi Rahul, Rahul Akolkar wrote on Monday, January 08, 2007 8:47 PM: On 1/8/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Dennis, Dennis Lundberg wrote: [snip] - Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. I tried to look at this, but where's the commons-sandbox parent pom? snip/ In trunks-sandbox, more specifically: https://svn.apache.org/repos/asf/jakarta/commons/trunks-sandbo x/pom.xml IMHO it makes more sense to have an own commons-sandbox-parent trunk (like any other sandbox component). That way you don't have to checkout the complete sandbox and additionally you get the possibility to create a release for the POM ... or is that not supposed to happen for the sandbox parent POM ? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Add Matt Benson as a Jakarta committer
Henri Yandell wrote on Friday, January 05, 2007 5:40 PM: 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. [X] +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: [sandbox] Using commons-skin for all components
+1 Dennis Lundberg wrote on Thursday, January 04, 2007 10:34 PM: Hi Before I dive head-first into this I thought I'd ask first. I'd like to unify the M2 generated sites for all sandbox components, by making use of commons-skin. This would mean: 1. Make various changes to the sandbox-parent, which is currently located in sandbox-trunk: - Remove local style rules - Remove stuff that is inherited from commons-parent, most notably maven-classic-skin 2. Change pom.xml and site.xml for many sandbox components - Make sure inheritance is correct - Align navigation structure - Remove stuff that is inherited from sandbox-parent 3. Re-publish the sites for all sandbox components - Do mvn site:deploy for all sandbox components - Would like to move sandbox-parent to its own directory in SVN - If we feel that it's necessary at this time: release commons-skin, commons-parent and sandbox-parent Does this sound OK to you? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io] Pre 1.3 build
Henri Yandell wrote on Tuesday, January 02, 2007 10:56 PM: Using: jvm 1.3 ant dist jvm 1.4 maven site I've built the following: http://people.apache.org/~bayard/commons-io/commons-io-snapshot-build/ Anything need fixing up before doing the real build? I'll make the version number 1.3 when I do that etc. The only thing that stands out for me is that a commons-io-1.3-SNAPSHOT-src-ide.zip file is created when we might want it to be named commons-io-1.3-SNAPSHOT-src.jar to match the ones Maven-2 makes. We could also be creating a javadoc jar. M2 creates -sources.jar files :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io] Pre 1.3 build
Stephen Colebourne wrote on Thursday, January 04, 2007 12:13 AM: Jörg Schaible wrote: M2 creates -sources.jar files :) Personally, I like -src-ide.zip, but I can't be bothered to fight the maven god on this. Hehehe. If you like it or not, Maven actually has some potential for unifying builds even if they're not Maven driven ;-) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VFS] contrib, truezip bridge
Hi Filip, Filip Defoort wrote on Thursday, January 04, 2007 3:00 AM: Hi Mario, I'm not sure if you're familiar with Truezip (https://truezip.dev.java.net), but it's a library that allows for read + write access to zip/gz/tar/bz2 and other types of archives. I've implemented a quicky VFS provider for it, and it seems to work (took all of a whopping 20 minutes :-) ). I'm wondering if VFS is interested in this code - I'd be happy to contribute it. (it's just three classes and largely copied from the local filesystem implementation). Let me know if you're interested and how you'd like to proceed. Truezip is under ASF license; and has been released (v 6.4 currently), so I doubt that we'll run into problems for releasing this. Sounds great. But best thing is to provide the stuff with a JIRA issue. That way it cannot get lost in the mail archives and the active devs can have a look at their own time. Nevertheless, thanks for your efforts! - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Using Maven 2 for everything
Hi Dennis, Dennis Lundberg wrote: [snip] 4. The M2 jars has the files pom.properties and pom.xml in the /META_INF/maven/commons-logging/commons-logging/ directory. This can be configured, but the plugin needs an up-to-date archiver component. I know that e.g. the war plugin uses such a new one, but I don't know by heart for the jar plugin. Nevertheless, this can go away in mid-term. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Phil Steitz wrote: Hmmm. http://people.apache.org/~dennisl/commons-lang3/http://people.apache.org/%7Edennisl/commons-lang3/ puts the nav bar in the right place flush left, but shows a big black box between the Jakarta and Lang logos on the top. Same for me with Firefox 1.5.0.9, Konqueror 3.5.5 and Opera 9.02 http://people.apache.org/~dennisl/commons-lang4/http://people.apache.org/%7Edennisl/commons-lang4/ puts the nav bar in the middle, as before. Just with Konqueror, looks right with Firefox and Opera. But with Konqueror it is really unusable. So - despite the black box - #3 is better. - Jörg, Genooist :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Introducing commons-skin
Dennis Lundberg wrote: Dennis Lundberg wrote: Phil Steitz wrote: snip http://people.apache.org/~dennisl/commons-lang4/http://people.apache.org/%7Edennisl/commons-lang4/ puts the nav bar in the middle, as before. That's odd. There must be something more that is wrong then. Unfortunately I haven't been able to reproduce this myself. I looked around to find a linux live-cd with Firefox 2 on it. I found one and burned a copy of Ubuntu 6.10 with Firefox 2.0.0.0. But I can't see the issues that you do. I can however see it on both Ubuntu and Windows if make the font size smaller (!) in firefox (CTRL -) about 6 times, then the navbar pops away to the right a bit. I'll continue searching for a solution. OK, I think I've got it this time. As it turned out I had put in my stylesheet rules in a different place than they should be, so I ended up having contradicting rules for the same selector. The conflicts have been solved and the rules have been moved to the appropriate section in the css file. This solves the all the problems I have seen. I have tested this with: - Firefox 2.0.0.1 on Windows - Internet Explorer 6 on Windows - Firefox 2.0.0.0 on Ubuntu - Konqueror 3.5.2 on Kubuntu Here's yet another staged site for commons-lang. Please help me and try it out on the platforms that had problems before. http://people.apache.org/~dennisl/commons-lang5/ Looks perfect :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-parent] Make deployment URL pluggable
Jochen Wiedmann wrote: On 12/29/06, Dennis Lundberg [EMAIL PROTECTED] wrote: If you have the need to deploy somewhere else you can easily add another profile, temporarily, in the component you are working on. Ok, my impression is that we all agree on the pluggable protocol, so I have committed that, and only that. Looks good. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Transaction 1.2
Hi Oliver, Oliver Zeigermann wrote: We have worked our way through three release candidates now and the latest has been out there for quite some time without substantial shortcomings reported: http://people.apache.org/~ozeigermann/tx-1.2rc3/ Do you also have a link for the 1.2 site ? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] id failed.
Henri Yandell wrote: Looks like this is just a non-determinant test: Testcase: testCanRetrieveTimeFromIdWithInternalOverflow(org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest): FAILED expected:1167047841826 but was:1167047841827 junit.framework.AssertionFailedError: expected:1167047841826 but was:1167047841827 It is, but it is affected by an environment that does time-shifts. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Luc Maisonobe as Jakarta Commons committer
+1 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]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC10
Hi Mario, Mario Ivankovits wrote: [snip] Although some tests are expected to fail, I have also a failure in the VirtualProviderTestCase that makes me wonder: /snip - --- Testcase: testSetLastModified(org.apache.commons.vfs.test.LastModifiedTests):FAILED expected:1.16656636E12 but was:1.16656623E12 junit.framework.AssertionFailedError: expected:1.16656636E12 but was:1.16656623E12 This makes me wonder too, which filesystem do you use for the test partition? I've tried it on two different machines both running linux with ext3 and it worked. I run the Maven 1 build 5 times again and the test never failed ?!? So we might keep a mental node, that the test may fail under some obscure circumstances, but passes normally ... :-/ This makes in the end +1 for the release. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC10
Hi Mario, first a question to all: Is it consensus that we use groupId commons-vfs? I just wondered that it was taken for the first release, since we'll switch to org.apache.commons ... But since we have to switch/relocate a lot of projects, one more does not really matter :) 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! running the tests on Linux with JDK 5/Maven. The Ant build chokes for all get-dep goals e.g.: == % == get-custom-dep-commons-net.jar: get-dep-commons-net.jar: [get] Getting: http://www.ibiblio.org/maven/commons-net/jars/commons-net-1.4.1.jar [get] To: /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar [get] Getting: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] To: /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar [get] Error opening connection java.io.FileNotFoundException: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] Error opening connection java.io.FileNotFoundException: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] Error opening connection java.io.FileNotFoundException: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] Can't get http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar to /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar == % == Shouldn't this goal now try to download from mirrors.ibiblio.org ? The fun part is, that all those deps are in my Maven 1 repo and the compilation went fine afterwards ;-) Although some tests are expected to fail, I have also a failure in the VirtualProviderTestCase that makes me wonder: == % == Testsuite: org.apache.commons.vfs.provider.test.VirtualProviderTestCase Tests run: 58, Failures: 1, Errors: 0, Time elapsed: 5,25 sec - Standard Output --- skipping testAbsoluteURI because fs does not have cap URI skipping testRandomRead because fs does not have cap RANDOM_ACCESS_READ skipping testRandomWrite because fs does not have cap RANDOM_ACCESS_READ skipping testRenameFile because fs does not have cap RENAME skipping testURL because fs does not have cap URI skipping testURLContent because fs does not have cap URI skipping testUnknownURL because fs does not have cap URI skipping testFolderURL because fs does not have cap URI skipping testLoadClass because fs does not have cap URI skipping testLoadResource because fs does not have cap URI skipping testSealing because fs does not have cap URI created threads still running: #1: main org.apache.commons.vfs.cache.SoftRefFilesCache$SoftRefReleaseThread daemon null - --- - Standard Error - 19.12.2006 23:11:33 org.apache.commons.vfs.VfsLog info INFO: Using /home/joehni/java/commons-vfs-1.0-src/target/test-classes/test-data/temp as temporary files store. . . . . - --- Testcase: testSetLastModified(org.apache.commons.vfs.test.LastModifiedTests):FAILED expected:1.16656636E12 but was:1.16656623E12 junit.framework.AssertionFailedError: expected:1.16656636E12 but was:1.16656623E12 at org.apache.commons.vfs.test.LastModifiedTests.testSetLastModified(LastModifiedTests.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.commons.vfs.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:197) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) == % == Is this expected for some fs ? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Are we ready for 1.1.1?
Hi Simon, [EMAIL PROTECTED] wrote on Tuesday, December 19, 2006 10:27 PM: Craig McClanahan [EMAIL PROTECTED] wrote: On 12/19/06, Dennis Lundberg [EMAIL PROTECTED] wrote: I've looked through the list of unscheduled issues [1] and can't find anything that need to go into a 1.1.1 release. I'm not aware of any fetaures or bugfixes waiting. How are we going to create the release? 1. Ant 2. Maven 1 3. Maven 2 Or some combination of them? My guess is to use Ant for the source/binaries distros and Maven 1 for the site. My preference would be to build using maven2, with -source and -target set to 1.2 and 1.1 respectively (using a JVM = 1.4 of course, as that's what maven needs). To check 1.2 compatibility, we could then run just the integration tests as a separate step using java 1.2. However this would require that: (a) mvn site works. Currently this generates odd errors I don't understand You might still use M1 to generatge the site though. Just configure the release plugin of M2 to run only deploy instead of deploy, site-deploy as long as site generation does not work with M2. (b) there is an obvious way of setting -source and -target values, so they default to 1.2/1.1 but users can override. I'm sure there is, but I don't know what it is. (c) the itest target supports running tests using an external JVM Using a single build tool to produce a release is much easier than using ant to build the code and maven1 to build the site, then stitching the results together. Well, since M2 is not yet up to date with M1 building the site, catch 22 ;-) My understanding is that Maven 1 for the site is required to get the current Commons LF. I don't have an opinion on which is the best to actually make the binaries of the release. As noted above, it would be great if we could get the site building using maven2. Yeah. Definitely. Is there anything else that needs to be done, besides the normal release cycle? I think we're set. I'd like to see a reasonable time for users to assess a release candidate. Getting the nightlies working would be a good first step; currently nightlies for logging uses maven1.x, which means that ONLY the site is actually being built nightly.. A working nightly M2 build would be really great. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][VFS] release commons-vfs 1.0 based on RC10
Mario Ivankovits wrote on Wednesday, December 20, 2006 7:59 AM: Hi Jörg! first a question to all: Is it consensus that we use groupId commons-vfs? I just wondered that it was taken for the first release, since we'll switch to org.apache.commons ... It's already changed for the m2 build. I don't know if its worth to relocate the m1. It's just that the M1 and M2 repos are kind of mirrored. Using the groupId in one repo means automatically the same for the M2 repo. But again, this is no stopper for the current release, we have plenty of component to relocate after the switch :) But since we have to switch/relocate a lot of projects, one more does not really matter :) ok. The ant build file is autogenerated using maven ... get-dep-commons-net.jar: [get] Getting: http://www.ibiblio.org/maven/commons-net/jars/commons-net-1.4.1.jar [get] To: /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar [get] Getting: This get succeeded!! Unhappily the ant build do not stop now but tries the other possible repositories too. Sorry, I should have looked better myself ... [snip] Shouldn't this goal now try to download from mirrors.ibiblio.org ? The fun part is, that all those deps are in my Maven 1 repo and the compilation went fine afterwards ;-) Hehe, yea, the ant build downloaded them fine. Although some tests are expected to fail, I have also a failure in the VirtualProviderTestCase that makes me wonder: /snip - --- Testcase: testSetLastModified(org.apache.commons.vfs.test.LastModifiedTe sts):FAILED expected:1.16656636E12 but was:1.16656623E12 junit.framework.AssertionFailedError: expected:1.16656636E12 but was:1.16656623E12 This makes me wonder too, which filesystem do you use for the test partition? I've tried it on two different machines both running linux with ext3 and it worked. My Gentoo Linux is running on XFS, tests done with JDK 1.5.0.10. I will have a closer look at the test this evening. Which JDK did you try? At least in current Win releases of JDK 5 Sun did some changes in the native FS code of the VM (longer paths than 260 chars g), other changes might have happened for other native FS support code too. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons SCXML 0.6
+1 RELEASE-NOTES.txt talks of JEXL 1.1 and JCL 1.1 though, dependency report reveils usage of JEXL 1.0 and JCL 1.0.4. Builds with Ant fine from source on JDK 5/Linux. - Jörg Rahul Akolkar wrote: Having made a couple of (IMO, minor) changes, I've cut RC2. Towards that as 0.6: http://people.apache.org/~rahul/commons/scxml-0.6/rc2/ [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Vote closes no sooner than Saturday, Dec 16th. TIA for your time, -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT][VOTE] Release Commons JEXL 1.1
Niall Pemberton wrote on Tuesday, December 12, 2006 9:35 AM: JEXL 1.1 doesn't appear to have been added to the m2 rsync directory: http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-jexl/jars/ It's available in the M1 M2 central repo though: http://repo1.maven.org/maven2/commons-jexl/commons-jexl/1.1/ http://repo1.maven.org/maven/commons-jexl/jars/ Note, that you should never publish artifacts to a synched M1 and M2 repo, since this replication is done on the central repo side. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT][VOTE] Release Commons JEXL 1.1
Niall Pemberton wrote on Tuesday, December 12, 2006 12:58 PM: On 12/12/06, Jörg Schaible [EMAIL PROTECTED] wrote: Niall Pemberton wrote on Tuesday, December 12, 2006 9:35 AM: JEXL 1.1 doesn't appear to have been added to the m2 rsync directory: http://people.apache.org/repo/m1-ibiblio-rsync-repository/comm ons-jexl/jars/ It's available in the M1 M2 central repo though: http://repo1.maven.org/maven2/commons-jexl/commons-jexl/1.1/ http://repo1.maven.org/maven/commons-jexl/jars/ OK thanks - so I guess its the same m1 not redirecting issue then and pointing to the above would have sorted it. Note, that you should never publish artifacts to a synched M1 and M2 repo, since this replication is done on the central repo side. I'm not quite sure what you mean by the above. We publish jars/poms to the m1 rsync directory: http://people.apache.org/repo/m1-ibiblio-rsync-repository Everything else gets taken care of automatically right? (i.e. http://repo1.maven.org and ibiblio) Yep. shrugI made once the mistake and put the artifacts of a release in a synched M1 and M2 repo - with the result, that you can get different artifacts depending on which repo you're refering/shrug. Therefore I just want to assure, that nobody tries to deploy the artifacts a second time ... since apache has a M2 repo also at http://people.apache.org/repo/m2-ibiblio-rsync-repository. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Betwixt 0.8
jar builds fine from source, all tests pass with JDK 1.5/Linux +1 - Jörg robert burrell donkin wrote: we've been through 4 release candidate for commons betwixt but the consensus now seems to be that the candidate is now good enough. release candidate 4 is available @ http://people.apache.org/~rdonkin/commons-betwixt/ and the site @ http://people.apache.org/~rdonkin/commons-betwixt/site/ here's my +1 - robert --8 [ ] +1 Release Commons Betwixt 0.8 [ ] +0 [ ] -0 [ ] -1 Do not release Commons Betwixt 0.8 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
