date:20060124

Author: rdonkin
Date: Tue Jan 24 09:55:07 2006
New Revision: 371967

URL: http://svn.apache.org/viewcvs?rev=371967view=rev
Log:
Removed links from contents to removed sections.

Modified:
jakarta/commons/proper/logging/trunk/xdocs/guide.xml

Modified: jakarta/commons/proper/logging/trunk/xdocs/guide.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/guide.xml?rev=371967r1=371966r2=371967view=diff
==
--- jakarta/commons/proper/logging/trunk/xdocs/guide.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/guide.xml Tue Jan 24 09:55:07 
2006
@@ -74,12 +74,6 @@
 /ol
 /li
 lia href='#Frequently Asked Questions'Frequently Asked 
Questions/a
-ol
-lia href='#Is JCL Thread Safe?'Is JCL Thread 
Safe?/a/li
-lia href='#Why xxxLogger does not implement 
Log?'Why xxxLogger does not implement Log?/a/li
-lia href='#How Can I Switch Logging Levels On And 
Off?'How Can I Switch Logging Levels On And Off?/a/li
-lia href='#How Do I Change The Logging System 
Configuration?'How Do I Change The Logging System Configuration?/a/li
-/ol
 /li
 /ol
 /p



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r371968 - in /jakarta/commons/proper/logging/trunk: build.xml project.xml

Author: rdonkin
Date: Tue Jan 24 09:59:37 2006
New Revision: 371968

URL: http://svn.apache.org/viewcvs?rev=371968view=rev
Log:
Decided that it's better to include suffix for release candidates.

Modified:
jakarta/commons/proper/logging/trunk/build.xml
jakarta/commons/proper/logging/trunk/project.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=371968r1=371967r2=371968view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Tue Jan 24 09:59:37 2006
@@ -87,7 +87,7 @@
   property name=component.title value=Logging Wrapper Library/
 
   !-- The current version number of this component --
-  property name=component.version   value=1.1/
+  property name=component.version   value=1.1-RC2/
 
   !-- The base directory for compilation targets --
   property name=build.home  value=${basedir}/target/

Modified: jakarta/commons/proper/logging/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/project.xml?rev=371968r1=371967r2=371968view=diff
==
--- jakarta/commons/proper/logging/trunk/project.xml (original)
+++ jakarta/commons/proper/logging/trunk/project.xml Tue Jan 24 09:59:37 2006
@@ -22,7 +22,7 @@
   nameLogging/name
   groupIdcommons-logging/groupId
   artifactIdcommons-logging/artifactId
-  currentVersion1.1/currentVersion
+  currentVersion1.1-RC2/currentVersion
   inceptionYear2001/inceptionYear
   shortDescriptionCommons Logging/shortDescription
   description



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] please check release candidate 1

On Mon, 2006-01-23 at 18:46 -0500, Rahul Akolkar wrote:
 On 1/23/06, robert burrell donkin [EMAIL PROTECTED] wrote:

snip

   I'm all for JCL 1.1, but IMO, the above approach should have been
   discussed before posting these files.
 
  it's just a few files posted to my home directory for checking. there
  hasn't been a vote and no formal announcement. it's not a release, just
  a bad release candidate.
 
 snip/
 
 I understand, but consider this timeline:
 
 a) We put up binaries marked for a release that hasn't been voted on
 in personal webspace (but in the apache.org domain)
 b) We post on the dev list / in bugzilla entries asking folks to try these out
 c) Some do as suggested in (b)
 d) Changes are made to the code and/or packaging, and the release takes place
 e) Release is downloaded. Some in (c) update to correct binaries
 diligently, some forget
 f) We have differing copies of the same marked release out in the wild
 
 Marked as RC, things are different. FWIW, this was my concern.

yep but IMO the risks of this happening are pretty low (it'll be
replaced by another RC soon enough) 

practical problems only start happening when the following happens:

g) someone uploads the jar to a repository

something similar has happened before to a commons library and it causes
trouble. so, the jar's need to be numbered.

  but thanks for highlighting the issue: i've had a chance to sleep on
  this and i think that they should have been versioned (even if that
  makes my life a lot more difficult). RC2 will be.
 
 snap/
 
 OK, and sorry for any trouble.

no trouble: you were right to highlight this issue

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] please check release candidate 1

On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
 On Mon, 2006-01-23 at 22:07 +, robert burrell donkin wrote:
  On Mon, 2006-01-23 at 10:05 +0100, Boris Unckel wrote:

snip

   Second 1.4.2_10 is the actual version, for a new release I would prefer 
   the
   latest compiler (even if there a just minor or no changes). JCL releases
   have a long life cycle, and will be widely spread, so it makes sence to
   compile with the latest available version.
  
  sorry - my bad 
  
  it got very late for me last night and i was too tired to check :(
  
  when i cut logging releases i do two compile runs (one with 1.2 and one
  with a 1.4 JVMs) and then assemble the jars. used the wrong JVM to
  assemble them. 
 
 Why is it necessary to use two different JVMs?

need a 1.4 JVM to compile the java.util stuff but the rest of the code
needs to run fine on earlier JVMs. 

javac settings will care of the differences in class formats but changes
to the system libraries mean that you should compile against the 1.2
java system libraries. this can be done either by using a 1.2 JSDK or by
using a later JSDK and setting bootclasspath appropriately. 

if we were confident that our unit tests had 100% code coverage then
compiling with a 1.4 JSDK would probably be safe enough. i'm not that
confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
more confident to use the system i know works.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r371976 - /jakarta/commons/proper/logging/trunk/build.xml

Author: rdonkin
Date: Tue Jan 24 10:39:24 2006
New Revision: 371976

URL: http://svn.apache.org/viewcvs?rev=371976view=rev
Log:
Removed properties used by the now-removed optional build.

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=371976r1=371975r2=371976view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Tue Jan 24 10:39:24 2006
@@ -105,10 +105,6 @@
   property name=test.home   value=src/test/
 
 
-  !-- Optional build --
-  property name=optional.home   value=optional/
-  property name=optional.dist.home   value=${optional.home}/dist/
-
   !-- jar names --
   property name=core.jar.name 
value=commons-${component.name}-${component.version}.jar/
   property name=api.jar.name 
value=commons-${component.name}-api-${component.version}.jar/
@@ -198,7 +194,6 @@
   property name=test.sysprops.commons-logging 
value=${build.home}/${core.jar.name}/
   property name=test.sysprops.commons-logging-api 
value=${build.home}/${api.jar.name}/
   property name=test.sysprops.commons-logging-adapters 
value=${build.home}/${adapters.jar.name}/
-  property name=test.sysprops.commons-logging-optional 
value=${dist.home}/${optional.jar.name}/
   propertyset id=test-lib-props
 propertyref prefix=test.sysprops./
 mapper type=glob from=test.sysprops.* to=*/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r371977 - /jakarta/commons/proper/logging/trunk/build.xml

Author: rdonkin
Date: Tue Jan 24 10:42:57 2006
New Revision: 371977

URL: http://svn.apache.org/viewcvs?rev=371977view=rev
Log:
Removed javadoc target. Use maven for documentation including javadocs.

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=371977r1=371976r2=371977view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Tue Jan 24 10:42:57 2006
@@ -532,39 +532,7 @@
description=Clean and compile all components/
 
 
-  target name=javadoc depends=compile
-   description=Create component Javadoc documentation
-mkdir  dir=${dist.home}/
-mkdir  dir=${dist.home}/docs/
-mkdir  dir=${dist.home}/docs/api/
-javadoc sourcepath=${source.home}
-destdir=${dist.home}/docs/api
-   overview=${source.home}/overview.html
-   packagenames=org.apache.commons.*
- author=true
-private=true
-version=true
-   doctitle=lt;h1gt;${component.title} (Version 
${component.version})lt;/h1gt;
-windowtitle=${component.title} (Version ${component.version})
- bottom='Copyright 2002-2004 The Apache Software 
Foundation.lt;!--
-
-Licensed 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.--gt;'
-  classpath refid=javadoc.classpath/
-/javadoc
-  /target
-
-
-  target name=dist depends=compile,javadoc
+  target name=dist depends=compile
description=Create binary distribution

 !--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r371978 - /jakarta/commons/proper/logging/trunk/build.xml

Author: rdonkin
Date: Tue Jan 24 10:46:20 2006
New Revision: 371978

URL: http://svn.apache.org/viewcvs?rev=371978view=rev
Log:
Default target is now 'all' and target 'all' now runs the unit tests.

Modified:
jakarta/commons/proper/logging/trunk/build.xml

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=371978r1=371977r2=371978view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Tue Jan 24 10:46:20 2006
@@ -36,7 +36,7 @@
   - $Id$
   --
 
-project name=Logging default=compile basedir=.
+project name=Logging default=all basedir=.
 
 
 !-- == Initialize Properties = --
@@ -528,7 +528,7 @@
   /target
 
 
-  target name=all depends=clean,compile
+  target name=all depends=clean,compile,test
description=Clean and compile all components/
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [exec] API sketch?

2006-01-24 Thread Niklas Gustavsson


Brett Porter wrote:

Niklas Gustavsson wrote:

/*
 * StreamHandlers are used for providing input,
 * retriving the output. Also used for logging.
 */
StreamHandler getStreamHandler();
void setStreamHandler(StreamHandler streamHandler);


My only comments on these is that I don't see the point of the setters
in the interface - is it a requirement of the use of the library, or is
it an implementation detail? (eg, I use plexus which instantiates
objects implementations with private field injection, some use setters
through reflection, some through a constructor - I'm not sure the
interface requires it).


 As for the stream handler - what is the contents of that interface? Does
 it have an input, output and error stream?


In this sketch, the StreamHandler provide the streams for in, out and 
err. There are some examples of StreamHandlers in the current code.


In one way or another this functionality would be required in the API.


You have commit access now, so if you want to start writing some example
code (or create a fresh branch, even), you're welcome to.


Yeah, I know. Just wanted to get some input here before getting going :-)

/niklas

---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] please check release candidate 1

2006-01-24 Thread Simon Kitching

On Tue, 2006-01-24 at 18:39 +, robert burrell donkin wrote:
 On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
  Why is it necessary to use two different JVMs?
 
 need a 1.4 JVM to compile the java.util stuff but the rest of the code
 needs to run fine on earlier JVMs. 
 
 javac settings will care of the differences in class formats but changes
 to the system libraries mean that you should compile against the 1.2
 java system libraries. this can be done either by using a 1.2 JSDK or by
 using a later JSDK and setting bootclasspath appropriately. 
 
 if we were confident that our unit tests had 100% code coverage then
 compiling with a 1.4 JSDK would probably be safe enough. i'm not that
 confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
 more confident to use the system i know works.

Ok, sounds entirely reasonable. I agree there are corner cases where
target doesn't solve the problem (eg the new StringBuffer overloaded
methods in more recent JVMs).

It might be nice to note this somewhere, eg as a comment in the
build.xml file or similar.

Cheers,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [exec] API sketch?

2006-01-24 Thread Niklas Gustavsson


Brett Porter wrote:

Niklas Gustavsson wrote:

/*
 * StreamHandlers are used for providing input,
 * retriving the output. Also used for logging.
 */
StreamHandler getStreamHandler();
void setStreamHandler(StreamHandler streamHandler);


My only comments on these is that I don't see the point of the setters
in the interface - is it a requirement of the use of the library, or is
it an implementation detail? (eg, I use plexus which instantiates
objects implementations with private field injection, some use setters
through reflection, some through a constructor - I'm not sure the
interface requires it).


 As for the stream handler - what is the contents of that interface? Does
 it have an input, output and error stream?


In this sketch, the StreamHandler provide the streams for in, out and 
err. There are some examples of StreamHandlers in the current code.


In one way or another this functionality would be required in the API.


You have commit access now, so if you want to start writing some example
code (or create a fresh branch, even), you're welcome to.


Yeah, I know. Just wanted to get some input here before getting going :-)

/niklas

---
Niklas Gustavsson
http://www.protocol7.com
mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues

2006-01-24 Thread Daniel F. Savarese


In message [EMAIL PROTECTED], Rahul
 Akolkar writes:
No, haven't had to deal with such a situation. But doesn't this mean
that the code will only work on a subset of the 1.3 JDKs (Sun)? If so,
maybe (3) isn't all that bad?

In general, I am biased against introducing dependencies on com.sun packages
for the very reason stated.  The code will work only with the Sun JDK or
JVMs incorporating sublicensed parts of the JDK that include those packages.
For that matter, it will work only with a particular version of the Sun JVM
should the classes not appear in a future release.  If JSSE will work and
is usable with JDK 1.3 as an add-on jar, I don't see any reason why it
should be avoided (i.e., I'm +1 for option 3 and -1 for 2).

daniel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372020 - in /jakarta/commons/proper/logging/trunk: ./ build.properties.sample build.xml

Author: rdonkin
Date: Tue Jan 24 13:09:51 2006
New Revision: 372020

URL: http://svn.apache.org/viewcvs?rev=372020view=rev
Log:
Updated dist method to reflect modern practice. Added optional isolated 
compilation for releases (requires a pre-1.4 JVM to run the ant tasks and the 
executable.javac1.4 build property to be set). Artifacts are built in new 
subdirectory with file ending standardisation. Ant lacks a svn task so will 
consider whether the source artifacts should also be created by dist.

Modified:
jakarta/commons/proper/logging/trunk/   (props changed)
jakarta/commons/proper/logging/trunk/build.properties.sample
jakarta/commons/proper/logging/trunk/build.xml

Propchange: jakarta/commons/proper/logging/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Tue Jan 24 13:09:51 2006
@@ -8,3 +8,5 @@
 .project
 .classpath
 .repositoryIndex
+*.tar.gz
+*.zip

Modified: jakarta/commons/proper/logging/trunk/build.properties.sample
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.properties.sample?rev=372020r1=372019r2=372020view=diff
==
--- jakarta/commons/proper/logging/trunk/build.properties.sample (original)
+++ jakarta/commons/proper/logging/trunk/build.properties.sample Tue Jan 24 
13:09:51 2006
@@ -38,3 +38,8 @@
 # Those committers using agents may like to use
 #maven.username=rdonkin
 #logging.cvs=lserver:[EMAIL PROTECTED]:/home/cvs
+
+
+# The path to a 1.4 JSDK javac
+# Optional - used when building with a 1.2 JVM for releases
+# executable.javac1.4=/opt/java/jdks/j2sdk1.4.2_10/bin/javac

Modified: jakarta/commons/proper/logging/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=372020r1=372019r2=372020view=diff
==
--- jakarta/commons/proper/logging/trunk/build.xml (original)
+++ jakarta/commons/proper/logging/trunk/build.xml Tue Jan 24 13:09:51 2006
@@ -33,6 +33,11 @@
   -  * run ant as ant -lib path-to-junit-jar
   -  * put the junit jar in $CLASSPATH
   -
+  - Note when building JCL for release it is strongly recommended that a 1.2 
JVM
+  - is used for the main compile and the home.jdk4 property used to specify
+  - the path to a 1.4 J2SDK. This will be used to compile those classes
+  - which require the 1.4 API. 
+  -
   - $Id$
   --
 
@@ -97,6 +102,9 @@
 
   !-- The base directory for distribution targets --
   property name=dist.home   value=dist/
+   
+  !-- The base directory for releases  --
+  property name=artifacts.home   value=artifacts/
 
   !-- The base directory for component sources --
   property name=source.home value=src/java/
@@ -104,11 +112,14 @@
   !-- The base directory for unit test sources --
   property name=test.home   value=src/test/
 
-
   !-- jar names --
   property name=core.jar.name 
value=commons-${component.name}-${component.version}.jar/
   property name=api.jar.name 
value=commons-${component.name}-api-${component.version}.jar/
   property name=adapters.jar.name 
value=commons-${component.name}-adapters-${component.version}.jar/
+   
+  !-- dist names --
+  property name=windows.dist.name 
value=commons-${component.name}-${component.version}.zip/
+  property name=nix.dist.name 
value=commons-${component.name}-${component.version}.tar.gz/
   
 !-- == Compiler Defaults = --
 
@@ -236,8 +247,6 @@
 mkdir dir=${build.home}/
 mkdir dir=${build.home}/classes/
 mkdir dir=${build.home}/conf/
-mkdir dir=${build.home}/docs/
-mkdir dir=${build.home}/docs/api/
 mkdir dir=${build.home}/tests/
   /target
 
@@ -313,7 +322,7 @@
   /target
 
   target name='warning' 
-
depends='log4j12-warning,log4j13-warning,logkit-warning,jdk1.4-warning,avalon-framework-warning'/
+
depends='log4j12-warning,log4j13-warning,logkit-warning,jdk1.4-warning,avalon-framework-warning,compile-1.4'/
 
   target name=compile-only 
 
depends=prepare,discovery,warning,show-lib-presence,compile-non-log4j,compile-log4j12,compile-log4j13,build-jar/
@@ -350,6 +359,38 @@
unless=avalon-framework.present/
 /javac
   /target
+   
+  target name=compile-1.4 depends=prepare,discovery,compile-non-log4j 
if='executable.javac1.4'
+   !-- 
+Compiles those classes which require a 1.4+ JSDK.
+This target will only be executed when ant is running a pre-1.4 JVM
+and the home.jdk4 property is set.
+This configuration is typically used to create a release only.
+   --
+   echo  message=/
+   echo  
message=/
+   echo  message=Compiling 1.4 only classes using [EMAIL 
PROTECTED]/
+   echo

Re: [logging] please check release candidate 1

On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
 On Tue, 2006-01-24 at 18:39 +, robert burrell donkin wrote:
  On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
   Why is it necessary to use two different JVMs?
  
  need a 1.4 JVM to compile the java.util stuff but the rest of the code
  needs to run fine on earlier JVMs. 
  
  javac settings will care of the differences in class formats but changes
  to the system libraries mean that you should compile against the 1.2
  java system libraries. this can be done either by using a 1.2 JSDK or by
  using a later JSDK and setting bootclasspath appropriately. 
  
  if we were confident that our unit tests had 100% code coverage then
  compiling with a 1.4 JSDK would probably be safe enough. i'm not that
  confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
  more confident to use the system i know works.
 
 Ok, sounds entirely reasonable. I agree there are corner cases where
 target doesn't solve the problem (eg the new StringBuffer overloaded
 methods in more recent JVMs).
 
 It might be nice to note this somewhere, eg as a comment in the
 build.xml file or similar.

the latest build.xml now supports dual compilation (1.2 and 1.4). the
ant task should be run by a 1.2 JDK and a build.property set the a 1.4
compiler. there's some documentation but i hope to return to this later
(unless anyone else beats me to it).

i'm now trying to think about whether to add a task to build the source
distributions. one advantage is that it would automatically standardise
the EOLs. one disadvantage is that it would require using exec to call
svn directly. another is that it should really be loaded from a tag
which would mean another build property.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[logging] commit freeze, please

i plan to tag RC2 sometime after 2130GMT today. please do not commit
changes after than time until you see the commit record for the tag.

cheers

- robert


signature.asc
Description: This is a digitally signed message part

Re: [logging] please check release candidate 1

2006-01-24 Thread Dennis Lundberg


robert burrell donkin wrote:

On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:

On Tue, 2006-01-24 at 18:39 +, robert burrell donkin wrote:

On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:

Why is it necessary to use two different JVMs?

need a 1.4 JVM to compile the java.util stuff but the rest of the code
needs to run fine on earlier JVMs. 


javac settings will care of the differences in class formats but changes
to the system libraries mean that you should compile against the 1.2
java system libraries. this can be done either by using a 1.2 JSDK or by
using a later JSDK and setting bootclasspath appropriately. 


if we were confident that our unit tests had 100% code coverage then
compiling with a 1.4 JSDK would probably be safe enough. i'm not that
confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
more confident to use the system i know works.

Ok, sounds entirely reasonable. I agree there are corner cases where
target doesn't solve the problem (eg the new StringBuffer overloaded
methods in more recent JVMs).

It might be nice to note this somewhere, eg as a comment in the
build.xml file or similar.


the latest build.xml now supports dual compilation (1.2 and 1.4). the
ant task should be run by a 1.2 JDK and a build.property set the a 1.4
compiler. there's some documentation but i hope to return to this later
(unless anyone else beats me to it).

i'm now trying to think about whether to add a task to build the source
distributions. one advantage is that it would automatically standardise
the EOLs. one disadvantage is that it would require using exec to call
svn directly. another is that it should really be loaded from a tag
which would mean another build property.


Robert, why would you need to use svn? If you are adding this to easy 
the creating of RC:s and releases, then I would imagine that the release 
manager has already checked out the correct tag from svn. If that is the 
case then the source is already checked out as well, you just need to 
package it.


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues

2006-01-24 Thread Jose Juan Montiel

 1.  Use the javax.net.ssl classes.  (Out of the question because of our
 mandate to support 1.3)

 2.  Do what Paul and Josejuan did - use the com.sun classes

 3.  Maybe.  use the javax.net.ssl classes but document that if used with
 JDK  1.4, jsse.jar must be on the classpath.

Hi, i'll use the second option, because if commons-net implements
SSL-FTPS under JDK 1.3, its necesary import JSSE, and if use JDK 1.4,
the source code, don't need any change.

When commons-net, upgrde to JDK 1.4, if want remove JSSE, the
modifications in source code will be simples. I'll do it :)

The 3º option it not possible, because, don't work under 1.3, although
import jsse.jar... need change the import in source code...

Its my opinion.

Thanks for all.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[lang] EqualsBuilder: Comparison of Collections

2006-01-24 Thread Matthias Pfau

Hi,
this is my first post ever to a mailing list so please do not mind to tell
me if I do sth. wrong... ;)

I just asked myself why the EqualsBuilder does not support the comparison of
Collections. Personally, I am very often in the situation that I have to
compare Collections. Collections are widely used and there might be other
people out there that need a proper support for this case. As you might know
the problem when just calling .equals(other) on an object is, that both
Collections need to have the same order. But two Collections should
definitely be equal if they contain the same elements, ordering is not
important!

The following code respects this and is my proposal to enhance the
EqualsBuilder.

--snip--

public EqualsBuilder append(Collection lhs, Collection rhs) {
if (isEquals == false) {
return this;
}
if (lhs == rhs) {
return this;
}
if (lhs == null || rhs == null) {
this.setEquals(false);
return this;
}
if (lhs.size() != rhs.size()) {
this.setEquals(false);
return this;
}
if (lhs.size() == Integer.MAX_VALUE) {
if (!lhs.containsAll(rhs) || !rhs.containsAll(lhs)) {
this.setEquals(false);
}
return this;
}
if (!lhs.containsAll(rhs)) {
this.setEquals(false);
}
return this;
}

--snap--

Looking forward to your comments!

Kind Regards,
Matthias Pfau


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372029 - in /jakarta/commons/sandbox/id/trunk/src: java/org/apache/commons/id/ java/org/apache/commons/id/task/ java/org/apache/commons/id/uuid/ test/org/apache/commons/id/

2006-01-24 Thread joehni

Author: joehni
Date: Tue Jan 24 13:51:23 2006
New Revision: 372029

URL: http://svn.apache.org/viewcvs?rev=372029view=rev
Log:
Dropped IdentifierGeneratorFactory and derived.
Dropped IdentifierUtils.

Removed:

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/DefaultIdentifierGeneratorFactory.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/IdentifierGeneratorFactory.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/IdentifierUtils.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/CustomIdentifierGeneratorFactory.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierGeneratorFactoryTest.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/IdentifierUtilsTest.java
Modified:

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java?rev=372029r1=372028r2=372029view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java
 Tue Jan 24 13:51:23 2006
@@ -16,7 +16,6 @@
 
 package org.apache.commons.id.task;
 
-import org.apache.commons.id.IdentifierUtils;
 import org.apache.commons.id.uuid.UUID;
 import org.apache.tools.ant.BuildException;
 import org.apache.tools.ant.Task;
@@ -59,7 +58,7 @@
uuid = UUID.nameUUIDFromString(name, new 
UUID(namespace), UUID.SHA1_ENCODING);
}
else if (uuidVersion.equals(VERSION_FOUR)) {
-   uuid = (UUID) 
IdentifierUtils.UUID_VERSION_FOUR_GENERATOR.nextIdentifier();
+   uuid = UUID.randomUUID();
}
else if (uuidVersion.equals(VERSION_ONE)) {
uuid = UUID.timeUUID();

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java?rev=372029r1=372028r2=372029view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java 
(original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java 
Tue Jan 24 13:51:23 2006
@@ -15,16 +15,15 @@
  */
 package org.apache.commons.id.uuid;
 
+import org.apache.commons.id.DecoderException;
+import org.apache.commons.id.DigestUtils;
+import org.apache.commons.id.Hex;
+
 import java.io.DataInput;
 import java.io.IOException;
 import java.io.Serializable;
 import java.util.StringTokenizer;
 
-import org.apache.commons.id.DecoderException;
-import org.apache.commons.id.DigestUtils;
-import org.apache.commons.id.Hex;
-import org.apache.commons.id.IdentifierUtils;
-
 
 /**
  * pcodeUUID/code represents a Universally Unique Identifier per RFC 
4122.
@@ -60,7 +59,6 @@
/** Holds the internal string value of the UUID */
private String stringValue = null;

-   
/** Constructs a nil UUID */
public UUID() {
super();
@@ -406,7 +404,7 @@
 * @return a new version 4 UUID, based upon Random bits.
 */
public static UUID randomUUID() {
-   return (UUID) 
IdentifierUtils.UUID_VERSION_FOUR_GENERATOR.nextIdentifier();
+return VersionFourGenerator.getInstance().nextUUID();
}

/**
@@ -415,7 +413,7 @@
 * @return a new version 1 UUID, based upon node identifier and time 
stamp.
 */
public static UUID timeUUID() {
-   return (UUID) 
IdentifierUtils.UUID_VERSION_ONE_GENERATOR.nextIdentifier();
+   return VersionOneGenerator.getInstance().nextUUID();
}

/**

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java?rev=372029r1=372028r2=372029view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java
 (original)
+++

Re: [logging] please check release candidate 1

On Tue, 2006-01-24 at 22:35 +0100, Dennis Lundberg wrote:
 robert burrell donkin wrote:
  On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
  On Tue, 2006-01-24 at 18:39 +, robert burrell donkin wrote:
  On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
  Why is it necessary to use two different JVMs?
  need a 1.4 JVM to compile the java.util stuff but the rest of the code
  needs to run fine on earlier JVMs. 
 
  javac settings will care of the differences in class formats but changes
  to the system libraries mean that you should compile against the 1.2
  java system libraries. this can be done either by using a 1.2 JSDK or by
  using a later JSDK and setting bootclasspath appropriately. 
 
  if we were confident that our unit tests had 100% code coverage then
  compiling with a 1.4 JSDK would probably be safe enough. i'm not that
  confident and every other JCL release i've cut has used 2 JSDKs. so, i'm
  more confident to use the system i know works.
  Ok, sounds entirely reasonable. I agree there are corner cases where
  target doesn't solve the problem (eg the new StringBuffer overloaded
  methods in more recent JVMs).
 
  It might be nice to note this somewhere, eg as a comment in the
  build.xml file or similar.
  
  the latest build.xml now supports dual compilation (1.2 and 1.4). the
  ant task should be run by a 1.2 JDK and a build.property set the a 1.4
  compiler. there's some documentation but i hope to return to this later
  (unless anyone else beats me to it).
  
  i'm now trying to think about whether to add a task to build the source
  distributions. one advantage is that it would automatically standardise
  the EOLs. one disadvantage is that it would require using exec to call
  svn directly. another is that it should really be loaded from a tag
  which would mean another build property.
 
 Robert, why would you need to use svn? If you are adding this to easy 
 the creating of RC:s and releases, then I would imagine that the release 
 manager has already checked out the correct tag from svn. If that is the 
 case then the source is already checked out as well, you just need to 
 package it.

it's best to export a fresh copy from the tag. a couple of reasons:

1 this ensures that no svn meta-data is present
2 it ensure that no temporary files used when building the release are
left in the source distribution

i'll probably just use svn, i think. svn export --native-eols=XXX should
do the line ending conversions automatically.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of id/1.0ReleasePlan by JörgSchaible

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by JÃ¶rgSchaible:
http://wiki.apache.org/jakarta-commons/id/1%2e0ReleasePlan

The comment on the change is:
Update status.

--
   * Review UUID implementation and verify the spec compliance 
[[http://www.ietf.org/rfc/rfc4122.txt RFC 4122]]
* Verify spec compliance
* Check against JDK 1.5 functionality
-   * Introduce a UUIDIdentifierGenerator interface extending 
StringIdentifierGenerator with extended functionality to get the identifier 
directly as UUID or additionally as byte array.
+   * Introduce a UUIDIdentifierGenerator interface with extended functionality 
to get the identifier directly as UUID or additionally as byte array.
+   * Introcuce a UUIDStringIdentifierGenerator as wrapper for a 
UUIDIdentifierGenerator
* Review the internal plugin mechanism (may drop dependency to 
commons-discovery and commons-logging)
* Fix persistent store of State (ensure usability in system class path and 
application class path)
+   * Allow multiple instances of VersionOneGenerator to support IoC containers
-  * Drop IdentifierGeneratorFactory and IdentifierUtils
+  * Drop IdentifierGeneratorFactory and IdentifierUtils (./)
This elements used static versions of each available IdentifierGenrator 
implementation and parametrization to provide a convenient way to access the 
generators available in commons-id. With the addition of new generator 
implementations the convenience for users vanish in combination with the 
maintainability.
   * Refactor PrefixXXXGeneratorIdentifier implementations
It might be useful for all String-based generators to decorate the created 
identifier. The 3 current prefix implementations should be replaced by a 
generic decorator or transformator approach.
@@ -35, +37 @@

   * Clean-up exception handling
Some methods have currently signatures for exceptions they do not throw. 
Some code throws a simple RuntimeException instead of introducing a derived 
exception for the commons-id components. A lot of internally runtime exceptions 
are not mentioned in the javadoc.
   * Improve test path coverage and fix remaining style issues
-  * Unify initialization of unit tests
+  * Unify initialization of unit tests (./)
-   A lot of unit tests use a suite method, have a constructor to parametrise 
the name and have a main method. All of this is normally not necessary in 
modern IDEs. In Eclipse this is even worse, since you cannot click on the run 
tests to switch to the test's source. '''Done.'''
+   A lot of unit tests use a suite method, have a constructor to parametrise 
the name and have a main method. All of this is normally not necessary in 
modern IDEs. In Eclipse this is even worse, since you cannot click on the run 
tests to switch to the test's source.
   * Check year of copyright in touched files

  === Documentation ===

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Trivial Update of id/1.0Release Plan by JörgSchaible

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by JÃ¶rgSchaible:
http://wiki.apache.org/jakarta-commons/id/1%2e0ReleasePlan

--
  
  === Build ===
  
-  * Use Cobertura for coverage report
+  * Use Cobertura for coverage report (./)
-   '''Done.'''
  
  == RC(s) ==
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [exec] design goals, API sketch, etc.. next step?

2006-01-24 Thread Niklas Gustavsson


jerome lacoste wrote:

Niklas, Brett, Trygve  all,


So here's what I propose to do:
- decide which requirements are important. What is the problem we are
trying to solve? How do we position us compared to the official's API?
etc... Someone using SDK 1.4 or 1.5 should find a compelling reason to
migrate to commons-exec. The migration should be intuitive. Benefits
for migrating clear. I think I exposed my ideas in the thread about
the library's vision.



Agreed, lets got through the requirements gathered so far (these are 
more of less copied from your's and Bretts email with some additions by 
myself).


* Provide an equivalent to ProcessBuilder working in older JREs
* Process and Stream management, allowing flexible reuse of this 
functionality

* be able to run an external command in a small number of lines,
capturing or streaming output and pass in my own input handler. Have it
actually work on Windows and Unix et al when there are quotes, spaces,
etc in the binary, arguments, etc.
* be able to run a process in the background, find out when it finished,
kill it if necessary.
* wire it up in an IoC container so I can do even less code to configure
it
* Provide an API for retrieving the current environment

Would you like anything else in there?

I think those listed above are covered by the current code, albeit 
behind an ugly API.



- we compare the clean API sketch to the refactoring I made in
September. We focus on making this API easy to use and remember
without compromise on flexibility.


Agreed, I will check out your refactoring next.


- we then take a decision on how to reach an implementation that
satisfies this API (Either start from the API sketch, or from the
refactorings I made 4 months ago).


I don't care on the approach as long as we get things moving and that
efforts are not wasted.

Niklas you said you could coordinate. I offered my help for coding,
documentation and tests. There's already a lot of work done on that.
Who else is interested? How do we proceed? Niklas I let you answer
those questions.


Yeap, I'll try my best to coordinate the efforts. First of all, I would 
like us to agree on the initial requirements. From what I gather, I 
think our basic requirements are very similar so I don't expect this to 
be any problem.


I will also have a look at the refactoring you've made and get back with 
comments on that tomorrow.




Let's try not to loose the momentum. I just don't want my efforts to
be wasted (so far they haven't been productive enough to my taste). 


Agreed.


I
would really like this library to be in early alpha by end of
February. So I can get it off the list of things I said I would do.



I think that is a reasonable goal.

/niklas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372030 - /jakarta/commons/proper/logging/trunk/

Author: rdonkin
Date: Tue Jan 24 13:57:44 2006
New Revision: 372030

URL: http://svn.apache.org/viewcvs?rev=372030view=rev
Log:
Ignore new artifacts directory used by dist target.

Modified:
jakarta/commons/proper/logging/trunk/   (props changed)

Propchange: jakarta/commons/proper/logging/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Tue Jan 24 13:57:44 2006
@@ -10,3 +10,4 @@
 .repositoryIndex
 *.tar.gz
 *.zip
+arifacts



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372031 - /jakarta/commons/proper/logging/trunk/

Author: rdonkin
Date: Tue Jan 24 13:58:22 2006
New Revision: 372031

URL: http://svn.apache.org/viewcvs?rev=372031view=rev
Log:
Ignore new artifacts directory used by dist target. (Fix)

Modified:
jakarta/commons/proper/logging/trunk/   (props changed)

Propchange: jakarta/commons/proper/logging/trunk/
--
--- svn:ignore (original)
+++ svn:ignore Tue Jan 24 13:58:22 2006
@@ -10,4 +10,4 @@
 .repositoryIndex
 *.tar.gz
 *.zip
-arifacts
+artifacts



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372032 - /jakarta/commons/proper/logging/tags/LOGGING_1_1_0_RC2/

Author: rdonkin
Date: Tue Jan 24 13:59:06 2006
New Revision: 372032

URL: http://svn.apache.org/viewcvs?rev=372032view=rev
Log:
Tag for the second release candidate for JCL 1.1

Added:
jakarta/commons/proper/logging/tags/LOGGING_1_1_0_RC2/
  - copied from r372031, jakarta/commons/proper/logging/trunk/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372033 - in /jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id: task/UUIDTask.java uuid/UUID.java uuid/VersionFourGenerator.java uuid/VersionOneGenerator.java

2006-01-24 Thread joehni

Author: joehni
Date: Tue Jan 24 14:00:20 2006
New Revision: 372033

URL: http://svn.apache.org/viewcvs?rev=372033view=rev
Log:
Fix year of copyright.

Modified:

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java?rev=372033r1=372032r2=372033view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/task/UUIDTask.java
 Tue Jan 24 14:00:20 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2004 The Apache Software Foundation.
+ * Copyright 2002-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java?rev=372033r1=372032r2=372033view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java 
(original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/UUID.java 
Tue Jan 24 14:00:20 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2004 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java?rev=372033r1=372032r2=372033view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionFourGenerator.java
 Tue Jan 24 14:00:20 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2004 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java?rev=372033r1=372032r2=372033view=diff
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/VersionOneGenerator.java
 Tue Jan 24 14:00:20 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 2004 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] commit freeze, please

done

feel free to add documentation enhancements and fixes (dennis?
changes.xml?)

- robert

On Tue, 2006-01-24 at 21:23 +, robert burrell donkin wrote:
 i plan to tag RC2 sometime after 2130GMT today. please do not commit
 changes after than time until you see the commit record for the tag.
 
 cheers
 
 - robert


signature.asc
Description: This is a digitally signed message part

[logging] please check release candidate 2

please download and check the 2nd release candidate from
http://people.apache.org/~rdonkin/commons-logging/.

the binary distributions should have standardised EOLs. installing the
latest subversion is giving me a few issues so the source distributions
ATM will probably have nix EOLs. please check that nothing has been
stuffed up by the EOLs and that they seem right.

- robert


signature.asc
Description: This is a digitally signed message part

[Jakarta-commons Wiki] Update of Logging by BorisUnckel

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by BorisUnckel:
http://wiki.apache.org/jakarta-commons/Logging

--
   * [http://logging.apache.org/log4j/docs/ Log4J]
   * [https://simple-log.dev.java.net/ Simple Log]
   * Ever get irratated with enclosing your log statements in conditionals?  
[http://just4log.sourceforge.net/ Just4Log] engineers the bytecode so that 
every log statements has a conditional wrapper!
+  * [http://www.x4juli.org/ x4juli] a native implementation of JCL for 
java.util.logging. Currently in alpha state.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [lang] EqualsBuilder: Comparison of Collections

2006-01-24 Thread Stephen Colebourne


Matthias Pfau wrote:

this is my first post ever to a mailing list

Welcome


I just asked myself why the EqualsBuilder does not support the comparison of
Collections. Personally, I am very often in the situation that I have to
compare Collections. Collections are widely used and there might be other
people out there that need a proper support for this case. As you might know
the problem when just calling .equals(other) on an object is, that both
Collections need to have the same order. But two Collections should
definitely be equal if they contain the same elements, ordering is not
important!


This is a misunderstanding of the java collections framework.

The framework consists of three collections interfaces - Collection, Set 
and List.


Two List implementations are equal based on their order.
Two Set implementations are equal based on their content.
Two Collection implementations have no defined equals behaviour.

If you want to achieve equals comparison based on content without order, 
then simply create two HashSet objects instead of two ArrayList objects.


Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [id] Review before 1.0 (Summary)

2006-01-24 Thread Phil Steitz

On 1/24/06, Jörg Schaible [EMAIL PROTECTED] wrote:
 Hi Michael,

 Michael Heuer wrote on Friday, January 20, 2006 7:40 PM:

  On Fri, 20 Jan 2006, Phil Steitz wrote:
  I have started working on this.  What I had in mind was just a simple
  facility for creating composite identifiers created by concatenating
  results of an array of generators.  This does add overhead for the
  prefix identifiers, so we may actually want to keep these.
  Synchronization is a separate issue.  I will commit some code this
  weekend to look at.
 
  Phil, could you create a bugzilla entry for this?  I might
  have something
  to contribute.

 Just open a BZ issue and add oyur patches :)

 - Jörg

+1 -- sorry I have been a bit nonresponsive last couple of days.  I am
travelling with limited access.  By all means open ticket and add
patches.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: doap maven project descriptor [was Re: svn commit: r371566]

2006-01-24 Thread Martin van den Bemt

On general @ jakarta Henri mentioned that the BCEL version was generated from the project.xml. I 
assume he did that with these doap files.

I hope that Henri didn't mean generated by hand from the project.xml.
It should be pretty easy to whip a plugin for maven 1 and 2.

Mvgr,
Martin

Niall Pemberton wrote:

Theres quite a bit of overlap between whats in maven's project.xml and whats
in this doap format - seems a shame to have to have it in two places. Maybe
a maven doap plugin would be a good idea?

Niall

- Original Message - 
From: [EMAIL PROTECTED]

To: [EMAIL PROTECTED]
Sent: Monday, January 23, 2006 4:13 PM
Subject: svn commit: r371566 - in /jakarta/commons/proper: attributes/trunk/
beanutils/trunk/ betwixt/trunk/ chain/trunk/ cli/trunk/ codec/trunk/
collections/trunk/ configuration/trunk/ daemon/trunk/ dbcp/trunk/
dbutils/trunk/ digester/trunk/ discovery/trunk/ e...




Author: bayard
Date: Mon Jan 23 08:12:55 2006
New Revision: 371566

URL: http://svn.apache.org/viewcvs?rev=371566view=rev
Log:
Adding doap files for each component for the projects.apache.org site





-
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: doap maven project descriptor [was Re: svn commit: r371566]

On 1/24/06, Martin van den Bemt [EMAIL PROTECTED] wrote:
 On general @ jakarta Henri mentioned that the BCEL version was generated from 
 the project.xml. I
 assume he did that with these doap files.
 I hope that Henri didn't mean generated by hand from the project.xml.
 It should be pretty easy to whip a plugin for maven 1 and 2.

snip/

Anyone interested can probably port make_doap.cgi that drives:

http://projects.apache.org/create.html

For now, I just intend to use that form since some information is not
in the POM.

-Rahul


 Mvgr,
 Martin

 Niall Pemberton wrote:
  Theres quite a bit of overlap between whats in maven's project.xml and whats
  in this doap format - seems a shame to have to have it in two places. Maybe
  a maven doap plugin would be a good idea?
 
  Niall
 
  - Original Message -
  From: [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Monday, January 23, 2006 4:13 PM
  Subject: svn commit: r371566 - in /jakarta/commons/proper: attributes/trunk/
  beanutils/trunk/ betwixt/trunk/ chain/trunk/ cli/trunk/ codec/trunk/
  collections/trunk/ configuration/trunk/ daemon/trunk/ dbcp/trunk/
  dbutils/trunk/ digester/trunk/ discovery/trunk/ e...
 
 
 
 Author: bayard
 Date: Mon Jan 23 08:12:55 2006
 New Revision: 371566
 
 URL: http://svn.apache.org/viewcvs?rev=371566view=rev
 Log:
 Adding doap files for each component for the projects.apache.org site
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues

2006-01-24 Thread Steve Cohen


Jose Juan Montiel wrote:

1.  Use the javax.net.ssl classes.  (Out of the question because of our
mandate to support 1.3)

2.  Do what Paul and Josejuan did - use the com.sun classes

3.  Maybe.  use the javax.net.ssl classes but document that if used with
JDK  1.4, jsse.jar must be on the classpath.



Hi, i'll use the second option, because if commons-net implements
SSL-FTPS under JDK 1.3, its necesary import JSSE, and if use JDK 1.4,
the source code, don't need any change.

When commons-net, upgrde to JDK 1.4, if want remove JSSE, the
modifications in source code will be simples. I'll do it :)

The 3º option it not possible, because, don't work under 1.3, although
import jsse.jar... need change the import in source code...

Its my opinion.

Thanks for all.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





Well if option 3 won't work, that changes things, but can you tell us 
how it fails?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372063 - /jakarta/commons/trunks-sandbox/pom.xml

2006-01-24 Thread brett

Author: brett
Date: Tue Jan 24 16:43:43 2006
New Revision: 372063

URL: http://svn.apache.org/viewcvs?rev=372063view=rev
Log:
note the correct build requirements

Modified:
jakarta/commons/trunks-sandbox/pom.xml

Modified: jakarta/commons/trunks-sandbox/pom.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/trunks-sandbox/pom.xml?rev=372063r1=372062r2=372063view=diff
==
--- jakarta/commons/trunks-sandbox/pom.xml (original)
+++ jakarta/commons/trunks-sandbox/pom.xml Tue Jan 24 16:43:43 2006
@@ -10,7 +10,7 @@
   urlhttp://jakarta.apache.org/commons/sandbox//url
   inceptionYear2001/inceptionYear
   prerequisites
-maven2.0.2-SNAPSHOT/maven
+maven2.0.2/maven
   /prerequisites
   ciManagement
 systemcontinuum/system
@@ -97,13 +97,7 @@
   /plugin
   plugin
 artifactIdmaven-site-plugin/artifactId
-executions
-  execution
-goals
-  goalattach-descriptor/goal
-/goals
-  /execution
-/executions
+version2.0-SNAPSHOT/version
   /plugin
 /plugins
   /build



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Which Maven / xdoc-plugin version to build component site?

2006-01-24 Thread Jörg Schaible

Hi folks,

which version of Maven and the xdoc-plugin is necessary to build the site of
a component? Building for commons-id, I just get:

== % ===
xdoc:jelly-transform:
[echo]
Generating /home/joehni/src/Jakarta/sandbox/id/target/docs/javadoc.html
from /home/joehni/src/Jakarta/sandbox/id/target/generated-xdocs/javadoc.xml
Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
java.lang.ClassNotFoundException:
org.apache.commons.jelly.tags.fmt.FmtTagLibrary
== % ===

Maven is 1.0.2
xdoc-plugin is 1.8

- Jörg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which Maven / xdoc-plugin version to build component site?

2006-01-24 Thread Martin Cooper

On 1/24/06, Jörg Schaible [EMAIL PROTECTED] wrote:

 Hi folks,

 which version of Maven and the xdoc-plugin is necessary to build the site
 of
 a component?


This file has the list of plugins and their versions:

https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/pluginUpdate.txt

Maven 1.0.2 is the base.

--
Martin Cooper


Building for commons-id, I just get:

 == % ===
 xdoc:jelly-transform:
 [echo]
 Generating /home/joehni/src/Jakarta/sandbox/id/target/docs/javadoc.html
 from
 /home/joehni/src/Jakarta/sandbox/id/target/generated-xdocs/javadoc.xml
 Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
 java.lang.ClassNotFoundException:
 org.apache.commons.jelly.tags.fmt.FmtTagLibrary
 == % ===

 Maven is 1.0.2
 xdoc-plugin is 1.8

 - Jörg



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which Maven / xdoc-plugin version to build component site?

On 1/24/06, Jörg Schaible [EMAIL PROTECTED] wrote:
 Hi folks,

 which version of Maven and the xdoc-plugin is necessary to build the site of
 a component? Building for commons-id, I just get:

 == % ===
 xdoc:jelly-transform:
[echo]
 Generating /home/joehni/src/Jakarta/sandbox/id/target/docs/javadoc.html
 from /home/joehni/src/Jakarta/sandbox/id/target/generated-xdocs/javadoc.xml
 Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
 java.lang.ClassNotFoundException:
 org.apache.commons.jelly.tags.fmt.FmtTagLibrary
 == % ===

 Maven is 1.0.2
snip/

Thats good.


 xdoc-plugin is 1.8
snap/

Try 1.9.2. Some folks have begun adding a specific version dependency
to the POM (marked site only).

http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/pluginUpdate.txt

This has become a popular question, need to put it on the wiki as
well. Maybe after dinner ...

-Rahul



 - Jörg

snip/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r372076 - /jakarta/commons/sandbox/id/trunk/project.xml

2006-01-24 Thread joehni

Author: joehni
Date: Tue Jan 24 17:44:46 2006
New Revision: 372076

URL: http://svn.apache.org/viewcvs?rev=372076view=rev
Log:
Use up-to-date xdoc-plugin.

Modified:
jakarta/commons/sandbox/id/trunk/project.xml

Modified: jakarta/commons/sandbox/id/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/project.xml?rev=372076r1=372075r2=372076view=diff
==
--- jakarta/commons/sandbox/id/trunk/project.xml (original)
+++ jakarta/commons/sandbox/id/trunk/project.xml Tue Jan 24 17:44:46 2006
@@ -164,6 +164,13 @@
   urlhttp://maven-plugins.sourceforge.net/maven-cobertura-plugin//url
   typeplugin/type
 /dependency
+dependency
+  groupIdmaven/groupId
+  artifactIdmaven-xdoc-plugin/artifactId
+  version1.9.2/version
+  urlhttp://maven.apache.org/maven-1.x/reference/plugins/xdoc//url
+  typeplugin/type
+/dependency
   /dependencies
 
   build



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which Maven / xdoc-plugin version to build component site?

2006-01-24 Thread Jörg Schaible

Thanks Martin and Rahul,

[snip]

http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/pluginUpdate.txt
 
 This has become a popular question, need to put it on the wiki as
 well. Maybe after dinner ...

I've added it to the project.xml of c-id, so it is available the next time
independently of the current installed plugins. Nevertheless the pointer is
good, I will look there next time first ;-)

- Jörg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which Maven / xdoc-plugin version to build component site?

2006-01-24 Thread Jörg Schaible

Jörg Schaible wrote:

 Hi folks,
 
 which version of Maven and the xdoc-plugin is necessary to build the site
 of a component? Building for commons-id, I just get:
 
 == % ===
 xdoc:jelly-transform:
 [echo]
 Generating /home/joehni/src/Jakarta/sandbox/id/target/docs/javadoc.html
 from
 /home/joehni/src/Jakarta/sandbox/id/target/generated-xdocs/javadoc.xml
 Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
 java.lang.ClassNotFoundException:
 org.apache.commons.jelly.tags.fmt.FmtTagLibrary == % ===
 
 Maven is 1.0.2
 xdoc-plugin is 1.8

OK, works with xdoc-1.9.2 ...

- Jörg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by RahulAkolkar

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

The comment on the change is:
s/Federation/Foundation/

--
  
  Promotion is basically a beauty contest. If the component can win enough 
votes and few enough people vote against it, then the component is promoted. 
But there is one thing that is most definitely required:
  
- * Compliance with Apache Software Federation policies. This means a full 
license at the top of every file. It means auditing the dependencies. It means 
ensuring the copyright date is correct on the licenses.
+ * Compliance with Apache Software Foundation policies. This means a full 
license at the top of every file. It means auditing the dependencies. It means 
ensuring the copyright date is correct on the licenses.
  
  There some points of etiqutte and a few criteria that (though they are not 
rules) often seem to influence the voting.
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of JakartaCommonsEtiquette by RahulAkolkar

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

The comment on the change is:
Unclear why this is on the etiquette page, will move it to the repository page

--
  
  A POLL is an unofficial decision thread. These are useful for gauging the 
general feeling of the broader user community. Again, preferences should be 
expressed in the usual fashion. In this case, there is no need to indicate 
non-binding (since none are!).
  
- 
- 
- = Other Useful Links =
- 
-  * http://jakarta.apache.org/site/source.html
- 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of UsingSVN by RahulAkolkar

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-commons/UsingSVN

The comment on the change is:
Adding link removed from etiquette page since it better fits in here IMO

--
   * http://svnbook.red-bean.com/
   * http://subversion.tigris.org/faq.html
   * http://www.apache.org/dev/version-control.html#https-svn
+  * http://jakarta.apache.org/site/source.html
+ 
  
  = Subversion client config =
  Add this to your subversion client configuration file:

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[wiki] Proposed changes

I'm proposing to move some content around on the Commons wiki.

Motivating factors are:

 * Discourage amorphous growth on one or two pages
 * Distribute content over already existing pages (some of which are
mostly abandoned)
 * Reduce the number of orphaned pages, aim for better wiki navigation

(... over time, not that I expect any of my changes to be revolutionary ;-)

If you don't like one or more of the changes below, reply with a -1
underneath the change. I will make all changes that do *not* receive a
-1 in a few days (Friday at the earliest).

1) Move articles and third party resources to this orphaned page:
http://wiki.apache.org/jakarta-commons/ArticlesAndTutorials

2) Create a DeveloperDocumentation page and move the related links
from the FrontPage to that one.

3) Create a menu/navigation bar on the top (currently it has three
entries). More entries will wrap in your browser, depending on your
resolution.

4) Lose the description for the links on top of the page, they should
do OK without it as well, and add them to (3). For example:
GettingInvolved has information for people interested in helping out
with commons development.
will just become a GettingInvolved link in the nav bar.

5) Add a FrequentlyAskedQuestions page for Commons as a whole (for
generic questions such as which why does my maven site fail)

Stephen-

Can we post your Javapolis pdf on the wiki? I remember someone suggesting it.

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which Maven / xdoc-plugin version to build component site?

2006-01-24 Thread Simon Kitching

On Tue, 2006-01-24 at 20:42 -0500, Rahul Akolkar wrote:
On 1/24/06, Jörg Schaible [EMAIL PROTECTED] wrote:
Hi folks,

which version of Maven and the xdoc-plugin is necessary to build the site of
a component? Building for commons-id, I just get:

== % ===
xdoc:jelly-transform:
[echo]
Generating /home/joehni/src/Jakarta/sandbox/id/target/docs/javadoc.html
from /home/joehni/src/Jakarta/sandbox/id/target/generated-xdocs/javadoc.xml
Could not find the class: org.apache.commons.jelly.tags.fmt.FmtTagLibrary
java.lang.ClassNotFoundException:
org.apache.commons.jelly.tags.fmt.FmtTagLibrary
== % ===

Maven is 1.0.2
snip/

Thats good.

xdoc-plugin is 1.8
snap/

Try 1.9.2. Some folks have begun adding a specific version dependency
to the POM (marked site only).

http://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk/pluginUpdate.txt

This has become a popular question, need to put it on the wiki as
well. Maybe after dinner ...

The current setup really sucks in my opinion.

Is it the commons-build stuff that requires this plugin version? If so,
why isn't the pom for commons-build declaring a reference on it? It's
ridiculous for each project to have to do so.

The link to the pluginUpdate stuff is not good also. The point of
these build tools is that they download the bits they need
automatically; having to explicitly install a bunch of plugins (of
versions that are undocumented in the thing being built) is like a leap
back into the last century.

Regards,

Simon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Which Maven / xdoc-plugin version to build component site?