date:20110817

Ted,

please just take your code and move IteratorEntry sparseIterator();
from RealVector to SparseRealvector. Look then at the compiler errors,
that are in most cases misuses of sparseIterator().

By the way most(all?) functions in CM return an array (dense)
impementation as return type.   

You mention the method isSparse in your posts - there is currently no
such method, if you want to detect, if you have a sparse implementation
you will have to check for SparseRealvector. So there is no big deal in
a following cast to SparseRealVector to access sparseIterator(). 

As I am no math guru, I cant follow your example, some real code
probaply will do the trick.

Arne

Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: 
 Here is an example from the perspective of somebody adding a new kind of
 matrix.
 
 Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that
 has elements that are -1, 0 or 1.  1 and -1 have equal probabilities of p/2.
  The value of p should be in [0,1].
 
 It would be very nice if the implementor of this matrix could extend an
 abstract matrix and over-ride get() to generate a value and set() to throw
 an unsupported operation exception.  If p  0.1, then the matrix should be
 marked as sparse, else as dense.
 
 All operations against other matrices, sparse or dense should work well
 without any special handling by the implementor of this matrix.
 
 This works in Mahout for instance by having the default operations in
 AbstractMatrix test for sparseness of left or right operands and do the
 right thing.  Obviously, a type test will not tell you whether this matrix
 is sparse or not.
 
 This matrix and siblings is very important in compressed sensing and
 stochastic projection algorithms.
 
 On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote:
 
  On 8/16/11 4:46 AM, Gilles Sadowski wrote:
   Hi.
  
   I understood what he was suggesting.  I still disagree.  Dynamic
  dispatch
   and non-lattice typing structure is still required to make this all
  work.
Java doesn't really do that.  Pretending that what Java does is
  sufficient
   is hammer-looking-for-a-nail, not solving the problems at hand.
   Maybe that *I* don't understand what you are hinting at. Sorry for being
   dense. [Although that seems appropriate in this discussion :-).]
  
   Polymorphism provides dynamic dispatch, overloading does not; that's why
  my
   proposition is that when you manipulate unknown types, those should
  come
   as this, not as the argument of the method.
  
   What's wrong with that?
  
   As for hammer-looking-for-a-nail, I also don't see what you mean: What
  is
   the problem? I guess that there are lots of applications who never need
  to
   know about sparse vectors/matrices. In those cases, the added complexity
  is
   not a feature. The issue reported contends that the current design in
  CM
   can cause problems for dense implementations. I'm not even sure that the
   current design is usable for the type of applications that make heavy use
  of
   sparseness. Those are problems, IMHO.
 
  I have been out of pocket the last couple of days and may not have
  time to dig into this until late tonight, but I agree with Gilles
  that we need to get the conversation here more concrete.  I know we
  discussed this before and Ted and others had good examples
  justifying the current setup.  Can we revisit these, please?   What
  would be great would be some examples both from the perspective of
  the [math] developer looking to add a new or specialized class and
  [math] users writing code that leverages the setup.
 
  Phil
  
  
   Gilles
  
   On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski 
  gsterijev...@gmail.comwrote:
  
   Forgive me for pushing my nose under the tent... I couldn't resist.
  
   I think Gilles is saying that each specialization of the matrix/vector
   objects would need to support pre (and post) multiplication with a
  dense.
   So
   the type issue would not be problematic.
  
   On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning ted.dunn...@gmail.com
   wrote:
  
   No.
  
   You can't.  This is because the type is lost as you enter the generic
   library.
  
   On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski 
   gil...@harfang.homelinux.org wrote:
  
   They know that their own object is dense, but they don't know what
   kind
   of
   input they were given.  They should still run fast if the input is
   sparse.
  
   Couldn't we still rely on polymorphism by implementing preTimes:
 unknown.preTimes(dense)
   -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] iterator and sparseIterator in RealVector hierarchy

Currently sparseIterator is only used in RealVector, no matrix class
will be affected, because there is no sparseIterator.
Search you sources for sparseIterator ?

Arne
Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: 
 Here is an example from the perspective of somebody adding a new kind of
 matrix.
 
 Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that
 has elements that are -1, 0 or 1.  1 and -1 have equal probabilities of p/2.
  The value of p should be in [0,1].
 
 It would be very nice if the implementor of this matrix could extend an
 abstract matrix and over-ride get() to generate a value and set() to throw
 an unsupported operation exception.  If p  0.1, then the matrix should be
 marked as sparse, else as dense.
 
 All operations against other matrices, sparse or dense should work well
 without any special handling by the implementor of this matrix.
 
 This works in Mahout for instance by having the default operations in
 AbstractMatrix test for sparseness of left or right operands and do the
 right thing.  Obviously, a type test will not tell you whether this matrix
 is sparse or not.
 
 This matrix and siblings is very important in compressed sensing and
 stochastic projection algorithms.
 
 On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote:
 
  On 8/16/11 4:46 AM, Gilles Sadowski wrote:
   Hi.
  
   I understood what he was suggesting.  I still disagree.  Dynamic
  dispatch
   and non-lattice typing structure is still required to make this all
  work.
Java doesn't really do that.  Pretending that what Java does is
  sufficient
   is hammer-looking-for-a-nail, not solving the problems at hand.
   Maybe that *I* don't understand what you are hinting at. Sorry for being
   dense. [Although that seems appropriate in this discussion :-).]
  
   Polymorphism provides dynamic dispatch, overloading does not; that's why
  my
   proposition is that when you manipulate unknown types, those should
  come
   as this, not as the argument of the method.
  
   What's wrong with that?
  
   As for hammer-looking-for-a-nail, I also don't see what you mean: What
  is
   the problem? I guess that there are lots of applications who never need
  to
   know about sparse vectors/matrices. In those cases, the added complexity
  is
   not a feature. The issue reported contends that the current design in
  CM
   can cause problems for dense implementations. I'm not even sure that the
   current design is usable for the type of applications that make heavy use
  of
   sparseness. Those are problems, IMHO.
 
  I have been out of pocket the last couple of days and may not have
  time to dig into this until late tonight, but I agree with Gilles
  that we need to get the conversation here more concrete.  I know we
  discussed this before and Ted and others had good examples
  justifying the current setup.  Can we revisit these, please?   What
  would be great would be some examples both from the perspective of
  the [math] developer looking to add a new or specialized class and
  [math] users writing code that leverages the setup.
 
  Phil
  
  
   Gilles
  
   On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski 
  gsterijev...@gmail.comwrote:
  
   Forgive me for pushing my nose under the tent... I couldn't resist.
  
   I think Gilles is saying that each specialization of the matrix/vector
   objects would need to support pre (and post) multiplication with a
  dense.
   So
   the type issue would not be problematic.
  
   On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning ted.dunn...@gmail.com
   wrote:
  
   No.
  
   You can't.  This is because the type is lost as you enter the generic
   library.
  
   On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski 
   gil...@harfang.homelinux.org wrote:
  
   They know that their own object is dense, but they don't know what
   kind
   of
   input they were given.  They should still run fast if the input is
   sparse.
  
   Couldn't we still rely on polymorphism by implementing preTimes:
 unknown.preTimes(dense)
   -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-javaflow (in module commons-sandbox) failed

2011-08-17 Thread Gump

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 gene...@gump.apache.org.

Project commons-javaflow has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-javaflow :  Commons Javaflow


Full details are available at:

http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-javaflow-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/commons-sandbox/javaflow/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/commons-sandbox/javaflow/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/commons-sandbox/javaflow/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/commons-sandbox/javaflow/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/gump_work/build_commons-sandbox_commons-javaflow.html
Work Name: build_commons-sandbox_commons-javaflow (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/commons-sandbox/javaflow/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/commons-sandbox/javaflow]
M2_HOME: /opt/maven2
-
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Commons Javaflow (Sandbox)
[INFO]task-segment: [package]
[INFO] 
Downloading: 
http://localhost:8192/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.pom

Downloading: http://localhost:8192/maven2/asm/asm-util/3.2/asm-util-3.2.pom

Downloading: 
http://localhost:8192/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.jar
17K downloaded  (asm-analysis-3.2.jar)
Downloading: http://localhost:8192/maven2/asm/asm-util/3.2/asm-util-3.2.jar
34K downloaded  (asm-util-3.2.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
 [copy] Copying 2 files to 
/srv/gump/public/workspace/commons-sandbox/javaflow/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] Setting property: classpath.resource.loader.class = 
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 35 source files to 
/srv/gump/public/workspace/commons-sandbox/javaflow/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/commons-sandbox/javaflow/src/main/java/org/apache/commons/javaflow/bytecode/transformation/bcel/analyser/ExecutionVisitor.java:[57,62]
 org.apache.bcel.generic.Visitor is not public in org.apache.bcel.generic; 
cannot be accessed from outside package

[INFO] 1error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/commons-sandbox/javaflow/src/main/java/org/apache/commons/javaflow/bytecode/transformation/bcel/analyser/ExecutionVisitor.java:[57,62]
 org.apache.bcel.generic.Visitor is not public in org.apache.bcel.generic; 
cannot be accessed from outside package


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Wed Aug 17 10:56:30 UTC 2011
[INFO] Final Memory: 22M/58M
[INFO]

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

2011-08-17 Thread Gump

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 gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 42 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

Tests run: 179, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Wed Aug 17 10:57:56 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml
- Atom:

Re: [Math] iterator and sparseIterator in RealVector hierarchy

2011-08-17 Thread Gilles Sadowski

On Tue, Aug 16, 2011 at 02:09:03PM -0700, Ted Dunning wrote:
 Here is an example from the perspective of somebody adding a new kind of
 matrix.
 
 Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that
 has elements that are -1, 0 or 1.  1 and -1 have equal probabilities of p/2.
  The value of p should be in [0,1].
 
 It would be very nice if the implementor of this matrix could extend an
 abstract matrix and over-ride get() to generate a value and set() to throw
 an unsupported operation exception. 

Do you mean that the matrix is stateless (each call to get generates a new
value)?

 If p  0.1, then the matrix should be
 marked as sparse, else as dense.
 
 All operations against other matrices, sparse or dense should work well
 without any special handling by the implementor of this matrix.
 
 This works in Mahout for instance by having the default operations in
 AbstractMatrix test for sparseness of left or right operands and do the
 right thing.  Obviously, a type test will not tell you whether this matrix
 is sparse or not.

As far as I understand, the sparseness test is an indicator that there is an
optimized way to iterate over the entries (faster than a loop over all the
indices) or that not all entries are explicitly stored. Is that correct?

If so, this is tied to the layout of the matrix, i.e. the type (which
can change depending on an input value, such as p above).

However, once it is created, its type/implementation is either dense or
sparse.

 [...]

I'm wondering whether this leads again to the issue of CM being a framework
for everyone to build on, or if its data structures are mostly intended for
internal use, so that the algorithms it provides are most efficient.


Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1158504 - /commons/trunks-proper/

On 17 August 2011 05:38, Stefan Bodewig bode...@apache.org wrote:
 On 2011-08-17, bay...@apache.org wrote:

 Propchange: commons/trunks-proper/
 --
 --- svn:externals (original)
 +++ svn:externals Wed Aug 17 04:25:55 2011
 @@ -2,6 +2,7 @@ attributes https://svn.apache.org/repos/
  bcel https://svn.apache.org/repos/asf/commons/proper/bcel/trunk
  beanutils https://svn.apache.org/repos/asf/commons/proper/beanutils/trunk
  betwixt https://svn.apache.org/repos/asf/commons/proper/betwixt/trunk
+ bsf https://svn.apache.org/repos/asf/commons/proper/bsf/trunk
  chain https://svn.apache.org/repos/asf/commons/proper/chain/trunk
  cli https://svn.apache.org/repos/asf/commons/proper/cli/trunk
  codec https://svn.apache.org/repos/asf/commons/proper/codec/trunk

 Note that BSF's trunk is the 2.x codebase while 3.x where the latest
 releases have come from lives in a branch.

 I'm not sure which one should be considered the trunk in the Commons
 sense of trunks-proper in this case.  Not sure what the BSF devs feel is
 correct either.

I did it this way round because the site is still in trunk; this was
the arrangement that seemed to cause least upheaval at the time.

As it happens, the changes proposed by Rony will be in 2.x, i.e.
trunk; the 3.x branch I think is stable.

I'm not sure it matters too much either way.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] close() and archives/streams in an invalid state

On 17 August 2011 06:18, Stefan Bodewig bode...@apache.org wrote:
 On 2011-08-17, sebb wrote:

 On 17 August 2011 03:42, Stefan Bodewig bode...@apache.org wrote:
 On 2011-08-15, sebb wrote:

 For input, there might be a use case for leaving the stream open, in
 case some kind of recovery is possible.

 It would be useful to have a way of determining the input file pointer
 at the point of failure.

 stream.getBytesRead() or are you thinking about anything else?

 That would be fine.

 I'm not sure whether we need to do anything for that.  The streams
 already count the bytes and you can access it when an exception occurs.
 We might want to revisit the exception messages whether they can include
 some sort of byte count.

 For normal users of compress I don't expect that information to be too
 useful, though.  Most users won't be familiar with the details of the
 format.  It may be useful for us during debugging or when bugs get
 reported.

Yes, that was my main concern.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] close() and archives/streams in an invalid state

2011-08-17 Thread Stefan Bodewig

On 2011-08-17, Honton, Charles wrote:

 Why guard against closing System.in?  If the client application needs that
 sort of functionality, it should wrap the incoming stream in a proxy that
 doesn't delegate the close method to the underlying stream.

You and I agree here - there even has been a thread about this not too
long ago.  Changing it would break backwards compatibility, though,
something we are willing to do in a 2.x release not too far away in the
future (I hope).  For 1.x we prefer to keep it as it is.

 (A new class for commons-io?)

I'm pretty sure that already exists.  CloseShieldInputStream IIRC.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] Encoder / Decoder interface

2011-08-17 Thread Matthew Pocock

Hi,

Before I start, I'd love to see a binary compatible codec release with the
Beider Morse code in, and for generics to be dealt with in a later release.
What I'm not quite sure about is why introducing generics will necessarily
cause breaking changes.

It seems to me that the Encoder/Decoder interfaces are screaming out to be
generified, and the current sub-interfaces should be removed unless there's
a compelling reason for them e.g. if they add extra methods. It is no
hardship in your code to write EncoderString, String rather than
StringEncoder. I realise that in any one application it may be the case that
they use only one family of encoders (e.g. String = String), but I don't
see why this means we should be introducing a Java interface explicitly for
this use case.

We could have StringEncoder extends EncoderString, String if we wished.
The problem with this is that not every EncoderString, String is a
StringEncoder. It isn't a type alias. By introducing an extra interface,
we're introducing an extra layer of contract. Right now StringEncoder does
introduce an extra contract - it provides an over-loaded encode method
specialised to String, and it is possible for implementations to do
different work in the two different methods.

In the specific case of the BeiderMorse encoder, the natural sig is
EncoderString, SetString. I expect this is the case for some other
StringEncoder implementations that deal with phonetic encodings. Would we
then introduce yet another interface, FuzzyStringEncoder to capture this?
All seems a bit messy to me.

Java does not allow you to implement the same interface with different
generic type arguments. So, you can't have Foo implements EncoderObject,
Object, EncoderString, String. Because of this, you can't provide
different behaviour for the two different cases. This is sort of what the
current situation requires. However, look at what javap says has been
generated in these scenarios.

## java
public interface EncoderENC, DEC {
  public ENC encode(DEC dec);
}

## javap
public interface Encoder{

public abstract java.lang.Object encode(java.lang.Object);

}

## java
public interface StringEncoder extends EncoderString, String {}

## javap
public interface StringEncoder extends Encoder{

}

## java
public class IdE implements EncoderString, String {
  public String encode(String in) {
return in;
  }
}

## javap

public class IdE extends java.lang.Object implements Encoder{
public IdE();
public java.lang.String encode(java.lang.String);
public java.lang.Object encode(java.lang.Object);
}

## java
public class IdSe implements StringEncoder {
  public String encode(String in) {
return in;
  }
}

## javap
public class IdSe extends java.lang.Object implements StringEncoder{

public IdSe();

public java.lang.String encode(java.lang.String);

public java.lang.Object encode(java.lang.Object);

}


## java
public interface StringEncoder2 extends EncoderString, String {
  @Override
  public String encode(String in);
}

## javap
public interface StringEncoder2 extends Encoder{
public abstract java.lang.String encode(java.lang.String);
}

## java
public class IdSe2 implements StringEncoder2 {
  public String encode(String in) {
return in;
  }
}

## javap
public class IdSe2 extends java.lang.Object implements StringEncoder2{
public IdSe2();
public java.lang.String encode(java.lang.String);
public java.lang.Object encode(java.lang.Object);
}

So, I guess I'm wondering what the breaking changes are that definitely get
introduced by generification, and if there are a significant number that
can't be dealt with by a bit of judicious use of deprecation and deprecated
interfaces.

Matthew

On 17 August 2011 06:24, Gary Gregory garydgreg...@gmail.com wrote:

 On Aug 16, 2011, at 23:47, sebb seb...@gmail.com wrote:

  On 17 August 2011 04:30, Gary Gregory garydgreg...@gmail.com wrote:
  On Tue, Aug 16, 2011 at 11:14 PM, sebb seb...@gmail.com wrote:
 
  ...
 
  FYI:
 
  What would need to be reversed out of trunk for a 1.6 binary compatible
 with
  1.5 is:
 
  [image: Error]Method 'public StringEncoderComparator()' has been removed
  org.apache.commons.codec.StringEncoderComparatorpublic
  StringEncoderComparator()[image: Error]Method 'public boolean
  isArrayByteBase64(byte[])' has been removed
  org.apache.commons.codec.binary.Base64public boolean
  isArrayByteBase64(byte[])[image: Error]Class
  org.apache.commons.codec.language.Caverphone removed
  org.apache.commons.codec.language.Caverphone
  [image: Error]Method 'public int getMaxLength()' has been removed
  org.apache.commons.codec.language.Soundexpublic int
 getMaxLength()[image:
  Error]Method 'public void setMaxLength(int)' has been removed
  org.apache.commons.codec.language.Soundexpublic void
 setMaxLength(int)[image:
  Error]Field charset is now
  finalorg.apache.commons.codec.net.URLCodeccharset[image:
  Error]Method 'public java.lang.String getEncoding()' has been removed

Re: [VOTE][DAEMON] release 1.0.6 and 1.0.7 Maven artifacts

2011-08-17 Thread Luc Maisonobe


Le 15/08/2011 20:03, sebb a écrit :

Just in case anyone wants to use Maven to download the Java part of
Commons Daemon (this has been requested in the past), I thought it
would be useful to create and upload the Maven artifacts to the Nexus
staging repo.

The uploads contain source, so although the main release votes have
already passed, it seems sensible to vote again on the actual Maven
artifacts.


I am not sure about this. What we release is mainly source code, and 
binaries are a convenience but seems to me less official. Also voting 
separately for the binaries as an afterthought is uncomfortable. Of 
course I do trust you to have built these artifacts properly, but how 
can I really be sure they correspond to the same source code we voted 
upon a few days ago ?


Please, don't consider it as offending, I am just wondering about a 
process I don't master.


Luc



Daemon 1.0.6
==
Staging area:
https://repository.apache.org/content/repositories/orgapachecommons-040/commons-daemon/commons-daemon/

which was built from the tag
https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_6
(r1144188)
using mvn clean; mvn deploy -Prelease

[ ]+1 OK to release
[ ]-1 do not release, please give a reason why

Daemon 1.0.7
==
Staging area
https://repository.apache.org/content/repositories/orgapachecommons-041/commons-daemon/commons-daemon/

which was built from the tag
https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_7
(r1153351)
using mvn clean; mvn deploy -Prelease

[ ]+1 OK to release
[ ]-1 do not release, please give a reason why

Voting will remain open for the usual minimum of 72 hours.

Thanks!

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] Encoder / Decoder interface

2011-08-17 Thread Stephen Colebourne

On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote:
 It seems to me that the Encoder/Decoder interfaces are screaming out to be
 generified, and the current sub-interfaces should be removed unless there's
 a compelling reason for them e.g. if they add extra methods. It is no
 hardship in your code to write EncoderString, String rather than
 StringEncoder. I realise that in any one application it may be the case that
 they use only one family of encoders (e.g. String = String), but I don't
 see why this means we should be introducing a Java interface explicitly for
 this use case.

I prefer StringEncoder to EncoderString, String. Its shorter and clearer.
Overall, I'd say focus users on the concrete versions like StringEncoder.

On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote:
 I am not a fan of these interfaces because they are not typed, Object
 encode(Object) is too vague now that Generics have been an option for
 years.

The Object encode(Object) approach is still valid if the primary use
case of the interface is for frameworks. In a framework, objects are
generally treated as of type Object, so the API is fine. User code
should use concrete versions.

Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] Encoder / Decoder interface

2011-08-17 Thread Matthew Pocock

On 17 August 2011 13:58, Stephen Colebourne scolebou...@joda.org wrote:

 The Object encode(Object) approach is still valid if the primary use
 case of the interface is for frameworks. In a framework, objects are
 generally treated as of type Object, so the API is fine. User code
 should use concrete versions.


In the case of ENC encode(DEC), the framework sees Object encode(Object), as
this is the erased type. The framework is happy and Java code referring to
the Encoder interface (directly or indirectly) is type-safe (baring casts
which we can't do much about).

Matthew



 Stephen

 --
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhams...@gmail.com
gchat: turingatemyhams...@gmail.com
msn: matthew_poc...@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143

Re: [VOTE][DAEMON] release 1.0.6 and 1.0.7 Maven artifacts

On 17 August 2011 13:50, Luc Maisonobe luc.maison...@free.fr wrote:
 Le 15/08/2011 20:03, sebb a écrit :

 Just in case anyone wants to use Maven to download the Java part of
 Commons Daemon (this has been requested in the past), I thought it
 would be useful to create and upload the Maven artifacts to the Nexus
 staging repo.

 The uploads contain source, so although the main release votes have
 already passed, it seems sensible to vote again on the actual Maven
 artifacts.

 I am not sure about this. What we release is mainly source code, and
 binaries are a convenience but seems to me less official. Also voting
 separately for the binaries as an afterthought is uncomfortable. Of course I
 do trust you to have built these artifacts properly, but how can I really be
 sure they correspond to the same source code we voted upon a few days ago ?

They were built from the same tags (listed below), which you can
compare against the source jar.

 Please, don't consider it as offending, I am just wondering about a process
 I don't master.

Not sure I understand how this is different from the previous Daemon
votes, apart from the fact that the source/binary jars only relate to
the Java subset of the original vote.

It's still possible to check the artifact contents, sigs, hashes, and
it's still possible to check that the source jar only contains source
from the tag.

 Luc


 Daemon 1.0.6
 ==
 Staging area:

 https://repository.apache.org/content/repositories/orgapachecommons-040/commons-daemon/commons-daemon/

 which was built from the tag

 https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_6
 (r1144188)
 using mvn clean; mvn deploy -Prelease

 [ ]+1 OK to release
 [ ]-1 do not release, please give a reason why

 Daemon 1.0.7
 ==
 Staging area

 https://repository.apache.org/content/repositories/orgapachecommons-041/commons-daemon/commons-daemon/

 which was built from the tag

 https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_7
 (r1153351)
 using mvn clean; mvn deploy -Prelease

 [ ]+1 OK to release
 [ ]-1 do not release, please give a reason why

 Voting will remain open for the usual minimum of 72 hours.

 Thanks!

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [codec] Encoder / Decoder interface

Hi Matthew,

On Wed, Aug 17, 2011 at 8:44 AM, Matthew Pocock 
turingatemyhams...@gmail.com wrote:

 Hi,

 Before I start, I'd love to see a binary compatible codec release with the
 Beider Morse code in, and for generics to be dealt with in a later release.


I think this is where we are going, see previous emails and threads.


 What I'm not quite sure about is why introducing generics will necessarily
 cause breaking changes.


I can break things depending on the new design... we'll have to all discuss.
See the branch in SVN for my first cut.
https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics


 It seems to me that the Encoder/Decoder interfaces are screaming out to be
 generified,


Yes! :)


 and the current sub-interfaces should be removed unless there's
 a compelling reason for them e.g. if they add extra methods. It is no
 hardship in your code to write EncoderString, String rather than
 StringEncoder. I realise that in any one application it may be the case
 that
 they use only one family of encoders (e.g. String = String), but I don't
 see why this means we should be introducing a Java interface explicitly for
 this use case.


I had not thought about it that way and I do like the idea since there are
no new methods there.

If you look at the branch I have:

interface EncoderI,O with O encode(I) and
interface SymmerticEncoderT extends EncoderT, T
interface StringEncoder extends SymmerticEncoderString

I could see doing away with StringEncoder. This would hopelessly break
compatibility but I like it because it uses generics in the most natural way
IMO.


 We could have StringEncoder extends EncoderString, String if we wished.
 The problem with this is that not every EncoderString, String is a
 StringEncoder. It isn't a type alias. By introducing an extra interface,
 we're introducing an extra layer of contract. Right now StringEncoder does
 introduce an extra contract - it provides an over-loaded encode method
 specialised to String, and it is possible for implementations to do
 different work in the two different methods.

 In the specific case of the BeiderMorse encoder, the natural sig is
 EncoderString, SetString. I expect this is the case for some other
 StringEncoder implementations that deal with phonetic encodings. Would we
 then introduce yet another interface, FuzzyStringEncoder to capture this?


I hope not!


 All seems a bit messy to me.

 Java does not allow you to implement the same interface with different
 generic type arguments. So, you can't have Foo implements EncoderObject,
 Object, EncoderString, String.


Yep, that's the only problem I ran into when adding generics to the branch


 Because of this, you can't provide
 different behaviour for the two different cases. This is sort of what the
 current situation requires. However, look at what javap says has been
 generated in these scenarios.


AH, it looks like you decompiled the branch ;)

Gary



 ## java
 public interface EncoderENC, DEC {
  public ENC encode(DEC dec);
 }

 ## javap
 public interface Encoder{

public abstract java.lang.Object encode(java.lang.Object);

 }

 ## java
 public interface StringEncoder extends EncoderString, String {}

 ## javap
 public interface StringEncoder extends Encoder{

 }

 ## java
 public class IdE implements EncoderString, String {
  public String encode(String in) {
return in;
  }
 }

 ## javap

 public class IdE extends java.lang.Object implements Encoder{
public IdE();
public java.lang.String encode(java.lang.String);
public java.lang.Object encode(java.lang.Object);
 }

 ## java
 public class IdSe implements StringEncoder {
  public String encode(String in) {
return in;
  }
 }

 ## javap
 public class IdSe extends java.lang.Object implements StringEncoder{

public IdSe();

public java.lang.String encode(java.lang.String);

public java.lang.Object encode(java.lang.Object);

 }


 ## java
 public interface StringEncoder2 extends EncoderString, String {
  @Override
  public String encode(String in);
 }

 ## javap
 public interface StringEncoder2 extends Encoder{
public abstract java.lang.String encode(java.lang.String);
 }

 ## java
 public class IdSe2 implements StringEncoder2 {
  public String encode(String in) {
return in;
  }
 }

 ## javap
 public class IdSe2 extends java.lang.Object implements StringEncoder2{
public IdSe2();
public java.lang.String encode(java.lang.String);
public java.lang.Object encode(java.lang.Object);
 }

 So, I guess I'm wondering what the breaking changes are that definitely get
 introduced by generification, and if there are a significant number that
 can't be dealt with by a bit of judicious use of deprecation and deprecated
 interfaces.

 Matthew

 On 17 August 2011 06:24, Gary Gregory garydgreg...@gmail.com wrote:

  On Aug 16, 2011, at 23:47, sebb seb...@gmail.com wrote:
 
   On 17 August 2011 04:30, Gary Gregory garydgreg...@gmail.com wrote:
   On Tue, Aug 16, 2011 at 11:14

Re: [codec] Encoder / Decoder interface

Hi All:

On Wed, Aug 17, 2011 at 8:58 AM, Stephen Colebourne scolebou...@joda.orgwrote:

 On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com
 wrote:
  It seems to me that the Encoder/Decoder interfaces are screaming out to
 be
  generified, and the current sub-interfaces should be removed unless
 there's
  a compelling reason for them e.g. if they add extra methods. It is no
  hardship in your code to write EncoderString, String rather than
  StringEncoder. I realise that in any one application it may be the case
 that
  they use only one family of encoders (e.g. String = String), but I don't
  see why this means we should be introducing a Java interface explicitly
 for
  this use case.

 I prefer StringEncoder to EncoderString, String. Its shorter and clearer.


What about SymmetricEncoderString?

[Leaving aside bin compat for this chat...]

I'm not sure I buy the argument for keeping StringEncoder in a generified
codec2/3.

For example, Strings are very common if not the most common kind of List but
there is no java.util.StringList and so on.

Overall, I'd say focus users on the concrete versions like StringEncoder.

 On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote:
  I am not a fan of these interfaces because they are not typed, Object
  encode(Object) is too vague now that Generics have been an option for
  years.

 The Object encode(Object) approach is still valid if the primary use
 case of the interface is for frameworks. In a framework, objects are
 generally treated as of type Object, so the API is fine. User code
 should use concrete versions.


 With a generics codec, a f/w can still use Object, it has to downcast but
it is possible/ugly.

Cheers!
Gary


 Stephen

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [codec] Encoder / Decoder interface

On 17 August 2011 13:58, Stephen Colebourne scolebou...@joda.org wrote:
 On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote:
 It seems to me that the Encoder/Decoder interfaces are screaming out to be
 generified, and the current sub-interfaces should be removed unless there's
 a compelling reason for them e.g. if they add extra methods. It is no
 hardship in your code to write EncoderString, String rather than
 StringEncoder. I realise that in any one application it may be the case that
 they use only one family of encoders (e.g. String = String), but I don't
 see why this means we should be introducing a Java interface explicitly for
 this use case.

 I prefer StringEncoder to EncoderString, String. Its shorter and clearer.
 Overall, I'd say focus users on the concrete versions like StringEncoder.

If StringEncoder is a non-generic interface it also makes it possible
to combine interfaces in classes, as is done currently.

Not sure this is possible with all-generic interfaces.

 On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote:
 I am not a fan of these interfaces because they are not typed, Object
 encode(Object) is too vague now that Generics have been an option for
 years.

 The Object encode(Object) approach is still valid if the primary use
 case of the interface is for frameworks. In a framework, objects are
 generally treated as of type Object, so the API is fine. User code

That's useful to know (I've not used frameworks)

 should use concrete versions.

+1

 Stephen

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[continuum] BUILD FAILURE: Apache Commons - Commons Compress - Default Maven 2 Build Definition (Java 1.5)

2011-08-17 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11377projectId=64

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed 17 Aug 2011 14:22:43 +
  Finished at: Wed 17 Aug 2011 14:23:04 +
  Total time: 21s
  Build Trigger: Schedule
  Build Number: 92
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version 1.6.0_24
  Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
  Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_24
  Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
  Default locale: en_AU, platform encoding: UTF-8
  OS name: linux version: 2.6.32-31-server arch: amd64 Family: 
unix


SCM Changes:

Changed: bodewig @ Wed 17 Aug 2011 14:07:12 +
Comment: make extraction tests pass for dump.  COMPRESS-132
Files changed:
  
/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveEntry.java
 ( 1158723 )
  
/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveInputStream.java
 ( 1158723 )
  
/commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/DumpTestCase.java
 ( 1158723 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 228
Failures: 2
Errors: 0
Success Rate: 99
Total time: 1.2810001


Test Failures:


DumpTestCase
testCheckArchive :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError: extraction failed: .
at junit.framework.Assert.fail(Assert.java:47)
at 
org.apache.commons.compress.AbstractTestCase.checkArchiveContent(AbstractTestCase.java:341)
at 
org.apache.commons.compress.AbstractTestCase.checkArchiveContent(AbstractTestCase.java:301)
at 
org.apache.commons.compress.archivers.DumpTestCase.checkDumpArchive(DumpTestCase.java:113)
at 
org.apache.commons.compress.archivers.DumpTestCase.testCheckArchive(DumpTestCase.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at

Re: [Math] iterator and sparseIterator in RealVector hierarchy

On Wed, Aug 17, 2011 at 4:44 AM, Gilles Sadowski 
gil...@harfang.homelinux.org wrote:

  It would be very nice if the implementor of this matrix could extend an
  abstract matrix and over-ride get() to generate a value and set() to
 throw
  an unsupported operation exception.

 Do you mean that the matrix is stateless (each call to get generates a
 new
 value)?


Yes.  And I would also typically expect it to be immutable although changing
p is a reasonable thing to do (I just prefer immutable objects where
practical).



  If p  0.1, then the matrix should be
  marked as sparse, else as dense.
 
  All operations against other matrices, sparse or dense should work well
  without any special handling by the implementor of this matrix.
 
  This works in Mahout for instance by having the default operations in
  AbstractMatrix test for sparseness of left or right operands and do the
  right thing.  Obviously, a type test will not tell you whether this
 matrix
  is sparse or not.

 As far as I understand, the sparseness test is an indicator that there is
 an
 optimized way to iterate over the entries (faster than a loop over all the
 indices) or that not all entries are explicitly stored. Is that correct?


Yes.


 If so, this is tied to the layout of the matrix, i.e. the type (which
 can change depending on an input value, such as p above).


Yes.


 However, once it is created, its type/implementation is either dense or
 sparse.


It depends on whether setP() is supported.  If the setter is there, then
density can even change after construction.



  [...]

 I'm wondering whether this leads again to the issue of CM being a framework
 for everyone to build on, or if its data structures are mostly intended for
 internal use, so that the algorithms it provides are most efficient.


Well, it *is* open source (so they say).

That kind of indicates that it should be relatively easy for people to
provide code.

Also, I find that even the idea of this dichotomy is a bit of a mirage.
 Providing a good extensible design often gives faster code down the way a
bit.

Re: [Math] iterator and sparseIterator in RealVector hierarchy

Arne,

Please read the thread again.  I am providing an example of how I think
things *should* be.

The point of doing so is that things are not that way now.  Telling me that
they are not that way is pretty redundant.

On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote:

 Currently sparseIterator is only used in RealVector, no matrix class
 will be affected, because there is no sparseIterator.
 Search you sources for sparseIterator ?

 Arne
 Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning:
  Here is an example from the perspective of somebody adding a new kind of
  matrix.
 
  Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p)
 that
  has elements that are -1, 0 or 1.  1 and -1 have equal probabilities of
 p/2.
   The value of p should be in [0,1].
 
  It would be very nice if the implementor of this matrix could extend an
  abstract matrix and over-ride get() to generate a value and set() to
 throw
  an unsupported operation exception.  If p  0.1, then the matrix should
 be
  marked as sparse, else as dense.
 
  All operations against other matrices, sparse or dense should work well
  without any special handling by the implementor of this matrix.
 
  This works in Mahout for instance by having the default operations in
  AbstractMatrix test for sparseness of left or right operands and do the
  right thing.  Obviously, a type test will not tell you whether this
 matrix
  is sparse or not.
 
  This matrix and siblings is very important in compressed sensing and
  stochastic projection algorithms.
 
  On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com
 wrote:
 
   On 8/16/11 4:46 AM, Gilles Sadowski wrote:
Hi.
   
I understood what he was suggesting.  I still disagree.  Dynamic
   dispatch
and non-lattice typing structure is still required to make this all
   work.
 Java doesn't really do that.  Pretending that what Java does is
   sufficient
is hammer-looking-for-a-nail, not solving the problems at hand.
Maybe that *I* don't understand what you are hinting at. Sorry for
 being
dense. [Although that seems appropriate in this discussion :-).]
   
Polymorphism provides dynamic dispatch, overloading does not; that's
 why
   my
proposition is that when you manipulate unknown types, those should
   come
as this, not as the argument of the method.
   
What's wrong with that?
   
As for hammer-looking-for-a-nail, I also don't see what you mean:
 What
   is
the problem? I guess that there are lots of applications who never
 need
   to
know about sparse vectors/matrices. In those cases, the added
 complexity
   is
not a feature. The issue reported contends that the current design
 in
   CM
can cause problems for dense implementations. I'm not even sure that
 the
current design is usable for the type of applications that make heavy
 use
   of
sparseness. Those are problems, IMHO.
  
   I have been out of pocket the last couple of days and may not have
   time to dig into this until late tonight, but I agree with Gilles
   that we need to get the conversation here more concrete.  I know we
   discussed this before and Ted and others had good examples
   justifying the current setup.  Can we revisit these, please?   What
   would be great would be some examples both from the perspective of
   the [math] developer looking to add a new or specialized class and
   [math] users writing code that leverages the setup.
  
   Phil
   
   
Gilles
   
On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski 
   gsterijev...@gmail.comwrote:
   
Forgive me for pushing my nose under the tent... I couldn't resist.
   
I think Gilles is saying that each specialization of the
 matrix/vector
objects would need to support pre (and post) multiplication with a
   dense.
So
the type issue would not be problematic.
   
On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning 
 ted.dunn...@gmail.com
wrote:
   
No.
   
You can't.  This is because the type is lost as you enter the
 generic
library.
   
On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski 
gil...@harfang.homelinux.org wrote:
   
They know that their own object is dense, but they don't know
 what
kind
of
input they were given.  They should still run fast if the input
 is
sparse.
   
Couldn't we still rely on polymorphism by implementing
 preTimes:
  unknown.preTimes(dense)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
   
   
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
  



 -
 To unsubscribe, e-mail:

[POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque

Eclipse complains about all the @inheritDoc tags in LinkedBlockingDeque.

AFAICT, @inheritDoc is allowed in @throws, but only if the method has
something to inherit from, i.e.. it overrides a super-class method or
implements an interface (Java 1.6+)
It does not inherit from the Throwable, which was perhaps the intention?

Oracle Java 1.5 is happy to allow @inheritDoc in the add() method -
because that overrides - but Eclipse complains.
[Looks like bug in Eclipse javadoc handling]

However, neither Oracle nor Eclipse allow the tag if there is no
parent, so I propose to remove such tags.

OK?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:
http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving project
artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.comwrote:

 This is a vote to release Apache Commons VFS 2.0.

 Changes made since the last candidate:

 * Fixed the manifest error that was causing the build to fail.
 * Changed the copyright date in the Notice file from 2010 to 2011.
 * Removed the references to javamail from the Notice file.
 * Removed all the @version tags
 * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
 src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
 * Modified the release notes to mention the code is not source compatible
 with VFS 1.x and that the package name changed.
 * Fixed the WARNING for the use of the deprecated tasks element.
 * Fixed the WARNING for the use of the deprecated systemProperties element.
 * Made sure all jars have NOTICE.txt and LICENSE.txt

 The build message
 [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
 was not fixed as that is due to commons parent causing the maven-bundle
 plugin to run on all subprojects, including those that don't generate
 bundles or jars.

 I have also removed files that shouldn't be present in the Maven repository
 from the staging repo.

 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [ ] -1 no, do not release it because.

 Ralph


 Tag:
 https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
  (revision 1158401).

 Site: http://people.apache.org/~rgoers/commons-vfs/site/

 Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

 The following artifacts have been staged to the org.apache.commons-045
 (u:rgoers, a:208.29.163.248) repository.

 The Maven artifacts are at:


 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

 and consist of

 archetype-catalog.xml
 commons-vfs2-examples-2.0-javadoc.jar
 commons-vfs2-examples-2.0-sources.jar.asc
 commons-vfs2-examples-2.0.pom
 commons-vfs2-examples-2.0-tests.jar
 commons-vfs2-examples-2.0-tests.jar.asc
 commons-vfs2-examples-2.0.jar.asc
 commons-vfs2-examples-2.0.pom.asc
 commons-vfs2-examples-2.0-javadoc.jar.asc
 commons-vfs2-examples-2.0.jar
 commons-vfs2-examples-2.0-sources.jar
 commons-vfs2-project-2.0.pom.asc
 commons-vfs2-project-2.0.pom
 commons-vfs2-sandbox-2.0.pom.asc
 commons-vfs2-sandbox-2.0-sources.jar.asc
 commons-vfs2-sandbox-2.0-test-sources.jar.asc
 commons-vfs2-sandbox-2.0.jar
 commons-vfs2-sandbox-2.0-javadoc.jar
 commons-vfs2-sandbox-2.0-test-sources.jar
 commons-vfs2-sandbox-2.0.jar.asc
 commons-vfs2-sandbox-2.0-sources.jar
 commons-vfs2-sandbox-2.0-javadoc.jar.asc
 commons-vfs2-sandbox-2.0-tests.jar.asc
 commons-vfs2-sandbox-2.0-tests.jar
 commons-vfs2-sandbox-2.0.pom

Re: [POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque

+1, who's on first again?

Gary

On Wed, Aug 17, 2011 at 11:09 AM, sebb seb...@gmail.com wrote:

 Eclipse complains about all the @inheritDoc tags in LinkedBlockingDeque.

 AFAICT, @inheritDoc is allowed in @throws, but only if the method has
 something to inherit from, i.e.. it overrides a super-class method or
 implements an interface (Java 1.6+)
 It does not inherit from the Throwable, which was perhaps the intention?

 Oracle Java 1.5 is happy to allow @inheritDoc in the add() method -
 because that overrides - but Eclipse complains.
 [Looks like bug in Eclipse javadoc handling]

 However, neither Oracle nor Eclipse allow the tag if there is no
 parent, so I propose to remove such tags.

 OK?

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque

On 17 August 2011 16:09, sebb seb...@gmail.com wrote:
 Eclipse complains about all the @inheritDoc tags in LinkedBlockingDeque.

 AFAICT, @inheritDoc is allowed in @throws, but only if the method has
 something to inherit from, i.e.. it overrides a super-class method or
 implements an interface (Java 1.6+)
 It does not inherit from the Throwable, which was perhaps the intention?

 Oracle Java 1.5 is happy to allow @inheritDoc in the add() method -
 because that overrides - but Eclipse complains.
 [Looks like bug in Eclipse javadoc handling]

Actually, just discovered that Oracle Javadoc has problems too - it
does not complain about the tag for overriding methods, but does not
import the details either - the generated Javadoc for add(E)
contains

Overrides:
add in class AbstractQueueE

Throws:
{@inheritDoc}

which is not at all helpful ...

So it now looks like all the inheritDoc tags should be removed from
throws clauses.

 However, neither Oracle nor Eclipse allow the tag if there is no
 parent, so I propose to remove such tags.

 OK?


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] iterator and sparseIterator in RealVector hierarchy

Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning: 
 Arne,
 
 Please read the thread again.  I am providing an example of how I think
 things *should* be.
OK.
if I understand you right: isSparse() should be added to RealVector and
the interface SparseRealVector can be dropped?

 
 The point of doing so is that things are not that way now.  Telling me that
 they are not that way is pretty redundant.
 
 On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote:
 
  Currently sparseIterator is only used in RealVector, no matrix class
  will be affected, because there is no sparseIterator.
  Search you sources for sparseIterator ?
 
  Arne
  Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning:
   Here is an example from the perspective of somebody adding a new kind of
   matrix.
  
   Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p)
  that
   has elements that are -1, 0 or 1.  1 and -1 have equal probabilities of
  p/2.
The value of p should be in [0,1].
  
   It would be very nice if the implementor of this matrix could extend an
   abstract matrix and over-ride get() to generate a value and set() to
  throw
   an unsupported operation exception.  If p  0.1, then the matrix should
  be
   marked as sparse, else as dense.
  
   All operations against other matrices, sparse or dense should work well
   without any special handling by the implementor of this matrix.
  
   This works in Mahout for instance by having the default operations in
   AbstractMatrix test for sparseness of left or right operands and do the
   right thing.  Obviously, a type test will not tell you whether this
  matrix
   is sparse or not.
  
   This matrix and siblings is very important in compressed sensing and
   stochastic projection algorithms.
  
   On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com
  wrote:
  
On 8/16/11 4:46 AM, Gilles Sadowski wrote:
 Hi.

 I understood what he was suggesting.  I still disagree.  Dynamic
dispatch
 and non-lattice typing structure is still required to make this all
work.
  Java doesn't really do that.  Pretending that what Java does is
sufficient
 is hammer-looking-for-a-nail, not solving the problems at hand.
 Maybe that *I* don't understand what you are hinting at. Sorry for
  being
 dense. [Although that seems appropriate in this discussion :-).]

 Polymorphism provides dynamic dispatch, overloading does not; that's
  why
my
 proposition is that when you manipulate unknown types, those should
come
 as this, not as the argument of the method.

 What's wrong with that?

 As for hammer-looking-for-a-nail, I also don't see what you mean:
  What
is
 the problem? I guess that there are lots of applications who never
  need
to
 know about sparse vectors/matrices. In those cases, the added
  complexity
is
 not a feature. The issue reported contends that the current design
  in
CM
 can cause problems for dense implementations. I'm not even sure that
  the
 current design is usable for the type of applications that make heavy
  use
of
 sparseness. Those are problems, IMHO.
   
I have been out of pocket the last couple of days and may not have
time to dig into this until late tonight, but I agree with Gilles
that we need to get the conversation here more concrete.  I know we
discussed this before and Ted and others had good examples
justifying the current setup.  Can we revisit these, please?   What
would be great would be some examples both from the perspective of
the [math] developer looking to add a new or specialized class and
[math] users writing code that leverages the setup.
   
Phil


 Gilles

 On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski 
gsterijev...@gmail.comwrote:

 Forgive me for pushing my nose under the tent... I couldn't resist.

 I think Gilles is saying that each specialization of the
  matrix/vector
 objects would need to support pre (and post) multiplication with a
dense.
 So
 the type issue would not be problematic.

 On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning 
  ted.dunn...@gmail.com
 wrote:

 No.

 You can't.  This is because the type is lost as you enter the
  generic
 library.

 On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski 
 gil...@harfang.homelinux.org wrote:

 They know that their own object is dense, but they don't know
  what
 kind
 of
 input they were given.  They should still run fast if the input
  is
 sparse.

 Couldn't we still rely on polymorphism by implementing
  preTimes:
   unknown.preTimes(dense)
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail:

Re: [Math] iterator and sparseIterator in RealVector hierarchy

I think that all vectors and matrices should be able to answer the question
about whether they are sparse and they should support sparse iterators,
defaulting to the normal iterators in the general case.  So yes to the first
question.  This allows the application programmer to be much less concerned
about whether they are using a sparse or dense matrix without losing much
performance, if any.

The second question I think is much less clear.  It might well be a good
idea to keep the interface to help the compiler in cases where the
programmer knows which general class of matrix they have.

On Wed, Aug 17, 2011 at 8:29 AM, Arne Ploese aplo...@gmx.de wrote:

 Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning:
  Arne,
 
  Please read the thread again.  I am providing an example of how I think
  things *should* be.
 OK.
 if I understand you right: isSparse() should be added to RealVector and
 the interface SparseRealVector can be dropped?

 
  The point of doing so is that things are not that way now.  Telling me
 that
  they are not that way is pretty redundant.
 
  On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote:
 
   Currently sparseIterator is only used in RealVector, no matrix class
   will be affected, because there is no sparseIterator.
   Search you sources for sparseIterator ?
  
   Arne
   Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning:
Here is an example from the perspective of somebody adding a new kind
 of
matrix.
   
Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p)
   that
has elements that are -1, 0 or 1.  1 and -1 have equal probabilities
 of
   p/2.
 The value of p should be in [0,1].
   
It would be very nice if the implementor of this matrix could extend
 an
abstract matrix and over-ride get() to generate a value and set() to
   throw
an unsupported operation exception.  If p  0.1, then the matrix
 should
   be
marked as sparse, else as dense.
   
All operations against other matrices, sparse or dense should work
 well
without any special handling by the implementor of this matrix.
   
This works in Mahout for instance by having the default operations in
AbstractMatrix test for sparseness of left or right operands and do
 the
right thing.  Obviously, a type test will not tell you whether this
   matrix
is sparse or not.
   
This matrix and siblings is very important in compressed sensing and
stochastic projection algorithms.
   
On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com
   wrote:
   
 On 8/16/11 4:46 AM, Gilles Sadowski wrote:
  Hi.
 
  I understood what he was suggesting.  I still disagree.  Dynamic
 dispatch
  and non-lattice typing structure is still required to make this
 all
 work.
   Java doesn't really do that.  Pretending that what Java does is
 sufficient
  is hammer-looking-for-a-nail, not solving the problems at hand.
  Maybe that *I* don't understand what you are hinting at. Sorry
 for
   being
  dense. [Although that seems appropriate in this discussion :-).]
 
  Polymorphism provides dynamic dispatch, overloading does not;
 that's
   why
 my
  proposition is that when you manipulate unknown types, those
 should
 come
  as this, not as the argument of the method.
 
  What's wrong with that?
 
  As for hammer-looking-for-a-nail, I also don't see what you
 mean:
   What
 is
  the problem? I guess that there are lots of applications who
 never
   need
 to
  know about sparse vectors/matrices. In those cases, the added
   complexity
 is
  not a feature. The issue reported contends that the current
 design
   in
 CM
  can cause problems for dense implementations. I'm not even sure
 that
   the
  current design is usable for the type of applications that make
 heavy
   use
 of
  sparseness. Those are problems, IMHO.

 I have been out of pocket the last couple of days and may not have
 time to dig into this until late tonight, but I agree with Gilles
 that we need to get the conversation here more concrete.  I know we
 discussed this before and Ted and others had good examples
 justifying the current setup.  Can we revisit these, please?   What
 would be great would be some examples both from the perspective of
 the [math] developer looking to add a new or specialized class and
 [math] users writing code that leverages the setup.

 Phil
 
 
  Gilles
 
  On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski 
 gsterijev...@gmail.comwrote:
 
  Forgive me for pushing my nose under the tent... I couldn't
 resist.
 
  I think Gilles is saying that each specialization of the
   matrix/vector
  objects would need to support pre (and post) multiplication
 with a
 dense.
  So
  the type issue would not be

[math] StorelessCovariance

2011-08-17 Thread Patrick Meyer

I am workin on the StorelessCovariance per jira MATH-449. However, I'm 
having a hard time using subversion via Netbeans. I have successfully 
created the new classes and a JUnit test. However, when I run the test I 
get the following message,


caused an ERORR: Absent Code attribute in method that is not native or 
abstract in class file org/apache/commons/math/TestUtils


Any help would be appreciated. I have a lot to contribute to commons 
math but my lack of experience with subversion is really hindering me.


Thanks,
Patrick

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] StorelessCovariance

On 8/17/11 9:15 AM, Patrick Meyer wrote:
 caused an ERORR: Absent Code attribute in method that is not
 native or abstract in class file org/apache/commons/math/TestUtils

First of all, THANKS for working on this!

This may not be what you want to hear or the fashionable response,
but I personally never use IDE integrated thingies for exactly this
kind of reason.  Most likely you have some kind of classpath or
compiled class cleanup problem.  Try cleaning everything and
starting with a fresh checkout and also checking that the IDE is not
bringing in an old [math] jar somehow.

As I said, because of this kind of silliness, I always just run svn
co or svn up from the command line and then mvn clean test from
the checked out trunk.  Then svn diff  newPatch to create patches
or inspect changes before committing.  Using -Dtest=ClassNameOfTest
is convenient if you don't want to run all of the tests.

Phil

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[math] StorelessCovariance

2011-08-17 Thread Patrick

I am workin on the StorelessCovariance per jira MATH-449. However, I'm 
having a hard time using subversion via Netbeans. I have successfully 
created the new classes and a JUnit test. However, when I run the test I 
get the following message,


caused an ERORR: Absent Code attribute in method that is not native or 
abstract in class file org/apache/commons/math/TestUtils


Any help would be appreciated. I have a lot to contribute to commons 
math but my lack of experience with subversion is really hindering me.


Thanks,
Patrick



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [chain] Apache Chain v2 Proof of Concept

2011-08-17 Thread Elijah Zupancic

Hi Matt and Simo,

I've attached the patch to the bug and fixed the issues mentioned with faces.

What other steps do I need to do now?

Thanks,
-Elijah

On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson gudnabr...@gmail.com wrote:
 Hi, Elijah--

  I am neither a develop nor even a user of chain, so my comments will
 be high-level.  Firstly, by all means upgrade to whatever JUnit 4
 release version you like, e.g. 4.8.2.  Next, I personally am a big fan
 of Mockito, so no complaints here on that account.  I can't guarantee
 noone else would complain, but [chain] has been fairly unloved for a
 good while.  As for JSF 2.1, is there something this achieves that
 wouldn't be equally well accomplished by simply upgrading to 2.0?
 This would give [chain]'s JSF support (which I personally hadn't
 realized existed) a potentially better combination of
 doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
 possible applicability.

 Finally, as you don't seem to be a committer your final submission in
 this regard would be best recommended in the form of a JIRA issue, and
 your patches in (albeit large) patch form.  In addition to this, the
 scope of these changes indicates it best IMO that you submit an
 Individual Contributor License Agreement governing your contributions
 to the ASF.  See http://www.apache.org/licenses/#clas for details on
 how to do this.

 Regards and welcome,
 Matt

 On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic eli...@zupancic.name wrote:
 I've just finished my proof of concept for an upgrade to Apache chain.
 I would love to get this into a svn branch. I'm not quite sure what
 the procedure is to do that, but the code can be found here for
 review:

 http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz

 And here is a diff:

 http://elijah.zupancic.name/projects/uber-diff

 At a high level, I have incorporated the following features in this
 proof of concept:

 * Global upgrade to the JDK 1.5
 * Added @Override annotations
 * Upgraded to the Servlet 2.5 API
 * Upgraded to the Faces 2.1 API
 * Upgraded to the Portlet 2.0 API
 * Upgraded the Maven Parent POM version
 * Added generics support to Command so that Command's API looks like:

 public interface CommandT extends Context {
 ...
    boolean execute(T context) throws Exception;
 }

 * Servlet and Portlet packages now provide Genericized APIs.
 * All dicey changes have been marked with a comment with my name: (elijah)

 More or less the work to updated Chain was straight forward albeit
 time consuming.

 If everyone is on board for this update, I would like to upgrade the
 test cases to use a new version of JUnit. However, this leads to a few
 questions:

 * What version of JUnit should I use?
 * Would it be ok to use Mockito for mocking instead of the home grown
 mocking classes already contained in the project?

 Please let me know what you think. Getting this far has been a couple
 weeks worth of on and off work.

 Thanks,
 -Elijah

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [chain] Apache Chain v2 Proof of Concept

2011-08-17 Thread Matt Benson

Be patient, while not being so patient that you allow us to forget it.

Matt

On Wed, Aug 17, 2011 at 12:01 PM, Elijah Zupancic eli...@zupancic.name wrote:
 Hi Matt and Simo,

 I've attached the patch to the bug and fixed the issues mentioned with faces.

 What other steps do I need to do now?

 Thanks,
 -Elijah

 On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson gudnabr...@gmail.com wrote:
 Hi, Elijah--

  I am neither a develop nor even a user of chain, so my comments will
 be high-level.  Firstly, by all means upgrade to whatever JUnit 4
 release version you like, e.g. 4.8.2.  Next, I personally am a big fan
 of Mockito, so no complaints here on that account.  I can't guarantee
 noone else would complain, but [chain] has been fairly unloved for a
 good while.  As for JSF 2.1, is there something this achieves that
 wouldn't be equally well accomplished by simply upgrading to 2.0?
 This would give [chain]'s JSF support (which I personally hadn't
 realized existed) a potentially better combination of
 doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
 possible applicability.

 Finally, as you don't seem to be a committer your final submission in
 this regard would be best recommended in the form of a JIRA issue, and
 your patches in (albeit large) patch form.  In addition to this, the
 scope of these changes indicates it best IMO that you submit an
 Individual Contributor License Agreement governing your contributions
 to the ASF.  See http://www.apache.org/licenses/#clas for details on
 how to do this.

 Regards and welcome,
 Matt

 On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic eli...@zupancic.name 
 wrote:
 I've just finished my proof of concept for an upgrade to Apache chain.
 I would love to get this into a svn branch. I'm not quite sure what
 the procedure is to do that, but the code can be found here for
 review:

 http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz

 And here is a diff:

 http://elijah.zupancic.name/projects/uber-diff

 At a high level, I have incorporated the following features in this
 proof of concept:

 * Global upgrade to the JDK 1.5
 * Added @Override annotations
 * Upgraded to the Servlet 2.5 API
 * Upgraded to the Faces 2.1 API
 * Upgraded to the Portlet 2.0 API
 * Upgraded the Maven Parent POM version
 * Added generics support to Command so that Command's API looks like:

 public interface CommandT extends Context {
 ...
    boolean execute(T context) throws Exception;
 }

 * Servlet and Portlet packages now provide Genericized APIs.
 * All dicey changes have been marked with a comment with my name: (elijah)

 More or less the work to updated Chain was straight forward albeit
 time consuming.

 If everyone is on board for this update, I would like to upgrade the
 test cases to use a new version of JUnit. However, this leads to a few
 questions:

 * What version of JUnit should I use?
 * Would it be ok to use Mockito for mocking instead of the home grown
 mocking classes already contained in the project?

 Please let me know what you think. Getting this far has been a couple
 weeks worth of on and off work.

 Thanks,
 -Elijah

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [chain] Apache Chain v2 Proof of Concept

2011-08-17 Thread Matt Benson

BTW, please don't take the previous response as indicating any
negativity on my part.  Feel free to prod us as long as possible, at
reasonable frequency.

Matt

On Wed, Aug 17, 2011 at 12:04 PM, Matt Benson gudnabr...@gmail.com wrote:
 Be patient, while not being so patient that you allow us to forget it.

 Matt

 On Wed, Aug 17, 2011 at 12:01 PM, Elijah Zupancic eli...@zupancic.name 
 wrote:
 Hi Matt and Simo,

 I've attached the patch to the bug and fixed the issues mentioned with faces.

 What other steps do I need to do now?

 Thanks,
 -Elijah

 On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson gudnabr...@gmail.com wrote:
 Hi, Elijah--

  I am neither a develop nor even a user of chain, so my comments will
 be high-level.  Firstly, by all means upgrade to whatever JUnit 4
 release version you like, e.g. 4.8.2.  Next, I personally am a big fan
 of Mockito, so no complaints here on that account.  I can't guarantee
 noone else would complain, but [chain] has been fairly unloved for a
 good while.  As for JSF 2.1, is there something this achieves that
 wouldn't be equally well accomplished by simply upgrading to 2.0?
 This would give [chain]'s JSF support (which I personally hadn't
 realized existed) a potentially better combination of
 doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest
 possible applicability.

 Finally, as you don't seem to be a committer your final submission in
 this regard would be best recommended in the form of a JIRA issue, and
 your patches in (albeit large) patch form.  In addition to this, the
 scope of these changes indicates it best IMO that you submit an
 Individual Contributor License Agreement governing your contributions
 to the ASF.  See http://www.apache.org/licenses/#clas for details on
 how to do this.

 Regards and welcome,
 Matt

 On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic eli...@zupancic.name 
 wrote:
 I've just finished my proof of concept for an upgrade to Apache chain.
 I would love to get this into a svn branch. I'm not quite sure what
 the procedure is to do that, but the code can be found here for
 review:

 http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz

 And here is a diff:

 http://elijah.zupancic.name/projects/uber-diff

 At a high level, I have incorporated the following features in this
 proof of concept:

 * Global upgrade to the JDK 1.5
 * Added @Override annotations
 * Upgraded to the Servlet 2.5 API
 * Upgraded to the Faces 2.1 API
 * Upgraded to the Portlet 2.0 API
 * Upgraded the Maven Parent POM version
 * Added generics support to Command so that Command's API looks like:

 public interface CommandT extends Context {
 ...
    boolean execute(T context) throws Exception;
 }

 * Servlet and Portlet packages now provide Genericized APIs.
 * All dicey changes have been marked with a comment with my name: (elijah)

 More or less the work to updated Chain was straight forward albeit
 time consuming.

 If everyone is on board for this update, I would like to upgrade the
 test cases to use a new version of JUnit. However, this leads to a few
 questions:

 * What version of JUnit should I use?
 * Would it be ok to use Mockito for mocking instead of the home grown
 mocking classes already contained in the project?

 Please let me know what you think. Getting this far has been a couple
 weeks worth of on and off work.

 Thanks,
 -Elijah

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[continuum] BUILD FAILURE: Apache Commons - Commons Pool - Default Maven 2 Build Definition (Java 1.5)

2011-08-17 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11393projectId=98

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed 17 Aug 2011 17:22:07 +
  Finished at: Wed 17 Aug 2011 17:22:15 +
  Total time: 7s
  Build Trigger: Schedule
  Build Number: 106
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version 1.6.0_24
  Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
  Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_24
  Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
  Default locale: en_AU, platform encoding: UTF-8
  OS name: linux version: 2.6.32-31-server arch: amd64 Family: 
unix


SCM Changes:

Changed: markt @ Wed 17 Aug 2011 17:03:35 +
Comment: POOL-98. Add additional attributes for moniroting (also available via 
JMX)
Files changed:
  /commons/proper/pool/trunk/src/changes/changes.xml ( 1158831 )
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
 ( 1158831 )
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPoolMBean.java
 ( 1158831 )
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java
 ( 1158831 )
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPoolMBean.java
 ( 1158831 )
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/PooledObject.java
 ( 1158831 )

Changed: markt @ Wed 17 Aug 2011 17:10:25 +
Comment: Ensure MBeans are de-registered on pool close.
Files changed:
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
 ( 1158834 )
  
/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java
 ( 1158834 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] StorelessCovariance

2011-08-17 Thread Luc Maisonobe


Hi Patrick,

Le 17/08/2011 18:15, Patrick Meyer a écrit :

I am workin on the StorelessCovariance per jira MATH-449. However, I'm
having a hard time using subversion via Netbeans. I have successfully
created the new classes and a JUnit test. However, when I run the test I
get the following message,

caused an ERORR: Absent Code attribute in method that is not native or
abstract in class file org/apache/commons/math/TestUtils


Do you have a complete implementation of JUnit in your classpath or only 
the top level API ?


It seems similar to this: 
http://www.andrejkoelewijn.com/wp/2010/03/04/absent-code-attribute-in-method-that-is-not-native-or-abstract/ 
or this 
http://dominikdorn.com/2010/05/maven-junit-classformaterror-absent-code-attribute/ 
and hence elated to API and implementation separation.


Apache Commons Math does not have any runtime dependency and the only 
test time dependency is JUnit.


Luc




Any help would be appreciated. I have a lot to contribute to commons
math but my lack of experience with subversion is really hindering me.

Thanks,
Patrick

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] iterator and sparseIterator in RealVector hierarchy

So what exactly is the meaning of isSparse?

* the vector at hand implements some kind of sparse storage? I.E:
OpenMapRealVector

or

* the vector is actually sparsely filled (then what is sparse anyway
10%, 50%, 90%?) in this case a SparserelVector interface is useless for
the compiler.

My suggestion is: ArrayRealVector implements a sparse iterator which
returns only values != 0? 

Having the backing storage implementation open, one could think of:

* isArray
* isBanded
* isSymetrical
* isDiagonal

as additional markers or put the whole thing in an enum or EnumSet?  

Am Mittwoch, den 17.08.2011, 08:51 -0700 schrieb Ted Dunning: 
 I think that all vectors and matrices should be able to answer the question
 about whether they are sparse and they should support sparse iterators,
 defaulting to the normal iterators in the general case.  So yes to the first
 question.  This allows the application programmer to be much less concerned
 about whether they are using a sparse or dense matrix without losing much
 performance, if any.
 
 The second question I think is much less clear.  It might well be a good
 idea to keep the interface to help the compiler in cases where the
 programmer knows which general class of matrix they have.
 
 On Wed, Aug 17, 2011 at 8:29 AM, Arne Ploese aplo...@gmx.de wrote:
 
  Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning:
   Arne,
  
   Please read the thread again.  I am providing an example of how I think
   things *should* be.
  OK.
  if I understand you right: isSparse() should be added to RealVector and
  the interface SparseRealVector can be dropped?
 
  
   The point of doing so is that things are not that way now.  Telling me
  that
   they are not that way is pretty redundant.
  
   On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote:
  
Currently sparseIterator is only used in RealVector, no matrix class
will be affected, because there is no sparseIterator.
Search you sources for sparseIterator ?
   
Arne
Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning:
 Here is an example from the perspective of somebody adding a new kind
  of
 matrix.

 Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p)
that
 has elements that are -1, 0 or 1.  1 and -1 have equal probabilities
  of
p/2.
  The value of p should be in [0,1].

 It would be very nice if the implementor of this matrix could extend
  an
 abstract matrix and over-ride get() to generate a value and set() to
throw
 an unsupported operation exception.  If p  0.1, then the matrix
  should
be
 marked as sparse, else as dense.

 All operations against other matrices, sparse or dense should work
  well
 without any special handling by the implementor of this matrix.

 This works in Mahout for instance by having the default operations in
 AbstractMatrix test for sparseness of left or right operands and do
  the
 right thing.  Obviously, a type test will not tell you whether this
matrix
 is sparse or not.

 This matrix and siblings is very important in compressed sensing and
 stochastic projection algorithms.

 On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com
wrote:

  On 8/16/11 4:46 AM, Gilles Sadowski wrote:
   Hi.
  
   I understood what he was suggesting.  I still disagree.  Dynamic
  dispatch
   and non-lattice typing structure is still required to make this
  all
  work.
Java doesn't really do that.  Pretending that what Java does is
  sufficient
   is hammer-looking-for-a-nail, not solving the problems at hand.
   Maybe that *I* don't understand what you are hinting at. Sorry
  for
being
   dense. [Although that seems appropriate in this discussion :-).]
  
   Polymorphism provides dynamic dispatch, overloading does not;
  that's
why
  my
   proposition is that when you manipulate unknown types, those
  should
  come
   as this, not as the argument of the method.
  
   What's wrong with that?
  
   As for hammer-looking-for-a-nail, I also don't see what you
  mean:
What
  is
   the problem? I guess that there are lots of applications who
  never
need
  to
   know about sparse vectors/matrices. In those cases, the added
complexity
  is
   not a feature. The issue reported contends that the current
  design
in
  CM
   can cause problems for dense implementations. I'm not even sure
  that
the
   current design is usable for the type of applications that make
  heavy
use
  of
   sparseness. Those are problems, IMHO.
 
  I have been out of pocket the last couple of days and may not have
  time to dig into this until late tonight, but I agree with Gilles
  that we need to get the conversation here more concrete.  I know we

Re: [Vote] Release Commons VFS 2.0

What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I could
add that to the readme, but it is documented pretty well on the maven site
plugin web site.

In a prior release candidate I wasn't generating the release notes and I had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only works
at the project root.

The build instructions consist of:

mvn clean install

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving project
artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source compatible
with VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties
element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

The build message
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
bundle]
was not fixed as that is due to commons parent causing the maven-bundle
plugin to run on all subprojects, including those that don't generate
bundles or jars.

I have also removed files that shouldn't be present in the Maven
repository
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph

Tag:

https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
1158401).

Site: http://people.apache.org/~rgoers/commons-vfs/site/

Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the org.apache.commons-045
(u:rgoers, a:208.29.163.248) repository.

The Maven artifacts are at:

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

and consist of

archetype-catalog.xml
commons-vfs2-examples-2.0-javadoc.jar

Re: [Vote] Release Commons VFS 2.0

Oh - and if for some non-obvious reason you want to create the distribution
jars when you do the build you can run

mvn -P apache-release clean install.

On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

Oops. That should be mvn site:stage-deploy.

Ralph

On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

In a prior release candidate I wasn't generating the release notes and I
had the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only works
at the project root.

The build instructions consist of:

mvn clean install

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source
compatible
with VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties
element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

I have also removed files that shouldn't be present in the Maven
repository
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph

Tag:

https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
1158401).

Site: http://people.apache.org/~rgoers/commons-vfs/site/

Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the org.apache.commons-045
(u:rgoers, a:208.29.163.248) repository.

The Maven artifacts are at:

Re: [Math] iterator and sparseIterator in RealVector hierarchy

I would think neither.

I think it should mean that the sparseIterator will be enough faster than
the dense iterator to make it worth using.  The indication doesn't have to
be be crisp or even always quite correct.  Thus, a densely filled
OpenMapReal might just return true because that usage is out of the
ordinary.

Regarding what the sparseIterator returns, skipping zeroes is a fine idea,
but the contract should really be that all non-zeros will be returned rather
than no zeros will be returned.  There should be flexibility to return zero
values if that is much more convenient, but there should be no case where a
non-zero is missed.

Regarding the additional indicators, these are occasionally useful in
particular cases, but many of those special cases actually work out just as
well if you simply treat them as sparse.  As an example, multiplication by a
diagonal matrix can be special cased, but simply iterating over the
non-zeros (i.e. the diagonal) is just as good.  Matrix power is a
counter-example where the computation can be reduced to element-wise power
for diagonal, but not for sparse.  Even so, the sparse implementation is
surprisingly competitive even there especially for small powers if you have
a special sparse-sparse multiply.  Mahout has an additional indicator
function that tells whether sparseIterator returns items in a sequential
order which can reduce many of these cases to a merge.

For banded arrays, the economies available beyond simple sparse algorithms
are even more limited.

Symmetric and triangular matrices also have special properties but it is
hard to decide what is really important there.  Many of the special
operations for these kinds of matrix are subject to solving by overloads
instead of indicators since we aren't dealing with binary operations.  For
example, left and right inverse multiplication with triangular matrices is
handled by normal single dispatch and qualifying an argument for real
Cholesky decomposition is specific to the Cholesky decomposition itself.

On Wed, Aug 17, 2011 at 11:28 AM, Arne Ploese aplo...@gmx.de wrote:

 So what exactly is the meaning of isSparse?

 * the vector at hand implements some kind of sparse storage? I.E:
 OpenMapRealVector

 or

 * the vector is actually sparsely filled (then what is sparse anyway
 10%, 50%, 90%?) in this case a SparserelVector interface is useless for
 the compiler.

 My suggestion is: ArrayRealVector implements a sparse iterator which
 returns only values != 0?

 Having the backing storage implementation open, one could think of:

 * isArray
 * isBanded
 * isSymetrical
 * isDiagonal

 as additional markers or put the whole thing in an enum or EnumSet?

 Am Mittwoch, den 17.08.2011, 08:51 -0700 schrieb Ted Dunning:
  I think that all vectors and matrices should be able to answer the
 question
  about whether they are sparse and they should support sparse iterators,
  defaulting to the normal iterators in the general case.  So yes to the
 first
  question.  This allows the application programmer to be much less
 concerned
  about whether they are using a sparse or dense matrix without losing much
  performance, if any.
 
  The second question I think is much less clear.  It might well be a good
  idea to keep the interface to help the compiler in cases where the
  programmer knows which general class of matrix they have.
 
  On Wed, Aug 17, 2011 at 8:29 AM, Arne Ploese aplo...@gmx.de wrote:
 
   Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning:
Arne,
   
Please read the thread again.  I am providing an example of how I
 think
things *should* be.
   OK.
   if I understand you right: isSparse() should be added to RealVector and
   the interface SparseRealVector can be dropped?
  
   
The point of doing so is that things are not that way now.  Telling
 me
   that
they are not that way is pretty redundant.
   
On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote:
   
 Currently sparseIterator is only used in RealVector, no matrix
 class
 will be affected, because there is no sparseIterator.
 Search you sources for sparseIterator ?

 Arne
 Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning:
  Here is an example from the perspective of somebody adding a new
 kind
   of
  matrix.
 
  Take the two kinds of matrix as RandomTrinaryMatrix(rows,
 columns, p)
 that
  has elements that are -1, 0 or 1.  1 and -1 have equal
 probabilities
   of
 p/2.
   The value of p should be in [0,1].
 
  It would be very nice if the implementor of this matrix could
 extend
   an
  abstract matrix and over-ride get() to generate a value and set()
 to
 throw
  an unsupported operation exception.  If p  0.1, then the matrix
   should
 be
  marked as sparse, else as dense.
 
  All operations against other matrices, sparse or dense should
 work
   well
  without any special handling by the implementor

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 19:37, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
Oh - and if for some non-obvious reason you want to create the distribution
jars when you do the build you can run

mvn -P apache-release clean install.

I though commons normally use their own release profile, which is -Prelease ?

On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

Oops. That should be mvn site:stage-deploy.

Ralph

On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

In a prior release candidate I wasn't generating the release notes and I
had the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only works
at the project root.

The build instructions consist of:

mvn clean install

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report ---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source
compatible
with VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties
element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

I have also removed files that shouldn't be present in the Maven
repository
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph

Tag:

https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
1158401).

Site: http://people.apache.org/~rgoers/commons-vfs/site/

Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the

Re: [Vote] Release Commons VFS 2.0

The Maven release plugin uses the apache-release profile which is set up in
the apache parent pom.

Ralph

On Wed, Aug 17, 2011 at 11:49 AM, sebb seb...@gmail.com wrote:

On 17 August 2011 19:37, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
Oh - and if for some non-obvious reason you want to create the
distribution
jars when you do the build you can run

mvn -P apache-release clean install.

I though commons normally use their own release profile, which is -Prelease
?

On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

Oops. That should be mvn site:stage-deploy.

Ralph

On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and
I
had the comment in the README. The release was vetoed due to the lack
of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.
Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.
Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate
(default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers
ralph.go...@dslextreme.com
wrote:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source
compatible
with VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties
element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

The build message
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
bundle]
was not fixed as that is due to commons parent causing the
maven-bundle
plugin to run on all subprojects, including those that don't
generate
bundles or jars.

I have also removed files that shouldn't be present in the Maven
repository
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not

Re: [Vote] Release Commons VFS 2.0

Commons parent has both a release profile and an apache-release profile.
The apache-release profile is used by the release plugin as it is set up for
the ASF. I'm not sure what value-add (or value loss) the release profile
provides.

On Wed, Aug 17, 2011 at 12:12 PM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

The Maven release plugin uses the apache-release profile which is set up in
the apache parent pom.

Ralph

On Wed, Aug 17, 2011 at 11:49 AM, sebb seb...@gmail.com wrote:

On 17 August 2011 19:37, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
Oh - and if for some non-obvious reason you want to create the
distribution
jars when you do the build you can run

mvn -P apache-release clean install.

I though commons normally use their own release profile, which is
-Prelease ?

On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

Oops. That should be mvn site:stage-deploy.

Ralph

On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:

What do you mean It did not work? This is a multi-project site so
in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and
I
had the comment in the README. The release was vetoed due to the lack
of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.
Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed
or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.
Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate
(default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers
ralph.go...@dslextreme.com
wrote:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source
compatible
with VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties
element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

The build message
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
bundle]
was not fixed as

Re: [Vote] Release Commons VFS 2.0

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I could
add that to the readme, but it is documented pretty well on the maven site
plugin web site.

In a prior release candidate I wasn't generating the release notes and I had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only works
at the project root.

The build instructions consist of:

mvn clean install

Those instructions appear on the Download and Build paged linked
in the main site menu, so I don't see this as a a blocker.
Instructions on how to build the site are nice to have, but not
showstoppers, IMO - especially since they generally stop working as
incompatible plugin and / or maven versions change.

One question I have and I apologize if this has already been
discussed is are we sure we want to release the sandbox stuff?
There is no disclaimer of any kind on the web site or in the release
notes. If the contents of that jar are being released as normal
artifacts, why is it called sandbox? If not, why no explanation
anywhere of what sandbox means?

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:
This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

I have also removed files that shouldn't be present in the Maven
repository
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph

Tag:

https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/(revision
1158401).
Site: http://people.apache.org/~rgoers/commons-vfs/site/

Binaries:

Re: [Vote] Release Commons VFS 2.0

The sandbox question I can't answer very well. The sandbox stuff was there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

None of the sandbox stuff appears to have been distributed with the 1.0
release, including in the source distribution. I don't know of a way I can
stop Maven from deploying it to the staging repo, but I can certainly delete
it from there just like I did the distribution zips. If desired, I'd have to
do another release to remove that source from the release. It would also
stay on the web site.

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and I
had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli)
@
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers
ralph.go...@dslextreme.com
wrote:
This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Oliver Heger

Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts 
and site look good.


The only thing I am missing are md5 files. Are they required (other 
components used to have them)? If not, you can count my +1.


Oliver

Am 17.08.2011 07:44, schrieb Ralph Goers:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and 
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source compatible with 
VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

The build message
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle]
was not fixed as that is due to commons parent causing the maven-bundle plugin 
to run on all subprojects, including those that don't generate bundles or jars.

I have also removed files that shouldn't be present in the Maven repository 
from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph


Tag: 
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
  (revision 1158401).

Site: http://people.apache.org/~rgoers/commons-vfs/site/

Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the org.apache.commons-045 
(u:rgoers, a:208.29.163.248) repository.

The Maven artifacts are at:

https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

and consist of

archetype-catalog.xml
commons-vfs2-examples-2.0-javadoc.jar
commons-vfs2-examples-2.0-sources.jar.asc
commons-vfs2-examples-2.0.pom
commons-vfs2-examples-2.0-tests.jar
commons-vfs2-examples-2.0-tests.jar.asc
commons-vfs2-examples-2.0.jar.asc
commons-vfs2-examples-2.0.pom.asc
commons-vfs2-examples-2.0-javadoc.jar.asc
commons-vfs2-examples-2.0.jar
commons-vfs2-examples-2.0-sources.jar
commons-vfs2-project-2.0.pom.asc
commons-vfs2-project-2.0.pom
commons-vfs2-sandbox-2.0.pom.asc
commons-vfs2-sandbox-2.0-sources.jar.asc
commons-vfs2-sandbox-2.0-test-sources.jar.asc
commons-vfs2-sandbox-2.0.jar
commons-vfs2-sandbox-2.0-javadoc.jar
commons-vfs2-sandbox-2.0-test-sources.jar
commons-vfs2-sandbox-2.0.jar.asc
commons-vfs2-sandbox-2.0-sources.jar
commons-vfs2-sandbox-2.0-javadoc.jar.asc
commons-vfs2-sandbox-2.0-tests.jar.asc
commons-vfs2-sandbox-2.0-tests.jar
commons-vfs2-sandbox-2.0.pom
commons-vfs2-2.0.pom.asc
commons-vfs2-2.0-javadoc.jar
commons-vfs2-2.0-tests.jar.asc
commons-vfs2-2.0-tests.jar
commons-vfs2-2.0.pom
commons-vfs2-2.0.jar
commons-vfs2-2.0-sources.jar.asc
commons-vfs2-2.0-test-sources.jar.asc
commons-vfs2-2.0.jar.asc
commons-vfs2-2.0-sources.jar
commons-vfs2-2.0-test-sources.jar
commons-vfs2-2.0-javadoc.jar.asc



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

On 8/17/11 12:45 PM, Oliver Heger wrote:
 Build is now successful under Windows 7 with Java 1.5 and 1.6.
 Artifacts and site look good.

 The only thing I am missing are md5 files. Are they required
 (other components used to have them)? If not, you can count my +1.

The md5s are required and we should test them as part of validating
the release candidate.

Phil

 Oliver

 Am 17.08.2011 07:44, schrieb Ralph Goers:
 This is a vote to release Apache Commons VFS 2.0.

 Changes made since the last candidate:

 * Fixed the manifest error that was causing the build to fail.
 * Changed the copyright date in the Notice file from 2010 to 2011.
 * Removed the references to javamail from the Notice file.
 * Removed all the @version tags
 * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
 src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
 * Modified the release notes to mention the code is not source
 compatible with VFS 1.x and that the package name changed.
 * Fixed the WARNING for the use of the deprecated tasks element.
 * Fixed the WARNING for the use of the deprecated
 systemProperties element.
 * Made sure all jars have NOTICE.txt and LICENSE.txt

 The build message
 [WARNING] Ignoring project type pom - supportedProjectTypes =
 [jar, bundle]
 was not fixed as that is due to commons parent causing the
 maven-bundle plugin to run on all subprojects, including those
 that don't generate bundles or jars.

 I have also removed files that shouldn't be present in the Maven
 repository from the staging repo.

 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [ ] -1 no, do not release it because.

 Ralph


 Tag:
 https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
  
 (revision 1158401).

 Site: http://people.apache.org/~rgoers/commons-vfs/site/

 Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/

 The following artifacts have been staged to the
 org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository.

 The Maven artifacts are at:

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/

 https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/


 and consist of

 archetype-catalog.xml
 commons-vfs2-examples-2.0-javadoc.jar
 commons-vfs2-examples-2.0-sources.jar.asc
 commons-vfs2-examples-2.0.pom
 commons-vfs2-examples-2.0-tests.jar
 commons-vfs2-examples-2.0-tests.jar.asc
 commons-vfs2-examples-2.0.jar.asc
 commons-vfs2-examples-2.0.pom.asc
 commons-vfs2-examples-2.0-javadoc.jar.asc
 commons-vfs2-examples-2.0.jar
 commons-vfs2-examples-2.0-sources.jar
 commons-vfs2-project-2.0.pom.asc
 commons-vfs2-project-2.0.pom
 commons-vfs2-sandbox-2.0.pom.asc
 commons-vfs2-sandbox-2.0-sources.jar.asc
 commons-vfs2-sandbox-2.0-test-sources.jar.asc
 commons-vfs2-sandbox-2.0.jar
 commons-vfs2-sandbox-2.0-javadoc.jar
 commons-vfs2-sandbox-2.0-test-sources.jar
 commons-vfs2-sandbox-2.0.jar.asc
 commons-vfs2-sandbox-2.0-sources.jar
 commons-vfs2-sandbox-2.0-javadoc.jar.asc
 commons-vfs2-sandbox-2.0-tests.jar.asc
 commons-vfs2-sandbox-2.0-tests.jar
 commons-vfs2-sandbox-2.0.pom
 commons-vfs2-2.0.pom.asc
 commons-vfs2-2.0-javadoc.jar
 commons-vfs2-2.0-tests.jar.asc
 commons-vfs2-2.0-tests.jar
 commons-vfs2-2.0.pom
 commons-vfs2-2.0.jar
 commons-vfs2-2.0-sources.jar.asc
 commons-vfs2-2.0-test-sources.jar.asc
 commons-vfs2-2.0.jar.asc
 commons-vfs2-2.0-sources.jar
 commons-vfs2-2.0-test-sources.jar
 commons-vfs2-2.0-javadoc.jar.asc


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

Nope. That is my mistake.  Maven generated them when it uploaded them to the
Nexus staging repo. But I deleted that since we don't deliver them from
there. I then uploaded the artifacts from where they were built on my
machine to the directory on people.a.o rather than grabbing them from Nexus,
which is what I should have done.  I'll have to correct that.

Ralph

On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger oliver.he...@oliver-heger.de
 wrote:

 Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts
 and site look good.

 The only thing I am missing are md5 files. Are they required (other
 components used to have them)? If not, you can count my +1.

 Oliver

 Am 17.08.2011 07:44, schrieb Ralph Goers:

  This is a vote to release Apache Commons VFS 2.0.

 Changes made since the last candidate:

 * Fixed the manifest error that was causing the build to fail.
 * Changed the copyright date in the Notice file from 2010 to 2011.
 * Removed the references to javamail from the Notice file.
 * Removed all the @version tags
 * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
 src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
 * Modified the release notes to mention the code is not source compatible
 with VFS 1.x and that the package name changed.
 * Fixed the WARNING for the use of the deprecated tasks element.
 * Fixed the WARNING for the use of the deprecated systemProperties
 element.
 * Made sure all jars have NOTICE.txt and LICENSE.txt

 The build message
 [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
 bundle]
 was not fixed as that is due to commons parent causing the maven-bundle
 plugin to run on all subprojects, including those that don't generate
 bundles or jars.

 I have also removed files that shouldn't be present in the Maven
 repository from the staging repo.

 [ ] +1 release it
 [ ] +0 go ahead I don't care
 [ ] -1 no, do not release it because.

 Ralph


 Tag: https://svn.apache.org/repos/**asf/commons/proper/vfs/tags/**
 commons-vfs2-project-2.0/https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
  (revision 1158401).

 Site: 
 http://people.apache.org/~**rgoers/commons-vfs/site/http://people.apache.org/~rgoers/commons-vfs/site/

 Binaries: 
 http://people.apache.org/~**rgoers/commons-vfs/staged/http://people.apache.org/~rgoers/commons-vfs/staged/

 The following artifacts have been staged to the org.apache.commons-045
 (u:rgoers, a:208.29.163.248) repository.

 The Maven artifacts are at:

 https://repository.apache.org/**content/groups/staging/org/**
 apache/commons/commons-vfs2/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
 https://repository.apache.org/**content/groups/staging/org/**
 apache/commons/commons-vfs2-**examples/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
 https://repository.apache.org/**content/groups/staging/org/**
 apache/commons/commons-vfs2-**project/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
 https://repository.apache.org/**content/groups/staging/org/**
 apache/commons/commons-vfs2-**sandbox/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

 and consist of

 archetype-catalog.xml
 commons-vfs2-examples-2.0-**javadoc.jar
 commons-vfs2-examples-2.0-**sources.jar.asc
 commons-vfs2-examples-2.0.pom
 commons-vfs2-examples-2.0-**tests.jar
 commons-vfs2-examples-2.0-**tests.jar.asc
 commons-vfs2-examples-2.0.jar.**asc
 commons-vfs2-examples-2.0.pom.**asc
 commons-vfs2-examples-2.0-**javadoc.jar.asc
 commons-vfs2-examples-2.0.jar
 commons-vfs2-examples-2.0-**sources.jar
 commons-vfs2-project-2.0.pom.**asc
 commons-vfs2-project-2.0.pom
 commons-vfs2-sandbox-2.0.pom.**asc
 commons-vfs2-sandbox-2.0-**sources.jar.asc
 commons-vfs2-sandbox-2.0-test-**sources.jar.asc
 commons-vfs2-sandbox-2.0.jar
 commons-vfs2-sandbox-2.0-**javadoc.jar
 commons-vfs2-sandbox-2.0-test-**sources.jar
 commons-vfs2-sandbox-2.0.jar.**asc
 commons-vfs2-sandbox-2.0-**sources.jar
 commons-vfs2-sandbox-2.0-**javadoc.jar.asc
 commons-vfs2-sandbox-2.0-**tests.jar.asc
 commons-vfs2-sandbox-2.0-**tests.jar
 commons-vfs2-sandbox-2.0.pom
 commons-vfs2-2.0.pom.asc
 commons-vfs2-2.0-javadoc.jar
 commons-vfs2-2.0-tests.jar.asc
 commons-vfs2-2.0-tests.jar
 commons-vfs2-2.0.pom
 commons-vfs2-2.0.jar
 commons-vfs2-2.0-sources.jar.**asc
 commons-vfs2-2.0-test-sources.**jar.asc
 commons-vfs2-2.0.jar.asc
 commons-vfs2-2.0-sources.jar
 commons-vfs2-2.0-test-sources.**jar
 commons-vfs2-2.0-javadoc.jar.**asc



 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:
The sandbox question I can't answer very well. The sandbox stuff was there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

Staying on the web site is fine. Releasing code and jars that we do
not intend to support is not, so I am -1 on this release. We used
to have an /experimental tree in [math] that we omitted from source
and binary releases. In the source assembly descriptor, this kind
of thing at least used to work:

fileSet
directorysrc/directory
excludes
exclude**/mantissa/**/exclude
exclude**/experimental/**/exclude
/excludes
/fileset

Phil

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and I
had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install
Those instructions appear on the Download and Build paged linked
in the main site menu, so I don't see this as a a blocker.
Instructions on how to build the site are nice to have, but not
showstoppers, IMO - especially since they generally stop working as
incompatible plugin and / or maven versions change.

Phil
Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli)
@
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers
ralph.go...@dslextreme.com
wrote:
This is a vote to release Apache Commons VFS 2.0.

Changes made since the

[lang?] Converting an array to an Iterable

2011-08-17 Thread Oliver Heger


Hi,

recently I stumbled over the use case to obtain an Iterable for an 
array. I was pretty sure that there should already be a solution for 
this problem, but could not find anything in the JDK or in [lang].


Would this be an addition to [lang]? Maybe in ArrayUtils?

Oliver

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

OK. I will take care of this, the MD5 issue and do something with the README
in a few hours after I get home from work and send out another release vote.
In the meantime, if there are any other problems that should be corrected
I'd appreciate the feedback.

Ralph

On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitz phil.ste...@gmail.com wrote:

On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:
The sandbox question I can't answer very well. The sandbox stuff was
there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

None of the sandbox stuff appears to have been distributed with the 1.0
release, including in the source distribution. I don't know of a way I
can
stop Maven from deploying it to the staging repo, but I can certainly
delete
it from there just like I did the distribution zips. If desired, I'd have
to
do another release to remove that source from the release. It would also
stay on the web site.

fileSet
directorysrc/directory
excludes
exclude**/mantissa/**/exclude
exclude**/experimental/**/exclude
/excludes
/fileset

Phil

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com
wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and
I
had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

Phil
Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.
Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)
Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.
Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] ---

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Luc Maisonobe

Le 17/08/2011 22:13, ralph.goers @dslextreme.com a écrit :

OK. I will take care of this, the MD5 issue and do something with the README
in a few hours after I get home from work and send out another release vote.

Was this vote offocially cancelled ?

Luc

In the meantime, if there are any other problems that should be corrected
I'd appreciate the feedback.

Ralph

On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitzphil.ste...@gmail.com wrote:

On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:

The sandbox question I can't answer very well. The sandbox stuff was

there

long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

None of the sandbox stuff appears to have been distributed with the 1.0
release, including in the source distribution. I don't know of a way I

can

stop Maven from deploying it to the staging repo, but I can certainly

delete

it from there just like I did the distribution zips. If desired, I'd have

do another release to remove that source from the release. It would also
stay on the web site.

fileSet
directorysrc/directory
excludes
exclude**/mantissa/**/exclude
exclude**/experimental/**/exclude
/excludes
/fileset

Phil

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitzphil.ste...@gmail.com

wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:

could

add that to the readme, but it is documented pretty well on the maven

site

plugin web site.

In a prior release candidate I wasn't generating the release notes and

had

the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only

works

at the project root.

The build instructions consist of:

mvn clean install

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregorygarydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.

Some

build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to

poke

around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom

[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving

project

artifact: Failure to find

org.apache.commons:commons-vfs-examples:pom:2.0

in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution

will

not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.

Why

we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate

(default-cli)

commons-vfs2 ---

Re: [lang?] Converting an array to an Iterable

2011-08-17 Thread Dave Brosius

 What would this do that java.util.Arrays.asList does not?  - Original 
Message -From: quot;Oliver Hegerquot; ;oliver.he...@oliver-heger.de

Re: [Vote] Release Commons VFS 2.0

Sorry, yes.

Ralph

On Wed, Aug 17, 2011 at 1:33 PM, Luc Maisonobe luc.maison...@free.frwrote:

Le 17/08/2011 22:13, ralph.goers @dslextreme.com a écrit :

OK. I will take care of this, the MD5 issue and do something with the
README
in a few hours after I get home from work and send out another release
vote.

Was this vote offocially cancelled ?

Luc

In the meantime, if there are any other problems that should be corrected
I'd appreciate the feedback.

Ralph

On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitzphil.ste...@gmail.com
wrote:

On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote:

The sandbox question I can't answer very well. The sandbox stuff was

there

long before I arrived to work on VFS, although I rewrote the webdav
stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

None of the sandbox stuff appears to have been distributed with the 1.0
release, including in the source distribution. I don't know of a way I

can

stop Maven from deploying it to the staging repo, but I can certainly

delete

it from there just like I did the distribution zips. If desired, I'd
have

do another release to remove that source from the release. It would
also
stay on the web site.

fileSet
directorysrc/directory
excludes
exclude**/mantissa/**/**exclude
exclude**/experimental/**/**exclude
/excludes
/fileset

Phil

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitzphil.ste...@gmail.com

wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:

could

add that to the readme, but it is documented pretty well on the maven

site

plugin web site.

In a prior release candidate I wasn't generating the release notes and

had

the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only

works

at the project root.

The build instructions consist of:

mvn clean install

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregorygarydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.

Some

build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~**rgoers/commons-vfs/staged/http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to

poke

around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-**plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/**org/apache/commons/commons-**
vfs-examples/2.0/commons-vfs-**examples-2.0.pomhttp://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom

[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.**ProjectBuildingException: Error resolving

project

artifact: Failure to find

org.apache.commons:commons-**vfs-examples:pom:2.0

in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution

will

not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-**vfs-examples:pom:2.0
at

org.apache.maven.project.**DefaultProjectBuilder.build(**
DefaultProjectBuilder.java:**272)

org.apache.maven.project.**DefaultMavenProjectBuilder.**
buildFromRepository(**DefaultMavenProjectBuilder.**java:237)

org.apache.maven.project.**DefaultMavenProjectBuilder.**

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 20:43, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
The sandbox question I can't answer very well. The sandbox stuff was there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

Can't you just remove it from the modules list?
That should stop Maven creating the jars at least.

In fact, if we are not releasing sandbox it really ought to be
disabled in the POM (perhaps via a profile)

it from there just like I did the distribution zips. If desired, I'd have to
do another release to remove that source from the release. It would also
stay on the web site.

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and I
had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found. Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report ---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir. Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli)
@
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Gary

On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers
ralph.go...@dslextreme.com
wrote:
This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 20:55, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
Nope. That is my mistake. Maven generated them when it uploaded them to the
Nexus staging repo. But I deleted that since we don't deliver them from
there. I then uploaded the artifacts from where they were built on my
machine to the directory on people.a.o rather than grabbing them from Nexus,
which is what I should have done. I'll have to correct that.

Rather than copying them before the vote, you could leave the zip/tgz
archives in the Nexus staging area until the vote is complete.

Then, just before publishing the staging repo, copy the non-Maven
files to the dist/ directory and delete from staging.

Then release the staging area.

Saves at least one set of copying.

Ralph

On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger oliver.he...@oliver-heger.de
wrote:

Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts
and site look good.

The only thing I am missing are md5 files. Are they required (other
components used to have them)? If not, you can count my +1.

Oliver

Am 17.08.2011 07:44, schrieb Ralph Goers:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

I have also removed files that shouldn't be present in the Maven
repository from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph

Tag: https://svn.apache.org/repos/**asf/commons/proper/vfs/tags/**
commons-vfs2-project-2.0/https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
(revision 1158401).

Site:
http://people.apache.org/~**rgoers/commons-vfs/site/http://people.apache.org/~rgoers/commons-vfs/site/

Binaries:
http://people.apache.org/~**rgoers/commons-vfs/staged/http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the org.apache.commons-045
(u:rgoers, a:208.29.163.248) repository.

The Maven artifacts are at:

https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/
https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2-**examples/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/
https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2-**project/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/
https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2-**sandbox/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

and consist of

archetype-catalog.xml
commons-vfs2-examples-2.0-**javadoc.jar
commons-vfs2-examples-2.0-**sources.jar.asc
commons-vfs2-examples-2.0.pom
commons-vfs2-examples-2.0-**tests.jar
commons-vfs2-examples-2.0-**tests.jar.asc
commons-vfs2-examples-2.0.jar.**asc
commons-vfs2-examples-2.0.pom.**asc
commons-vfs2-examples-2.0-**javadoc.jar.asc
commons-vfs2-examples-2.0.jar
commons-vfs2-examples-2.0-**sources.jar
commons-vfs2-project-2.0.pom.**asc
commons-vfs2-project-2.0.pom
commons-vfs2-sandbox-2.0.pom.**asc
commons-vfs2-sandbox-2.0-**sources.jar.asc
commons-vfs2-sandbox-2.0-test-**sources.jar.asc
commons-vfs2-sandbox-2.0.jar
commons-vfs2-sandbox-2.0-**javadoc.jar
commons-vfs2-sandbox-2.0-test-**sources.jar
commons-vfs2-sandbox-2.0.jar.**asc
commons-vfs2-sandbox-2.0-**sources.jar
commons-vfs2-sandbox-2.0-**javadoc.jar.asc
commons-vfs2-sandbox-2.0-**tests.jar.asc
commons-vfs2-sandbox-2.0-**tests.jar
commons-vfs2-sandbox-2.0.pom
commons-vfs2-2.0.pom.asc
commons-vfs2-2.0-javadoc.jar
commons-vfs2-2.0-tests.jar.asc
commons-vfs2-2.0-tests.jar
commons-vfs2-2.0.pom
commons-vfs2-2.0.jar
commons-vfs2-2.0-sources.jar.**asc
commons-vfs2-2.0-test-sources.**jar.asc
commons-vfs2-2.0.jar.asc
commons-vfs2-2.0-sources.jar

[Math] New method: addToEntry in RealVector

2011-08-17 Thread Gilles Sadowski

Hi.

1. Is it OK to add an addToEntry method to RealVector? [There is one in
   AbstractRealMatrix.] Do I need to open a JIRA issue for this?
2. Are we going to remove the RealVector interface in favour of keeping
   only an abstract concrete class (AbstractRealVector) at the top of the
   hierarchy? [The class could be renamed RealVector.]


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

I didn't check, but for some reason I assumed that once I do a close that
I wouldn't be able to delete anything. But you are correct. I can do that so
I will as it is easier.

Ralph

On Wed, Aug 17, 2011 at 2:51 PM, sebb seb...@gmail.com wrote:

On 17 August 2011 20:55, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
Nope. That is my mistake. Maven generated them when it uploaded them to
the
Nexus staging repo. But I deleted that since we don't deliver them from
there. I then uploaded the artifacts from where they were built on my
machine to the directory on people.a.o rather than grabbing them from
Nexus,
which is what I should have done. I'll have to correct that.

Rather than copying them before the vote, you could leave the zip/tgz
archives in the Nexus staging area until the vote is complete.

Then, just before publishing the staging repo, copy the non-Maven
files to the dist/ directory and delete from staging.

Then release the staging area.

Saves at least one set of copying.

Ralph

On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger
oliver.he...@oliver-heger.de
wrote:

Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts
and site look good.

The only thing I am missing are md5 files. Are they required (other
components used to have them)? If not, you can count my +1.

Oliver

Am 17.08.2011 07:44, schrieb Ralph Goers:

This is a vote to release Apache Commons VFS 2.0.

Changes made since the last candidate:

* Fixed the manifest error that was causing the build to fail.
* Changed the copyright date in the Notice file from 2010 to 2011.
* Removed the references to javamail from the Notice file.
* Removed all the @version tags
* Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and
src/changes/announcement.vm (osgi/MANIFEST.MF has been removed).
* Modified the release notes to mention the code is not source
compatible
with VFS 1.x and that the package name changed.
* Fixed the WARNING for the use of the deprecated tasks element.
* Fixed the WARNING for the use of the deprecated systemProperties
element.
* Made sure all jars have NOTICE.txt and LICENSE.txt

I have also removed files that shouldn't be present in the Maven
repository from the staging repo.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because.

Ralph

Tag: https://svn.apache.org/repos/**asf/commons/proper/vfs/tags/**
commons-vfs2-project-2.0/
https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/
(revision 1158401).

Site: http://people.apache.org/~**rgoers/commons-vfs/site/
http://people.apache.org/~rgoers/commons-vfs/site/

Binaries: http://people.apache.org/~**rgoers/commons-vfs/staged/
http://people.apache.org/~rgoers/commons-vfs/staged/

The following artifacts have been staged to the org.apache.commons-045
(u:rgoers, a:208.29.163.248) repository.

The Maven artifacts are at:

https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/

https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2-**examples/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/

https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2-**project/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/

https://repository.apache.org/**content/groups/staging/org/**
apache/commons/commons-vfs2-**sandbox/
https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/

and consist of

Re: [Vote] Release Commons VFS 2.0

I'd prefer to not remove it from the modules list as that will also remove
it from the web site.

Ralph

On Wed, Aug 17, 2011 at 2:46 PM, sebb seb...@gmail.com wrote:

On 17 August 2011 20:43, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
The sandbox question I can't answer very well. The sandbox stuff was
there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

Can't you just remove it from the modules list?
That should stop Maven creating the jars at least.

In fact, if we are not releasing sandbox it really ought to be
disabled in the POM (perhaps via a profile)

it from there just like I did the distribution zips. If desired, I'd have
to
do another release to remove that source from the release. It would also
stay on the web site.

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com
wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so
in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and
I
had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.
Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed
or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.
Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate
(default-cli)
@
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do not know if I should -1 this because there are no build
instructions,
or if there are, they are located in some non-obvious spot.

Re: [Vote] Release Commons VFS 2.0

On 17 August 2011 23:17, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
I'd prefer to not remove it from the modules list as that will also remove
it from the web site.

But then surely source archive builds will fail?

Ralph

On Wed, Aug 17, 2011 at 2:46 PM, sebb seb...@gmail.com wrote:

On 17 August 2011 20:43, ralph.goers @dslextreme.com
ralph.go...@dslextreme.com wrote:
The sandbox question I can't answer very well. The sandbox stuff was
there
long before I arrived to work on VFS, although I rewrote the webdav stuff
and moved it to core. The only real description is on the web site under
File Systems where it says they under in development (not by me :-) ).

Can't you just remove it from the modules list?
That should stop Maven creating the jars at least.

In fact, if we are not releasing sandbox it really ought to be
disabled in the POM (perhaps via a profile)

it from there just like I did the distribution zips. If desired, I'd have
to
do another release to remove that source from the release. It would also
stay on the web site.

Ralph

On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com
wrote:

On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote:
What do you mean It did not work? This is a multi-project site so
in
general mvn site is useless. You have to run mvn site:stage-deply
-DstagingSiteURL=file url where I want the site to go. I suppose I
could
add that to the readme, but it is documented pretty well on the maven
site
plugin web site.

In a prior release candidate I wasn't generating the release notes and
I
had
the comment in the README. The release was vetoed due to the lack of
release notes. I simply forgot to delete the README.

Did you run announcement-generate from the core directory? That only
works
at the project root.

The build instructions consist of:

mvn clean install

Phil

Ralph

On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Hi All:

I am not sure if I am building correctly, but here is what I found.
Some
build instructions in the readme.txt file would help.

Downloaded source zip from
http://people.apache.org/~rgoers/commons-vfs/staged/

From the root I ran mvn site which did not work. Fine, starting to
poke
around.

From the dist directory I ran mvn site which did not work:

[INFO] Generating Dependency Management report ---
maven-project-info-reports-plugin:2.3.1
Downloading:

http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Error resolving
project
artifact: Failure to find
org.apache.commons:commons-vfs-examples:pom:2.0
in
http://r
epo1.maven.org/maven2 was cached in the local repository, resolution
will
not be reattempted until the update interval of central has elapsed
or
updates are for
ced for project org.apache.commons:commons-vfs-examples:pom:2.0
at

org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237)
at

org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252)

Why would building the site require an installed VFS2?

The README.txt says to run mvn changes:announcement-generate to get
release notes but there is a RELEASE-NOTES.txt file in the same dir.
Why
do
we need two?

When I do run mvn changes:announcement-generate, I get:

[INFO] --- maven-changes-plugin:2.4:announcement-generate
(default-cli)
@
commons-vfs2 ---
[WARNING] changes.xml file
C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist.

There is no such file.

I do

Re: [Math] New method: addToEntry in RealVector

On 8/17/11 3:14 PM, Gilles Sadowski wrote:
 Hi.

 1. Is it OK to add an addToEntry method to RealVector? [There is one in
AbstractRealMatrix.] Do I need to open a JIRA issue for this?
 2. Are we going to remove the RealVector interface in favour of keeping
only an abstract concrete class (AbstractRealVector) at the top of the
hierarchy? [The class could be renamed RealVector.]

+1 to go ahead and remove the interface and reclaim the name.  This
is a little scary, but now is the time to do these things.  I am
thinking about doing the same thing in lots of interface/impl splits
where we have only one impl.  If anyone is opposed to this, please
speak up now.  I think each such change should be tracked in a JIRA
and changes.xml so we have a record of the decision and the
associated commits.

Phil


 Regards,
 Gilles

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] iterator and sparseIterator in RealVector hierarchy

2011-08-17 Thread Greg Sterijevski

On symmetrics, diagonal, banded and so on, I disagree-as I have made clear
in the past. In the case of White standard errors or panel regressions, you
typically have long strings of multiplication by diagonals and symmetrics,
sandwich products and so forth. There are enough of these types of
operations that a math/stat library should support these forms of matrices.
isSparse() will not cut it. A symmetric matrix is typically NOT sparse, it
is typically dense in these cases. More importantly, the number of
operations you save by explicitly recognizing the special structure is not
insignificant.



 For banded arrays, the economies available beyond simple sparse algorithms
 are even more limited.


I am confused, Ted, since when I suggested that some of the multiplication
issues could solved by method overloading, you thought it would not work.
Probably a mis-communication on my part.


 Symmetric and triangular matrices also have special properties but it is
 hard to decide what is really important there.  Many of the special
 operations for these kinds of matrix are subject to solving by overloads
 instead of indicators since we aren't dealing with binary operations.  For
 example, left and right inverse multiplication with triangular matrices is
 handled by normal single dispatch and qualifying an argument for real
 Cholesky decomposition is specific to the Cholesky decomposition itself.


While on the discussion of extending RealMatrix in any direction, I would
humbly offer that the objects are too complex. Pardon this foolish question,
but what are the uses for the methods  double
walkInRowOrder(RealMatrixChangingVisitor visitor) When I think of having to
fill in all those methods for any extension, my head spins.

-Greg

Re: [Math] iterator and sparseIterator in RealVector hierarchy

On Wed, Aug 17, 2011 at 4:24 PM, Greg Sterijevski gsterijev...@gmail.comwrote:

 On symmetrics, diagonal, banded and so on, I disagree-as I have made clear
 in the past. In the case of White standard errors or panel regressions, you
 typically have long strings of multiplication by diagonals and symmetrics,
 sandwich products and so forth. There are enough of these types of
 operations that a math/stat library should support these forms of matrices.
 isSparse() will not cut it. A symmetric matrix is typically NOT sparse, it
 is typically dense in these cases. More importantly, the number of
 operations you save by explicitly recognizing the special structure is not
 insignificant.


I agree pretty much for the symmetric case.  The savings for banded matrices
is surprisingly small and you can have all of those savings as a left
operand.  It is the right operand where simple sparsity accounts for almost
everything.


  For banded arrays, the economies available beyond simple sparse
 algorithms
  are even more limited.
 
 
 I am confused, Ted, since when I suggested that some of the multiplication
 issues could solved by method overloading, you thought it would not work.
 Probably a mis-communication on my part.


No.  What I mean is that when a sparse matrix is the right operand and not
subject overloading due to dynamic typing, you get most of the advantages of
the fancy optimizations without any need for anything more than isSparse and
a sparse iterator.  You don't get all of the benefit, but you do get most of
it and you get it for a wide variety of left operands.


  Symmetric and triangular matrices also have special properties but it is
  hard to decide what is really important there.  Many of the special
  operations for these kinds of matrix are subject to solving by overloads
  instead of indicators since we aren't dealing with binary operations.
  For
  example, left and right inverse multiplication with triangular matrices
 is
  handled by normal single dispatch and qualifying an argument for real
  Cholesky decomposition is specific to the Cholesky decomposition itself.
 
 
 While on the discussion of extending RealMatrix in any direction, I would
 humbly offer that the objects are too complex. Pardon this foolish
 question,
 but what are the uses for the methods  double
 walkInRowOrder(RealMatrixChangingVisitor visitor) When I think of having
 to
 fill in all those methods for any extension, my head spins.


Exactly.  I think that you shouldn't need that.  The abstract super class
should have a moderately fancy operation that is limited to handling
generically sparse and dense matrices reasonably well and dense x dense
cases really well.  The writer of a new matrix type should not need to know
about that at all.

What I was suggesting is that if you have a leftInverseMultiply method that
solves for x in the system Ax = b, then that method knows the type of A
because the natural method call is A.leftInverseMultiply(b).  Thus, if A has
special structure, you get what you need from normal method dispatch.

It is the cases like A.times(b) or A.plus(b) that will be best supported by
generic sparsity support in the abstract class.

Re: [Math] New method: addToEntry in RealVector

Are you going to add addAndScale and all the other gazillion common mutators
as well?

Or should there just be a functional style interface where you say

   A.assign(Functions.plus(3.0))

to add 3 to all elements of a matrix or vector?

That would then allow

   A.assign(Functions.ABS)

or

   A.assign(Functions.times(0.3))

This allows one method to serve many, many purposes, including those that
are not yet known.

Similar logic leads to a family of assign methods and also some aggregate
methods.  The resulting flexibility and parsimony is very nice.

On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski 
gil...@harfang.homelinux.org wrote:

 1. Is it OK to add an addToEntry method to RealVector? [There is one in

Re: [Vote] Release Commons VFS 2.0

2011-08-17 Thread Ralph Goers


On Aug 17, 2011, at 3:27 PM, sebb wrote:

 On 17 August 2011 23:17, ralph.goers @dslextreme.com
 ralph.go...@dslextreme.com wrote:
 I'd prefer to not remove it from the modules list as that will also remove
 it from the web site.
 
 But then surely source archive builds will fail?

Yeah. I'll have to think about that. I hate it when you make me think. 

So somehow the site build should include the module and the rest of the time it 
is not enabled.

Ralph
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Vote] Release Commons VFS 2.0

On 18 August 2011 01:09, Ralph Goers ralph.go...@dslextreme.com wrote:

 On Aug 17, 2011, at 3:27 PM, sebb wrote:

 On 17 August 2011 23:17, ralph.goers @dslextreme.com
 ralph.go...@dslextreme.com wrote:
 I'd prefer to not remove it from the modules list as that will also remove
 it from the web site.

 But then surely source archive builds will fail?

 Yeah. I'll have to think about that. I hate it when you make me think.

 So somehow the site build should include the module and the rest of the time 
 it is not enabled.

Try using a profile to enable it, and ensure you enable the profile
when building the site, but not when building the artifacts.

 Ralph
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] StorelessCovariance

2011-08-17 Thread Greg Sterijevski

I am building in Netbeans and I believe that Luc is correct. I initially had
problems until I included the junit.jar. (junit-4.8.2.jar)

PS What is your approach to the covariance matrix? Are you building a sum of
squares matrix or keeping updates of the mean, ... etc?

On Wed, Aug 17, 2011 at 1:22 PM, Luc Maisonobe luc.maison...@free.frwrote:

Hi Patrick,

Le 17/08/2011 18:15, Patrick Meyer a écrit :

I am workin on the StorelessCovariance per jira MATH-449. However, I'm
having a hard time using subversion via Netbeans. I have successfully
created the new classes and a JUnit test. However, when I run the test I
get the following message,

caused an ERORR: Absent Code attribute in method that is not native or
abstract in class file org/apache/commons/math/**TestUtils

Do you have a complete implementation of JUnit in your classpath or only
the top level API ?

It seems similar to this: http://www.andrejkoelewijn.**
com/wp/2010/03/04/absent-code-**attribute-in-method-that-is-**
not-native-or-abstract/http://www.andrejkoelewijn.com/wp/2010/03/04/absent-code-attribute-in-method-that-is-not-native-or-abstract/
or this http://dominikdorn.com/2010/**05/maven-junit-**
classformaterror-absent-code-**attribute/http://dominikdorn.com/2010/05/maven-junit-classformaterror-absent-code-attribute/
and hence elated to API and implementation separation.

Apache Commons Math does not have any runtime dependency and the only test
time dependency is JUnit.

Luc

Any help would be appreciated. I have a lot to contribute to commons
math but my lack of experience with subversion is really hindering me.

Thanks,
Patrick

--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] New method: addToEntry in RealVector

2011-08-17 Thread Greg Sterijevski

Shocking as this may seem! ;-) I like Ted's suggestion. Very clean, an
appropriate use of OO and something for which the penalty is not great, but
the benefit humongous! +1 for functional/functor approach.



On Wed, Aug 17, 2011 at 6:44 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 Are you going to add addAndScale and all the other gazillion common
 mutators
 as well?

 Or should there just be a functional style interface where you say

   A.assign(Functions.plus(3.0))

 to add 3 to all elements of a matrix or vector?

 That would then allow

   A.assign(Functions.ABS)

 or

   A.assign(Functions.times(0.3))

 This allows one method to serve many, many purposes, including those that
 are not yet known.

 Similar logic leads to a family of assign methods and also some aggregate
 methods.  The resulting flexibility and parsimony is very nice.

 On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski 
 gil...@harfang.homelinux.org wrote:

  1. Is it OK to add an addToEntry method to RealVector? [There is one
 in

Re: [math] StorelessCovariance

2011-08-17 Thread Patrick Meyer

OK, after fidgeting with NetBeans for too long without results, I went 
with Phil's suggestion and just used subversion at the command prompt. 
It was much easier than trying to configure NetBeans.


I uploaded the patch this evening. It includes two new classes 
StorelessCovariance.java and StorelessCovarianceMatrix.java. I also 
included a new test class StorelessCovarianceTest.java.


Interestingly, the one-pass algorithm is slightly less accurate than the 
two-pass algorithm. I had to reduce the tolerance from 10E-9 to 10E-7 in 
order for tests to pass with the Longley data. The tolerance was not 
changed for the Swiss data. It remained 10E-13 for the Swiss data.


The one-pass algorithm is described in a paper by Pebay (2008) 
http://prod.sandia.gov/techlib/access-control.cgi/2008/086212.pdf


Thanks for everyone's help.

Patrick



On 8/17/2011 12:13 PM, Patrick wrote:
I am workin on the StorelessCovariance per jira MATH-449. However, I'm 
having a hard time using subversion via Netbeans. I have successfully 
created the new classes and a JUnit test. However, when I run the test 
I get the following message,


caused an ERORR: Absent Code attribute in method that is not native 
or abstract in class file org/apache/commons/math/TestUtils


Any help would be appreciated. I have a lot to contribute to commons 
math but my lack of experience with subversion is really hindering me.


Thanks,
Patrick



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] StorelessCovariance

NetBeans is kind of wasting away for lack of attention.

IntelliJ generally gets these things exactly correct. SVN, git and mvn are
all mother tongues for it. There is an excellent community edition and
Apache committers can get a full version.

On Wed, Aug 17, 2011 at 8:09 PM, Patrick Meyer meyer...@gmail.com wrote:

OK, after fidgeting with NetBeans for too long without results, I went with
Phil's suggestion and just used subversion at the command prompt. It was
much easier than trying to configure NetBeans.

I uploaded the patch this evening. It includes two new classes
StorelessCovariance.java and StorelessCovarianceMatrix.**java. I also
included a new test class StorelessCovarianceTest.java.

Interestingly, the one-pass algorithm is slightly less accurate than the
two-pass algorithm. I had to reduce the tolerance from 10E-9 to 10E-7 in
order for tests to pass with the Longley data. The tolerance was not changed
for the Swiss data. It remained 10E-13 for the Swiss data.

The one-pass algorithm is described in a paper by Pebay (2008)
http://prod.sandia.gov/**techlib/access-control.cgi/**2008/086212.pdfhttp://prod.sandia.gov/techlib/access-control.cgi/2008/086212.pdf

Thanks for everyone's help.

Patrick

On 8/17/2011 12:13 PM, Patrick wrote:

caused an ERORR: Absent Code attribute in method that is not native or
abstract in class file org/apache/commons/math/**TestUtils

Any help would be appreciated. I have a lot to contribute to commons math
but my lack of experience with subversion is really hindering me.

Thanks,
Patrick

--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] New method: addToEntry in RealVector