svn commit: r441916 - /jakarta/commons/proper/io/trunk/pom.xml
Author: bayard Date: Sat Sep 9 23:01:04 2006 New Revision: 441916 URL: http://svn.apache.org/viewvc?view=revrev=441916 Log: Maven-2 pom for IO so I can mvn install the snapshot locally into my .m2 and use it with finder Added: jakarta/commons/proper/io/trunk/pom.xml Added: jakarta/commons/proper/io/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/pom.xml?view=autorev=441916 == --- jakarta/commons/proper/io/trunk/pom.xml (added) +++ jakarta/commons/proper/io/trunk/pom.xml Sat Sep 9 23:01:04 2006 @@ -0,0 +1,260 @@ +?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; + parent +groupIdorg.apache.commons/groupId +artifactIdcommons/artifactId +version1-SNAPSHOT/version + /parent + modelVersion4.0.0/modelVersion + groupIdorg.apache.commons/groupId + artifactIdcommons-io/artifactId + version1.3-SNAPSHOT/version + nameIO/name + + inceptionYear2002/inceptionYear + description +Commons-IO contains utility classes, stream implementations, file filters, and endian classes. + /description + + urlhttp://jakarta.apache.org/commons/io//url + + organization +nameThe Apache Software Foundation/name +urlhttp://jakarta.apache.org/url + /organization + + licenses +license + nameThe Apache Software License, Version 2.0/name + url/LICENSE.txt/url + distributionrepo/distribution +/license + /licenses + + issueManagement +systemjira/system +urlhttp://issues.apache.org/jira/browse/IO/url + /issueManagement + + scm + connectionscm:svn:scm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/io/trunk/connection + developerConnectionscm:svn:scm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/io/trunk/developerConnection +urlhttp://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/url + /scm + + mailingLists +mailingList + nameCommons Dev List/name + subscribe[EMAIL PROTECTED]/subscribe + unsubscribe[EMAIL PROTECTED]/unsubscribe + archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-dev//archive +/mailingList +mailingList + nameCommons User List/name + subscribe[EMAIL PROTECTED]/subscribe + unsubscribe[EMAIL PROTECTED]/unsubscribe + archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-user//archive +/mailingList + /mailingLists + + developers +developer + nameScott Sanders/name + idsanders/id + email[EMAIL PROTECTED]/email + organization/organization + roles +roleJava Developer/role + /roles +/developer +developer + namedIon Gillard/name + iddion/id + email[EMAIL PROTECTED]/email + organization/organization + roles +roleJava Developer/role + /roles +/developer +developer + nameNicola Ken Barozzi/name + idnicolaken/id + email[EMAIL PROTECTED]/email + organization/organization + roles +roleJava Developer/role + /roles +/developer +developer + nameHenri Yandell/name + idbayard/id + email[EMAIL PROTECTED]/email + organization/organization + roles +roleJava Developer/role + /roles +/developer +developer + nameStephen Colebourne/name + idscolebourne/id + organization/organization + roles +roleJava Developer/role + /roles + timezone0/timezone +/developer +developer + nameJeremias Maerki/name + idjeremias/id + email[EMAIL PROTECTED]/email + organization/ + roles +roleJava Developer/role + /roles + timezone+1/timezone +/developer +developer + nameMatthew Hawthorne/name + idmatth/id + email[EMAIL PROTECTED]/email + organization/ + roles +roleJava Developer/role + /roles +/developer +developer + nameMartin Cooper/name + idmartinc/id
svn commit: r441918 - /jakarta/commons/proper/cli/trunk/pom.xml
Author: bayard Date: Sat Sep 9 23:13:41 2006 New Revision: 441918 URL: http://svn.apache.org/viewvc?view=revrev=441918 Log: Finder is also going to want to use CLI, so creating an m2 pom for it as well Added: jakarta/commons/proper/cli/trunk/pom.xml Added: jakarta/commons/proper/cli/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/pom.xml?view=autorev=441918 == --- jakarta/commons/proper/cli/trunk/pom.xml (added) +++ jakarta/commons/proper/cli/trunk/pom.xml Sat Sep 9 23:13:41 2006 @@ -0,0 +1,175 @@ +?xml version=1.0 encoding=UTF-8? +!-- + 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; + parent +groupIdorg.apache.commons/groupId +artifactIdcommons/artifactId +version1-SNAPSHOT/version + /parent + modelVersion4.0.0/modelVersion + groupIdorg.apache.commons/groupId + artifactIdcommons-cli/artifactId + version2.0-SNAPSHOT/version + nameCLI/name + + inceptionYear2002/inceptionYear + description +Commons CLI provides a simple API for presenting, processing and +validating a command line interface. + /description + + urlhttp://jakarta.apache.org/commons/cli//url + + organization +nameApache Software Foundation/name +urlhttp://www.apache.org/url + /organization + + licenses +license + nameThe Apache Software License, Version 2.0/name + url/LICENSE.txt/url + distributionrepo/distribution +/license + /licenses + + issueManagement +systemjira/system +urlhttp://issues.apache.org/jira/browse/CLI/url + /issueManagement + + scm + connectionscm:svn:scm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/trunk/connection + developerConnectionscm:svn:scm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/trunk/developerConnection +urlhttp://svn.apache.org/viewvc/jakarta/commons/proper/cli/trunk/url + /scm + + developers +developer + nameJames Strachan/name + idjstrachan/id + email[EMAIL PROTECTED]/email + organizationSpiritSoft, Inc./organization +/developer +developer + nameBob McWhirter/name + idbob/id + email[EMAIL PROTECTED]/email + organizationWerken/organization + roles +rolecontributed ideas and code from werken.opt/role + /roles +/developer +developer + nameJohn Keyes/name + idjkeyes/id + email[EMAIL PROTECTED]/email + organizationintegral Source/organization + roles +rolecontributed ideas and code from Optz/role + /roles +/developer +developer + nameRob Oxspring/name + idroxspring/id + email[EMAIL PROTECTED]/email + organizationIndigo Stone/organization + roles +roledesigned CLI2/role + /roles +/developer + /developers + + contributors +contributor + namePeter Donald/name + roles +rolecontributed ideas and code from Avalon Excalibur's cli package/role + /roles +/contributor +contributor + nameBerin Loritsch/name + email[EMAIL PROTECTED]/email + roles +rolehelped in the Avalon CLI merge/role + /roles +/contributor +contributor + namePeter Maddocks/name + email[EMAIL PROTECTED]/email + organizationHewlett-Packard/organization + roles +rolesupplied patch/role + /roles +/contributor + /contributors + + dependencies + +!-- used in PatternOptionBuilder -- +dependency + groupIdcommons-lang/groupId + artifactIdcommons-lang/artifactId + version2.1/version +/dependency + +!-- used for unit tests -- +dependency + groupIdjunit/groupId + artifactIdjunit/artifactId + version3.8.1/version + scopetest/scope +/dependency + +!-- used for unit tests -- +dependency + groupIdjdepend/groupId + artifactIdjdepend/artifactId + version2.5/version + scopetest/scope +/dependency + + /dependencies +
[cli][configuration][convert] Architecting our overlaps
So I'm using [cli] in [finder] to see if I can mimic the command line
interface for the unix find command. I'm using the cli2 version - lots
of thought, but very painful to use. Here are the 30 lines of code to
add a single option:
code
public static void main(String[] args) throws OptionException {
DefaultOptionBuilder obuilder = new DefaultOptionBuilder();
ArgumentBuilder abuilder = new ArgumentBuilder();
GroupBuilder gbuilder = new GroupBuilder();
Option type =
obuilder
.withShortName(type)
.withDescription(True if the file is of the specified type.)
.withArgument(
abuilder
.withName(type-flag)
.withMinimum(1)
.withMaximum(1)
.create()
)
.create();
Group options =
gbuilder
.withName(options)
.withOption(type)
.create();
Parser parser = new Parser();
parser.setGroup(options);
CommandLine cl = parser.parse(args);
if(cl.hasOption(type)) {
System.out.println(USE TYPE: + cl.getValue(type));
}
}
/code
Obviously a second flag wouldn't double it or anything, but it's still
a lot. So my first thought is wondering how the API can be simpler for
simple cases. Power is good, power when it's not needed is
unmanageable.
Perusing the CLI2 javadoc, my second thought is that it overlaps with
Configuration a lot. You can have Properties and Preferences command
lines; and Configuration lacks a CLI style way to input data.
A third thought is that the CLI2 CommandLine API for the data itself
rests on a getValue(Option);Object method, which implies some
conversion is going on but I've not seen how yet by looking at the
API. Configuration also does conversion of String to various objects.
BeanUtils does that too, which gave rise to an overmodelled [convert]
package that we've talked about restarting as something simpler.
--
Any of that kick off any thoughts?
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441922 - in /jakarta/commons/sandbox/finder/trunk: pom.xml src/java/org/apache/commons/finder/Find.java
Author: bayard
Date: Sun Sep 10 00:40:29 2006
New Revision: 441922
URL: http://svn.apache.org/viewvc?view=revrev=441922
Log:
Adding dependency on commons-cli for the purpose of a command line find
implementation, and a Find class to put said implementation in, though it
barely has anything in it to start with.
Added:
jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Find.java
Modified:
jakarta/commons/sandbox/finder/trunk/pom.xml
Modified: jakarta/commons/sandbox/finder/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/pom.xml?view=diffrev=441922r1=441921r2=441922
==
--- jakarta/commons/sandbox/finder/trunk/pom.xml (original)
+++ jakarta/commons/sandbox/finder/trunk/pom.xml Sun Sep 10 00:40:29 2006
@@ -14,9 +14,14 @@
dependencies
dependency
- groupIdcommons-io/groupId
+ groupIdorg.apache.commons/groupId
artifactIdcommons-io/artifactId
- versionSNAPSHOT/version
+ version1.3-SNAPSHOT/version
+/dependency
+dependency
+ groupIdorg.apache.commons/groupId
+ artifactIdcommons-cli/artifactId
+ version2.0-SNAPSHOT/version
/dependency
dependency
groupIdjunit/groupId
Added:
jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Find.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Find.java?view=autorev=441922
==
---
jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Find.java
(added)
+++
jakarta/commons/sandbox/finder/trunk/src/java/org/apache/commons/finder/Find.java
Sun Sep 10 00:40:29 2006
@@ -0,0 +1,58 @@
+/*
+ * 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.
+ */
+package org.apache.commons.finder;
+
+import org.apache.commons.cli2.*;
+import org.apache.commons.cli2.builder.*;
+import org.apache.commons.cli2.commandline.Parser;
+
+public class Find {
+
+public static void main(String[] args) throws OptionException {
+DefaultOptionBuilder obuilder = new DefaultOptionBuilder();
+ArgumentBuilder abuilder = new ArgumentBuilder();
+GroupBuilder gbuilder = new GroupBuilder();
+
+Option type =
+obuilder
+.withShortName(type)
+.withDescription(True if the file is of the specified type.)
+.withArgument(
+abuilder
+.withName(type-flag)
+.withMinimum(1)
+.withMaximum(1)
+.create()
+)
+.create();
+
+Group options =
+gbuilder
+.withName(options)
+.withOption(type)
+.create();
+
+Parser parser = new Parser();
+parser.setGroup(options);
+CommandLine cl = parser.parse(args);
+
+if(cl.hasOption(type)) {
+System.out.println(USE TYPE: + cl.getValue(type));
+}
+}
+
+}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441924 - /jakarta/commons/proper/lang/trunk/xdocs/userguide.xml
Author: bayard Date: Sun Sep 10 00:55:54 2006 New Revision: 441924 URL: http://svn.apache.org/viewvc?view=revrev=441924 Log: Update the text section - though not with much of value. Need to talk about the classes here. Modified: jakarta/commons/proper/lang/trunk/xdocs/userguide.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/userguide.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/userguide.xml?view=diffrev=441924r1=441923r2=441924 == --- jakarta/commons/proper/lang/trunk/xdocs/userguide.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/userguide.xml Sun Sep 10 00:55:54 2006 @@ -223,9 +223,14 @@ section name=lang.text.* !-- - Interpolation - MappedMessageFormat + CompositeFormat + StrLookup + StrSubstitutor + StrBuilder + StrMatcher + StrTokenizer -- + pThe text package was added in Lang 2.2. /p /section section name=Next version of Lang - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441925 - /jakarta/commons/proper/lang/trunk/xdocs/userguide.xml
Author: bayard Date: Sun Sep 10 00:56:35 2006 New Revision: 441925 URL: http://svn.apache.org/viewvc?view=revrev=441925 Log: Killing the 'next version' part of the user guide. It's the wrong place for that kind of information I think Modified: jakarta/commons/proper/lang/trunk/xdocs/userguide.xml Modified: jakarta/commons/proper/lang/trunk/xdocs/userguide.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/xdocs/userguide.xml?view=diffrev=441925r1=441924r2=441925 == --- jakarta/commons/proper/lang/trunk/xdocs/userguide.xml (original) +++ jakarta/commons/proper/lang/trunk/xdocs/userguide.xml Sun Sep 10 00:56:35 2006 @@ -233,9 +233,5 @@ pThe text package was added in Lang 2.2. /p /section - section name=Next version of Lang -pThe next version of Lang is a work in progress. /p - /section - /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441929 - in /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang: enum/ValuedEnum.java enums/ValuedEnum.java
Author: bayard
Date: Sun Sep 10 01:04:17 2006
New Revision: 441929
URL: http://svn.apache.org/viewvc?view=revrev=441929
Log:
Fixed javadoc typo as mentioned in #LANG-258
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java?view=diffrev=441929r1=441928r2=441929
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enum/ValuedEnum.java
Sun Sep 10 01:04:17 2006
@@ -73,7 +73,7 @@
* pThe above class could then be used as follows:/p
*
* pre
- * public void doSomething(JavaVersion ver) {
+ * public void doSomething(JavaVersionEnum ver) {
* switch (ver.getValue()) {
* case JAVA1_0_VALUE:
* // ...
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java?view=diffrev=441929r1=441928r2=441929
==
---
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
(original)
+++
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/enums/ValuedEnum.java
Sun Sep 10 01:04:17 2006
@@ -78,7 +78,7 @@
* pThe above class could then be used as follows:/p
*
* pre
- * public void doSomething(JavaVersion ver) {
+ * public void doSomething(JavaVersionEnum ver) {
* switch (ver.getValue()) {
* case JAVA1_0_VALUE:
* // ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-258) Enum JavaDoc: 1) outline 5.0 native Enum migration 2) warn not to use the switch() , 3) point out approaches for persistence and gui
[ http://issues.apache.org/jira/browse/LANG-258?page=comments#action_12433677 ] Henri Yandell commented on LANG-258: Fixed the doSomething javado typo in r441929. Will go with 2.2. Enum JavaDoc: 1) outline 5.0 native Enum migration 2) warn not to use the switch() , 3) point out approaches for persistence and gui Key: LANG-258 URL: http://issues.apache.org/jira/browse/LANG-258 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.1 Environment: all Reporter: Ralf Hauser Fix For: 2.3 http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enums/Enum.html is great! Now that Jdk5.0 has its own approach for type-safe enums, would it be great to provide a few sentences - whether they simply should co-habit? - how one would best migrate? - where the concepts are different Also, it would be great to provide some hints how to work on the with a MVC/GUI framework - see SB-20. also, http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enums/ValuedEnum.html has a minor typo it says doSomething(JavaVersion, but should say doSomething(JavaVersionEnum also, it should contain a big warning that by using switch(), one opens up for type-unsafety! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] LANG-262
Any thoughts on this issue? https://issues.apache.org/jira/browse/LANG-262 Says that the cEnumClasses Hashmap in the Enum class is keeping a ClassLoader from being garbage collected and that switching it to a WeakHashMap should fix it. Seems fair to me, and an easy fix for 2.2; but not something I can think of simple ways to unit test. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r441940 - /jakarta/commons/proper/httpclient/trunk/release_notes.txt
Author: olegk Date: Sun Sep 10 04:14:12 2006 New Revision: 441940 URL: http://svn.apache.org/viewvc?view=revrev=441940 Log: HTTPCLIENT-597 Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/release_notes.txt?view=diffrev=441940r1=441939r2=441940 == --- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original) +++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Sun Sep 10 04:14:12 2006 @@ -1,6 +1,10 @@ --- Changes since Release 3.1 Alpha 1: +* [HTTPCLIENT-597] - Improved handling of idle connections in the multithreaded HTTP connection + manager. + Contributed by Michael Becke mbecke at apache.org + * [HTTPCLIENT-593] - Fixed problem with #equals() and #hashCode() methods in subclasses of DefaultProtocolSocketFactory and SSLProtocolSocketFactory Contributed by Chris Audley chrisaudley at yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Hey guys An interesting discussion here. I'll try to address some of the points raised and give my take on the issue. * As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. See http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 for a few. * As far as I am concerned, the ideal scenario for a project like [net] is that 1.5+ support continues on a different version line. It may be the trunk, it may be a branch. So for [net], the 1.x line is for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean that support is suddenly dropped for pre-Tiger releases. But sooner or later, 2.0 is the main development version, and that's where the effort should go. * I don't like the concept of a .net5 package name. Does this mean that we need a .net6 package space when JDK 6 is released? It doesn't feel elegant, and it loses one of the big advantages that the current system has : a user can upgrade their JDK from 1.3 to 5.0 overnight, download a new [net] 2.0 jar, and their FTPClient-based code should *just work* (with a 90% probability ;)). * I agree with Henri's comment below about Commons being a maintenance vs. development space. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. Cheers Rory Henri Yandell wrote: On 9/9/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Steve Cohen wrote: I am not ready to vote yet on this until there is a discussion about what this release means. Will commons-net-2.0 become the official release, with previous versions relegated to backward compatibility support? If so, this may be premature as Sun is still supporting JDK-1.4.2-x. But I don't think we should stand in the way of progress either. Rory, can you comment on what are the specific new features that demand JDK 5.0 support? How have other jakarta-commons projects handled this? Are there any official versions that require 1.5? Are there projects that have two official releases? I see this as a positive step (a JDK 1.5 only release). I also see this as the right jump (from JDK 1.2/1.3 to 1.5). I'm a strong +1 for JDK 1.5 dependence. The way I see it is that while we're supporting 1.2-1.4, new development happens on 1.5 so the only time we need to worry about older JVMs is for critical bugfixes on maintenance systems - not for new development. Trying to focus on old JVMs makes us a maintenance project, not a development project and that's damaging for the project health. Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I need to dig into Ubuntu to try and get it to work there and I can't even figure out how to get it to work on Windows at the moment (JDK 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not defined in the user's environment variables). Another reason is that Lang has tests that fail to pass on 1.2 and 1.3; possibly due to bugs in the JVM (time crap). Even once I can make a 1.2/1.3 build, I'm not sure if I should. Plus other reasons, such as being without a happy laptop at home until tonight :) However, I believe that commons holds an almost unique place in Java development being the lowest layer in many many open source projects. As such making an incompatible major version change is a *very* big deal. [PROPOSAL] As such, I would like to propose that projects creating a JDK1.5 only release should use a new package name. Thus, in this case, the release would use the package org.apache.commons.net5.*. -1 for a slew of reasons. * Lots of source code would have to be touched just to upgrade; big pain in the arse for something that is quite likely to not involve any other change to a user's source. * Building v49 class files is going to explode on a v48 JVM, so people are going to be stopped pretty quickly from using the net5 on their old JVM. We don't need to protect them via packages. * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6? With this change, a user can have both the old and the new commons-net jars in their classpath without any conflicts. Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted builds and not 1.2-1.4. And then it's nothing to do with 1.4/1.5 and just the classic problem of package clash
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-10092006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-10092006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-10092006.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-10092006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-10092006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-10092006.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:63) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:58) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:112) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:160) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:102) [junit] at org.dom4j.rule.Stylesheet.run(Stylesheet.java:91) [junit] at
[nightly build] finder failed.
Failed build logs: http://people.apache.org/~psteitz/commons-nightlies/20060910/finder.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Continuing the discussion: 1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3 compatible that we couldn't use it. That's a small point. I doubt we want to have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for all these years, if our soon-to-be target is 1.5. I do agree that the oro dependency has been a very annoying pebble in the shoe. 2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down that road. I guess SVN can handle that but it's still ugly. It makes upgrade for clients of net a maintenance nightmare. 3. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. No, there unfortunately does need to be this debate. Sun has not end-of-lifed 1.4.2. That is important. They continue to release new subreleases of 1.4.2. Why? Important clients are still not ready to use 5.0. My employer, a very large corporation, now mandates the use of 5.0 but is forced immediately to relent on this mandate for some of its most important projects because it also still uses a lot of Websphere which still does not support 5.0 (and won't until WebSphere 7 is released and even then it will be some time before the server teams are ready to make that switch - they dragged their feet on Websphere 6 until recently). So Sun has to support 1.4 (and continues to have to make new subreleases of 1.4.2 for reasons such as the new daylight savings time start/end dates). The world marches on even when corporate java clients do not. Backward compatibility's a bitch, but if Sun has to worry about this, I think we do too. I don't think jakarta-commons has ever downgraded a version of java that Sun considers live. And yet, as Rory says, there are some compelling reasons to do so. I'd love to use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work, for a long time Eclipse did not support 5.0 although I don't think it is anymore. So what is the solution? What does it mean to say not at the expense of existing users on older versions? I think we'd need to modify the site to have full support for two release branches, with some easy switch between them. There should be navigation menu items on the 2.0 site that point back to the 1.4.x site and vice versa as is the case with Tomcat and other projects. We can't just say all new development will be on 2.0, we'll continue to make 1.4.1 available for those who can't make the move. We may want to say that, but I don't think our user base will let us. Until Sun EOL's 1.4.x, I think our policy must be that every change that can be supported on pre-2.0 will be supported there. I also wonder if this should be a jakarta-commons-wide policy and not just something that net does. Rory Winston wrote: Hey guys An interesting discussion here. I'll try to address some of the points raised and give my take on the issue. * As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. See http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 for a few. * As far as I am concerned, the ideal scenario for a project like [net] is that 1.5+ support continues on a different version line. It may be the trunk, it may be a branch. So for [net], the 1.x line is for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean that support is suddenly dropped for pre-Tiger releases. But sooner or later, 2.0 is the main development version, and that's where the effort should go. * I don't like the concept of a .net5 package name. Does this mean that we need a .net6 package space when JDK 6 is released? It doesn't feel elegant, and it loses one of the big advantages that the current system has : a user can upgrade their JDK from 1.3 to 5.0 overnight, download a new [net] 2.0 jar, and their FTPClient-based code should *just work* (with a 90% probability ;)). * I agree with Henri's comment below about Commons being a maintenance vs. development space. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. Cheers Rory Henri
Re: [VOTE] Release [net] version 2.0
On 9/9/06, Steve Cohen [EMAIL PROTECTED] wrote: snip/ I am not ready to vote yet on this until there is a discussion about what this release means. Will commons-net-2.0 become the official release, with previous versions relegated to backward compatibility support? If so, this may be premature as Sun is still supporting JDK-1.4.2-x. snap/ I see this has spawned the necessary discussion, and I'm unlikely to vote until that discussion reaches some semblance of completion. -Rahul But I don't think we should stand in the way of progress either. Rory, can you comment on what are the specific new features that demand JDK 5.0 support? How have other jakarta-commons projects handled this? Are there any official versions that require 1.5? Are there projects that have two official releases? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli][configuration][convert] Architecting our overlaps
Henri Yandell wrote: So I'm using [cli] in [finder] to see if I can mimic the command line interface for the unix find command. I'm using the cli2 version - lots of thought, but very painful to use. Here are the 30 lines of code to add a single option: snip/ Must learn more about the CLI API before I can comment on this. Perusing the CLI2 javadoc, my second thought is that it overlaps with Configuration a lot. You can have Properties and Preferences command There is an enhancement request for [configuration] for a command line configuration: http://issues.apache.org/jira/browse/CONFIGURATION-211 This also shows that there is overlap. lines; and Configuration lacks a CLI style way to input data. Not sure what you mean by this. A third thought is that the CLI2 CommandLine API for the data itself rests on a getValue(Option);Object method, which implies some conversion is going on but I've not seen how yet by looking at the API. Configuration also does conversion of String to various objects. BeanUtils does that too, which gave rise to an overmodelled [convert] package that we've talked about restarting as something simpler. In [configuration] there are many conversion functions to different data types. Especially the conversions that deal with arrays and lists are a pain IMHO: There is a huge amount of code that implements these conversions in a structural very similar way. It would be really cool (except for an additional dependency) if this code could be dropped or significantly be simplified by making use of a special [convert] project. There is surely a need for such a conversion library. Oliver -- Any of that kick off any thoughts? 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
On 9/10/06, Steve Cohen [EMAIL PROTECTED] wrote: Continuing the discussion: 1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3 compatible that we couldn't use it. That's a small point. I doubt we want to have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for all these years, if our soon-to-be target is 1.5. I do agree that the oro dependency has been a very annoying pebble in the shoe. 2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down that road. I guess SVN can handle that but it's still ugly. It makes upgrade for clients of net a maintenance nightmare. 3. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. No, there unfortunately does need to be this debate. Sun has not end-of-lifed 1.4.2. That is important. They continue to release new subreleases of 1.4.2. Why? Important clients are still not ready to use 5.0. My employer, a very large corporation, now mandates the use of 5.0 but is forced immediately to relent on this mandate for some of its most important projects because it also still uses a lot of Websphere which still does not support 5.0 (and won't until WebSphere 7 is released and even then it will be some time before the server teams are ready to make that switch - they dragged their feet on Websphere 6 until recently). So Sun has to support 1.4 (and continues to have to make new subreleases of 1.4.2 for reasons such as the new daylight savings time start/end dates). The world marches on even when corporate java clients do not. Backward compatibility's a bitch, but if Sun has to worry about this, I think we do too. I don't think jakarta-commons has ever downgraded a version of java that Sun considers live. And yet, as Rory says, there are some compelling reasons to do so. I'd love to use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work, for a long time Eclipse did not support 5.0 although I don't think it is anymore. So what is the solution? What does it mean to say not at the expense of existing users on older versions? I think we'd need to modify the site to have full support for two release branches, with some easy switch between them. There should be navigation menu items on the 2.0 site that point back to the 1.4.x site and vice versa as is the case with Tomcat and other projects. We can't just say all new development will be on 2.0, we'll continue to make 1.4.1 available for those who can't make the move. We may want to say that, but I don't think our user base will let us. Until Sun EOL's 1.4.x, I think our policy must be that every change that can be supported on pre-2.0 will be supported there. I also wonder if this should be a jakarta-commons-wide policy and not just something that net does. snip/ Mostly agree to Steve's note above. IMO: * New projects have a choice to start off with 1.4 (the least version that hasn't begun the EOL process) -- as did SCXML. Unless ofcourse, the central concept of the component itself is based on a 1.5 (or higher) feature. * Older projects need to atleast support 1.4 (with active development as in ports back from a 1.5 branch where possible etc.) until 1.4 begins to be EOL'ed. Again, above caveat will apply. Having said that, I've been a proponent of 1.5 branches (and now releases, as long as they're preceded by suitable discussion). As a sidebar, Hen -- I feel your pain about having to go =1.2 for certain releases. Personally, I won't even think about RM'ing anything that needs those. In the end, if its causing much grief that hampers releases, perhaps that baseline may need revisiting. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
I agree with the major points that Steve has made below. I would think that a logical way to go (at least for [net]} would be : * Version 2.0 (JDK 5.0+) becomes the main development branch, and the focal point for new features; * Version 1.x continues to be supported, in that fixes and new features are backported where possible, and code submitted by the community targeted at the 1.x branch can still be applied. I think this is a pretty reasonable way of moving forward, encouraging new development on a codebase free of the shackles of legacy limitations, whilst still being able to service users with more conservative requirements. Rory Steve Cohen wrote: Continuing the discussion: 1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3 compatible that we couldn't use it. That's a small point. I doubt we want to have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for all these years, if our soon-to-be target is 1.5. I do agree that the oro dependency has been a very annoying pebble in the shoe. 2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down that road. I guess SVN can handle that but it's still ugly. It makes upgrade for clients of net a maintenance nightmare. 3. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. No, there unfortunately does need to be this debate. Sun has not end-of-lifed 1.4.2. That is important. They continue to release new subreleases of 1.4.2. Why? Important clients are still not ready to use 5.0. My employer, a very large corporation, now mandates the use of 5.0 but is forced immediately to relent on this mandate for some of its most important projects because it also still uses a lot of Websphere which still does not support 5.0 (and won't until WebSphere 7 is released and even then it will be some time before the server teams are ready to make that switch - they dragged their feet on Websphere 6 until recently). So Sun has to support 1.4 (and continues to have to make new subreleases of 1.4.2 for reasons such as the new daylight savings time start/end dates). The world marches on even when corporate java clients do not. Backward compatibility's a bitch, but if Sun has to worry about this, I think we do too. I don't think jakarta-commons has ever downgraded a version of java that Sun considers live. And yet, as Rory says, there are some compelling reasons to do so. I'd love to use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work, for a long time Eclipse did not support 5.0 although I don't think it is anymore. So what is the solution? What does it mean to say not at the expense of existing users on older versions? I think we'd need to modify the site to have full support for two release branches, with some easy switch between them. There should be navigation menu items on the 2.0 site that point back to the 1.4.x site and vice versa as is the case with Tomcat and other projects. We can't just say all new development will be on 2.0, we'll continue to make 1.4.1 available for those who can't make the move. We may want to say that, but I don't think our user base will let us. Until Sun EOL's 1.4.x, I think our policy must be that every change that can be supported on pre-2.0 will be supported there. I also wonder if this should be a jakarta-commons-wide policy and not just something that net does. Rory Winston wrote: Hey guys An interesting discussion here. I'll try to address some of the points raised and give my take on the issue. * As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. See http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 for a few. * As far as I am concerned, the ideal scenario for a project like [net] is that 1.5+ support continues on a different version line. It may be the trunk, it may be a branch. So for [net], the 1.x line is for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean that support is suddenly dropped for pre-Tiger releases. But sooner or later, 2.0 is the main development version, and that's where the effort should go. * I don't like the concept of a .net5 package
[math] Mantissa inclusion and copyright issues
Hello, As mentioned a few times on this list, I have proposed to donate the Mantissa (http://www.spaceroots.org/software/mantissa/index.html) code to Apache and continue maintaining it here along with commons math. Almost everything has been both designed and coded by me, so I was able to sign a Software Grant myself for everything except one class already identified since the beginning. However, after some checks, four additional Mantissa classes could induce some copyright issues and I am seeking for advices for these classes. org.spaceroots.mantissa.estimation.LevenbergMarquardtEstimator: This class is an implementation of the Levenberg-Marquardt algorithm. The internal code is a translation in Java of the 1980 fortran lmder, lmpar and qrsolv routines (http://www.netlib.org/minpack/lmder.f, http://www.netlib.org/minpack/lmpar.f, http://www.netlib.org/minpack/qrsolv.f) which are distributed as part of minpack under the following license: http://www.netlib.org/minpack/disclaimer. The code I want to donate includes the following changes from minpack: - complete translation of all code in Java - complete redesign of the interface to fit with the existing Mantissa Estimator interface - complete rewrite of the Q.R decomposition part to use another implementation derived from a textbook - adaptation of the upper-level code (calling the Q.R decomposition) to the lower-level implementation changes (calls, indices and columns reordering handling) The implementation of the estimate (lmder), determineLMParameter (lmpar) and determineLMDirection (qrsolv) are the parts that come from Minpack, their origin are advertised (as required by Minpack license) and only the translation in Java and the adaptation are new. All the rest of the class (interface, all other methods including qrDecomposition) is original work. From a users perspective, it is a very important algorithm and a clear improvement for commons math. It also seems that most (if not all) implementations of the algorithm are indeed translations of these minpack routines. It seems difficult to ask for the original authors to provide a software grant to Apache. Is this class acceptable in commons math or should it be dropped (it would be difficult to reimplement the three methods directly translated from minpack) ? org.spaceroots.mantissa.ode.GraggBulirschStoerIntegrator and org.spaceroots.mantissa.ode.GraggBulirschStoerInterpolator These classes are an implementation of the Gragg-Bulirsch-Stoer integrator. The internal code is a translation in Java of the fortran odex code by E. Hairer and G. Wanner (http://www.unige.ch/math/folks/hairer/prog/nonstiff/odex.f) distributed under the following license (BSD type): http://www.unige.ch/~hairer/prog/licence.txt The algorithm is described in the well known Hairer, Norsett and Wanner textbook Solving Differential Equations (part I, nonstiff problems). The code I want to donate includes the following changes from odex: - complete translation of all code in Java - complete redesign of the interface to fit with the existing Mantissa FirstOrderIntegrator interface From a users perspective, this integrator could be omitted. It is one of the best integrators available for nonstiff problems, of course, but Mantissa also includes the Dormand-Prince 8(5,3) which is another very good integrator, and which was implemented from scratch and shares the design of other Runge-Kutta-Fehlberg integrators. Should these two classes be included in commons math ? org.spaceroots.mantissa.random.MersenneTwister: This class is an implementation of the Mersenne twister pseudo-random generator. It is a translation of the Makoto Matsumoto and Takuji Nishimura c code. As there is already an implementation of the Mersenne twister in commons math, it seems irrelevant to include this new implementation. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
I think we are in agreement. I would be available to do some of the backporting work if we go down this path. Does anyone have anything to say about making the site a dual site (something like Tomcat does)? How difficult is that? Does Maven 2 aid in such a process, can it build a site from two different SVN branches at once? Or is it really just two sites that link to one another? Rory Winston wrote: I agree with the major points that Steve has made below. I would think that a logical way to go (at least for [net]} would be : * Version 2.0 (JDK 5.0+) becomes the main development branch, and the focal point for new features; * Version 1.x continues to be supported, in that fixes and new features are backported where possible, and code submitted by the community targeted at the 1.x branch can still be applied. I think this is a pretty reasonable way of moving forward, encouraging new development on a codebase free of the shackles of legacy limitations, whilst still being able to service users with more conservative requirements. Rory Steve Cohen wrote: Continuing the discussion: 1. Regex support is in 1.4. It's only because we were trying to stay 1.2/1.3 compatible that we couldn't use it. That's a small point. I doubt we want to have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for all these years, if our soon-to-be target is 1.5. I do agree that the oro dependency has been a very annoying pebble in the shoe. 2. I'm not comfortable with the .net5 package name. I see a cvs nightmare down that road. I guess SVN can handle that but it's still ugly. It makes upgrade for clients of net a maintenance nightmare. 3. JDK 5.0 has been officially released for around two years. In my opinion, there shouldn't even be a debate. It should be taken advantage of, and supported, although not at the expense of existing users on older versions. No, there unfortunately does need to be this debate. Sun has not end-of-lifed 1.4.2. That is important. They continue to release new subreleases of 1.4.2. Why? Important clients are still not ready to use 5.0. My employer, a very large corporation, now mandates the use of 5.0 but is forced immediately to relent on this mandate for some of its most important projects because it also still uses a lot of Websphere which still does not support 5.0 (and won't until WebSphere 7 is released and even then it will be some time before the server teams are ready to make that switch - they dragged their feet on Websphere 6 until recently). So Sun has to support 1.4 (and continues to have to make new subreleases of 1.4.2 for reasons such as the new daylight savings time start/end dates). The world marches on even when corporate java clients do not. Backward compatibility's a bitch, but if Sun has to worry about this, I think we do too. I don't think jakarta-commons has ever downgraded a version of java that Sun considers live. And yet, as Rory says, there are some compelling reasons to do so. I'd love to use JDK 5.0. It hasn't been a possibility for me yet. Even outside of work, for a long time Eclipse did not support 5.0 although I don't think it is anymore. So what is the solution? What does it mean to say not at the expense of existing users on older versions? I think we'd need to modify the site to have full support for two release branches, with some easy switch between them. There should be navigation menu items on the 2.0 site that point back to the 1.4.x site and vice versa as is the case with Tomcat and other projects. We can't just say all new development will be on 2.0, we'll continue to make 1.4.1 available for those who can't make the move. We may want to say that, but I don't think our user base will let us. Until Sun EOL's 1.4.x, I think our policy must be that every change that can be supported on pre-2.0 will be supported there. I also wonder if this should be a jakarta-commons-wide policy and not just something that net does. Rory Winston wrote: Hey guys An interesting discussion here. I'll try to address some of the points raised and give my take on the issue. * As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. See http://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0 for a few. * As far as I am concerned, the ideal scenario for a project like [net]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
May I point out, that tools like retroweaver or retrotranslator can be used to write code with most 1.5 features while still compiling for 1.4? I don't know whether this applies to the commons-net project, but for most projects I know, this should still be fine. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Mantissa inclusion and copyright issues
It looks like the Minpack license is a BSD license with an extended warranty and liability section. I'll ping the legal-discuss mailing list about it, but it looks fine to me. Just some government boilerplate tacked onto a BSD license I think. The Hairer license is as you say, a BSD-like license, so that's fine. For both cases, we don't need software grants. Instead we put the information in the NOTICE.txt file. I presume the original files you took the code from had copyright statements at the top? Hen On 9/10/06, Luc Maisonobe [EMAIL PROTECTED] wrote: Hello, As mentioned a few times on this list, I have proposed to donate the Mantissa (http://www.spaceroots.org/software/mantissa/index.html) code to Apache and continue maintaining it here along with commons math. Almost everything has been both designed and coded by me, so I was able to sign a Software Grant myself for everything except one class already identified since the beginning. However, after some checks, four additional Mantissa classes could induce some copyright issues and I am seeking for advices for these classes. org.spaceroots.mantissa.estimation.LevenbergMarquardtEstimator: This class is an implementation of the Levenberg-Marquardt algorithm. The internal code is a translation in Java of the 1980 fortran lmder, lmpar and qrsolv routines (http://www.netlib.org/minpack/lmder.f, http://www.netlib.org/minpack/lmpar.f, http://www.netlib.org/minpack/qrsolv.f) which are distributed as part of minpack under the following license: http://www.netlib.org/minpack/disclaimer. The code I want to donate includes the following changes from minpack: - complete translation of all code in Java - complete redesign of the interface to fit with the existing Mantissa Estimator interface - complete rewrite of the Q.R decomposition part to use another implementation derived from a textbook - adaptation of the upper-level code (calling the Q.R decomposition) to the lower-level implementation changes (calls, indices and columns reordering handling) The implementation of the estimate (lmder), determineLMParameter (lmpar) and determineLMDirection (qrsolv) are the parts that come from Minpack, their origin are advertised (as required by Minpack license) and only the translation in Java and the adaptation are new. All the rest of the class (interface, all other methods including qrDecomposition) is original work. From a users perspective, it is a very important algorithm and a clear improvement for commons math. It also seems that most (if not all) implementations of the algorithm are indeed translations of these minpack routines. It seems difficult to ask for the original authors to provide a software grant to Apache. Is this class acceptable in commons math or should it be dropped (it would be difficult to reimplement the three methods directly translated from minpack) ? org.spaceroots.mantissa.ode.GraggBulirschStoerIntegrator and org.spaceroots.mantissa.ode.GraggBulirschStoerInterpolator These classes are an implementation of the Gragg-Bulirsch-Stoer integrator. The internal code is a translation in Java of the fortran odex code by E. Hairer and G. Wanner (http://www.unige.ch/math/folks/hairer/prog/nonstiff/odex.f) distributed under the following license (BSD type): http://www.unige.ch/~hairer/prog/licence.txt The algorithm is described in the well known Hairer, Norsett and Wanner textbook Solving Differential Equations (part I, nonstiff problems). The code I want to donate includes the following changes from odex: - complete translation of all code in Java - complete redesign of the interface to fit with the existing Mantissa FirstOrderIntegrator interface From a users perspective, this integrator could be omitted. It is one of the best integrators available for nonstiff problems, of course, but Mantissa also includes the Dormand-Prince 8(5,3) which is another very good integrator, and which was implemented from scratch and shares the design of other Runge-Kutta-Fehlberg integrators. Should these two classes be included in commons math ? org.spaceroots.mantissa.random.MersenneTwister: This class is an implementation of the Mersenne twister pseudo-random generator. It is a translation of the Makoto Matsumoto and Takuji Nishimura c code. As there is already an implementation of the Mersenne twister in commons math, it seems irrelevant to include this new implementation. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
How does that work exactly? Can we happily write 1.5 stuff and then let the user take the 1.5 jar and retroweave it before using it, or do we have to integrate retroweaver into our builds (though not our sources I hope?)? Hen On 9/10/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: May I point out, that tools like retroweaver or retrotranslator can be used to write code with most 1.5 features while still compiling for 1.4? I don't know whether this applies to the commons-net project, but for most projects I know, this should still be fine. 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
You'd integrate it into your builds. However, this doesn't help with missing APIs (though I believe retrotranslator does take care of some of these). It's a pretty good solution for providing JDK 5 binaries for JDK 1.4. However, I don't think this addresses the issue being faced - and it isn't entirely a JDK 5 related one, but something that is faced whenever a component might want an extreme makeover. IMO, this is the best pattern to follow: - keep the maintenance branches going for the previous release, and bump trunk to the next major version - if new functionality can be isolated to a new package or a separate module, do that (eg, some libraries like xwork have an xwork-tiger module for jdk5 related code) - if the update can remain api compatible, then there is no need to change package names (eg, the JDK added generics to a lot of the runtime without making incompatible changes to the public interfaces) - if the update must change the api, consider changing the package name (but only do so if there is a need to use both versions of the jar in a single classloader, for example lucene was able to safely overhaul their api for 2.0 because it would be unlikely both would be in the same classloader) Obviously, the final one is a last resort and should be avoided - especially since that case would be quite prevalent for commons. If it really really really was needed for some reason, I'd call it o.a.c.net2 (or hopefully something better) rather than net5, reflecting the API not the JDK it is designed for because that'll quickly be outdated as JDK 6 comes out. I think these are all general principles to apply to API evolution, not just for JDK 5 related changes. Didn't collections go through this (backwards-incompatible API change, not a JDK5-ification) Îin the past for 3.0? Any experiences that can be learned from there? HTH, Brett On 11/09/2006, at 7:16 AM, Henri Yandell wrote: How does that work exactly? Can we happily write 1.5 stuff and then let the user take the 1.5 jar and retroweave it before using it, or do we have to integrate retroweaver into our builds (though not our sources I hope?)? Hen On 9/10/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: May I point out, that tools like retroweaver or retrotranslator can be used to write code with most 1.5 features while still compiling for 1.4? I don't know whether this applies to the commons-net project, but for most projects I know, this should still be fine. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Brett Porter wrote: Didn't collections go through this (backwards-incompatible API change, not a JDK5-ification) Îin the past for 3.0? Any experiences that can be learned from there? [collections] 3.0 has been FUDed with the backwards incompatible tag ever since it was released, but it was never exactly true. The release rewrote many classes, and tidied many APIs, but did so by moving them into new packages. The original classes were deprecated, so no problems... ...except that one backwards incompatible change did sneak in - where the return type of a constant was changed. The clirr tool would have caught it, but didn't exist then. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Commons and API change
Some interesting points have been made so far. I believe I should restate my proposal based on feedback (especially as the original was written just after a weeks holiday...): [PROPOSAL] Whenever a project performs a backwards incompatible API change, two things must happen: a) the major version is increased, eg. from 1.2 to 2.0 b) the package name is changed from o.a.c.foo to o.a.c.foo2, or alternatively to a completely new name, eg. o.a.c.bar [/PROPOSAL] Thus, this isn't really a JDK5 issue, but a basic issue of dependency management. And hence, as poined out, the API version number should be used. Note however that it is possible to go up a major version without the proposed rule being enforced *if* and only if there are no backwards incompatible changes (removal of deprecations allowed). Now, I would suggest that many projects going from a JDK1.2/3/4 base to a JDK1.5 base will want to (and should!) make API changes (also, because of generics et al its difficult to know if you *have* actually made a backwards incompatible change!) As such, I would expect these 1.5 projects to be subject to the rule in the proposal. I understand that this is a bit of a pain for end users, but its a pain because of the lack of a module system as per JSR277. I would argue that changing a package name to migrate is infinitely preferable when dealing with a library to coming up against an insoluble jar hell scenario. Remember, [collections] took one small human error to cause an incredible amount of FUD and bad press about commons, that still reduces our user-base today. *Every* jar-hell scenario that is created worsens this. AFAIK, package renaming is the best, most-viable solution to backwards incompatible change in Java today. Stephen Henri Yandell wrote: [PROPOSAL] As such, I would like to propose that projects creating a JDK1.5 only release should use a new package name. Thus, in this case, the release would use the package org.apache.commons.net5.*. -1 for a slew of reasons. * Lots of source code would have to be touched just to upgrade; big pain in the arse for something that is quite likely to not involve any other change to a user's source. * Building v49 class files is going to explode on a v48 JVM, so people are going to be stopped pretty quickly from using the net5 on their old JVM. We don't need to protect them via packages. * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6? With this change, a user can have both the old and the new commons-net jars in their classpath without any conflicts. Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted builds and not 1.2-1.4. And then it's nothing to do with 1.4/1.5 and just the classic problem of package clash within dependencies. Note that these users may be different OSS projects, which may upgrade at different times. Users wishing to migrate from one version to another can simply do a global search and replace on the package name. We must not underestimate the significance of the low-level position of commons in the Java OSS, and proprietry, communities. A clear and planned migration strategy for all our modules is needed. I accept that by its nature Commons is going to cause problems every time they release. We're going to be a frequent location for classpath clash problems. It's not JVM relevant though, it happens every time we release anything so the version you would need in the package name is the Commons major version, not the jdk version. I think we should declare that new development will be on 1.5 - building 1.5 only jars. Anyone trying to use them on 1.4 and before is going to get a nice error and we can start exploring new JDK features like regular expressions *sarc :) *. Then we can stick with it until 1.8 is in beta or something. 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: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
oops! Thanks for the clarification - I'd never had any problems myself, but I thought I'd gotten that indication from the release notes/web site. Long while ago now, obviously my memory isn't so good. - Brett On 11/09/2006, at 7:55 AM, Stephen Colebourne wrote: Brett Porter wrote: Didn't collections go through this (backwards-incompatible API change, not a JDK5-ification) Îin the past for 3.0? Any experiences that can be learned from there? [collections] 3.0 has been FUDed with the backwards incompatible tag ever since it was released, but it was never exactly true. The release rewrote many classes, and tidied many APIs, but did so by moving them into new packages. The original classes were deprecated, so no problems... ...except that one backwards incompatible change did sneak in - where the return type of a constant was changed. The clirr tool would have caught it, but didn't exist then. 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: [math] Mantissa inclusion and copyright issues
Henri Yandell wrote : It looks like the Minpack license is a BSD license with an extended warranty and liability section. I'll ping the legal-discuss mailing list about it, but it looks fine to me. Just some government boilerplate tacked onto a BSD license I think. Thanks. I'm not subscribed to the legal-discuss list, could you tell me when you'll have an answer ? The Hairer license is as you say, a BSD-like license, so that's fine. Fine. For both cases, we don't need software grants. Instead we put the information in the NOTICE.txt file. I presume the original files you took the code from had copyright statements at the top? No, there was no formal copyright statements, just authors lists like you would find in a mathematical paper. In fact I had to dig around in the sites in order to find the licences. In Mantissa, I put the text of theses licenses in the Javadoc at class level and displayed the original authors names in @author statements. Luc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
