Re: [Math] New method: "addToEntry" in "RealVector"

[Ted Dunning]

Credit where it is due: this style of API was a major characteristic of Colt
and Mahout inherited this style (to our benefit).

On Wed, Aug 17, 2011 at 6:41 PM, Greg Sterijevski wrote:

> 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 
> 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

[Ted Dunning]

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  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.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-unsubscribe@commons.**apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] StorelessCovariance

[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] New method: "addToEntry" in "RealVector"

[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  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

[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 wrote:

> 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:  com/wp/2010/03/04/absent-code-**attribute-in-method-that-is-**
> not-native-or-abstract/>
> or this  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.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Vote] Release Commons VFS 2.0

[sebb]

On 18 August 2011 01:09, Ralph Goers  wrote:
>
> On Aug 17, 2011, at 3:27 PM, sebb wrote:
>
>> On 17 August 2011 23:17, ralph.goers @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: [Vote] Release Commons VFS 2.0

[Ralph Goers]

On Aug 17, 2011, at 3:27 PM, sebb wrote:

> On 17 August 2011 23:17, ralph.goers @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: [Math] New method: "addToEntry" in "RealVector"

[Ted Dunning]

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] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Ted Dunning]

On Wed, Aug 17, 2011 at 4:24 PM, Greg Sterijevski wrote:

> 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] "iterator" and "sparseIterator" in "RealVector" hierarchy

[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] New method: "addToEntry" in "RealVector"

[Phil Steitz]

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: [Vote] Release Commons VFS 2.0

[sebb]

On 17 August 2011 23:17, ralph.goers @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  wrote:
>
>> On 17 August 2011 20:43, 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
>>
>> 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 
>> 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.
>> >>
>> >> 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 > >> >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?
>> >> >>
>> >> >> Th

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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  wrote:

> On 17 August 2011 20:43, 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
>
> 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 
> 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.
> >>
> >> 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  >> >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 g

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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  wrote:

> On 17 August 2011 20:55, ralph.goers @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
> >>>
> >>> 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-**s

[Math] New method: "addToEntry" in "RealVector"

[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

[sebb]

On 17 August 2011 20:55, ralph.goers @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 > 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/
>>>  (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.

Re: [Vote] Release Commons VFS 2.0

[sebb]

On 17 August 2011 20:43, 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

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  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.
>>
>> 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 > >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: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Matthew Pocock]

Also, for matrices, is the internal storage optimized for row-major access
or column-major access? Perhaps you can get a sparse iterator over the major
dimension which returns a dense iterator over the minor, or a sparse iteator
over all cells. What you expose boils down to what it is about the matrix or
vector that you need to discover to be able to implement binary ops
efficiently enough. As Java doesn't have multiple-dispatch, I don't really
know a completely clean way to deal with this.

I also agree with Ted. The contract for sparse iteration should be that it
can optionally skip returning zero entries. There may be cases when it's
cheaper to store some zeros even if you use some sort of skip-list structure
internally.

Matthew

On 17 August 2011 19:28, Arne Ploese  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  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  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-nai

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

Sorry, yes.

Ralph

On Wed, Aug 17, 2011 at 1:33 PM, Luc Maisonobe wrote:

> 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 Steitz
>>  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.

>>>
>>> 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:
>>>
>>> 
>>>  src
>>>  
>>>**/mantissa/**
>>>**/experimental/**
>>>  
>>> 
>>>
>>> Phil
>>>

 Ralph


 On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz

>>> 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.
>
> 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> 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
>
>> 

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

[Dave Brosius]

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

Re: [Vote] Release Commons VFS 2.0

[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 Steitz  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.


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:


  src
  
**/mantissa/**
**/experimental/**
  


Phil


Ralph


On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz

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.

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
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 kno

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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  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.
>
> 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:
>
> 
>  src
>  
>**/mantissa/**
>**/experimental/**
>  
> 
>
> Phil
> >
> > Ralph
> >
> >
> > On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz 
> 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.
> >>
> >> 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  >>> 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 VFS

[lang?] Converting an array to an Iterable

[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

[Phil Steitz]

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.

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:


  src
  
**/mantissa/**
**/experimental/**
  


Phil
>
> Ralph
>
>
> On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz  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.
>>
>> 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 >> 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

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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  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/
>>  (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-unsubscribe@commons.**apache.org
> For additiona

Re: [Vote] Release Commons VFS 2.0

[Phil Steitz]

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

[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

[ralph.goers @dslextreme.com]

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  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.
>
> 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  >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 javamai

Re: [Vote] Release Commons VFS 2.0

[Phil Steitz]

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 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 >> 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 be

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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  wrote:
>
>> On 17 August 2011 19:37, ralph.goers @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 > >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.
>>  > * 

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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  wrote:

> On 17 August 2011 19:37, ralph.goers @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  >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.
> 

Re: [Vote] Release Commons VFS 2.0

[sebb]

On 17 August 2011 19:37, ralph.goers @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 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 >>> >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
 > fro

Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Ted Dunning]

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  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  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  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
> > >

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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:
>
>> 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 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 >> >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
>>

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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 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 > >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/co

Re: [Vote] Release Commons VFS 2.0

[ralph.goers @dslextreme.com]

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 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  >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/comm

Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Arne Ploese]

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  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  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 
> > > > 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 probl

Re: [math] StorelessCovariance

[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: 
 
or this 
 
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

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

[Continuum@vmbuild]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11393&projectId=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: [chain] Apache Chain v2 Proof of Concept

[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  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  
> 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  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  
>>> 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 Command {
 ...
    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

[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  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  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  
>> 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 Command {
>>> ...
>>>    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

[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  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  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 Command {
>> ...
>>    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

[math] StorelessCovariance

[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: [math] StorelessCovariance

[Phil Steitz]

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

[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] "iterator" and "sparseIterator" in "RealVector" hierarchy

[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  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  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 
> > > 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
> > > > > >
> > > 

Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Arne Ploese]

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  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 
> > 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.com>wrote:
> > > > >>
> > > > >>> 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:
> > > >

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

[sebb]

On 17 August 2011 16:09, sebb  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()
contains

Overrides:
add in class AbstractQueue

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: [POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque

[Gary Gregory]

+1, who's on first again?

Gary

On Wed, Aug 17, 2011 at 11:09 AM, sebb  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: [Vote] Release Commons VFS 2.0

[Gary Gregory]

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 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
> 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-

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

[sebb]

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: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Ted Dunning]

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  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 
> 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.com>wrote:
> > > >>
> > > >>> 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 uns

Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Ted Dunning]

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.

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

[Continuum@vmbuild]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11377&projectId=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 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(Suref

Re: [codec] Encoder / Decoder interface

[sebb]

On 17 August 2011 13:58, Stephen Colebourne  wrote:
> On 17 August 2011 13:44, Matthew Pocock  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 Encoder 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 Encoder. 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  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

Re: [codec] Encoder / Decoder interface

[Gary Gregory]

Hi All:

On Wed, Aug 17, 2011 at 8:58 AM, Stephen Colebourne wrote:

> On 17 August 2011 13:44, Matthew Pocock 
> 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 Encoder 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 Encoder. Its shorter and clearer.
>

What about SymmetricEncoder?

[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  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

[Gary Gregory]

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 Encoder 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 Encoder with "O encode(I)" and
interface SymmerticEncoder extends Encoder
interface StringEncoder extends SymmerticEncoder

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 Encoder if we wished.
> The problem with this is that not every Encoder 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
> Encoder>. 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 Encoder Object>, Encoder.


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 Encoder {
>  public ENC encode(DEC dec);
> }
>
> ## javap
> public interface Encoder{
>
>public abstract java.lang.Object encode(java.lang.Object);
>
> }
>
> ## java
> public interface StringEncoder extends Encoder {}
>
> ## javap
> public interface StringEncoder extends Encoder{
>
> }
>
> ## java
> public class IdE implements Encoder {
>  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 Encoder {
>  @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  wrote:
>
> > On Aug 16, 2011, at 23:47, sebb  wrote:
> >
> > > On 17 August 2011 04:30, Gary Gregory  wrote:
> > >> On Tue, Aug 16, 2011 at 11:14 PM, sebb  wrote:
> > >
> > > ...
> > >
> > >> FYI:
> > >>

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

[sebb]

On 17 August 2011 13:50, Luc Maisonobe  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

[Matthew Pocock]

On 17 August 2011 13:58, Stephen Colebourne  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: [codec] Encoder / Decoder interface

[Stephen Colebourne]

On 17 August 2011 13:44, Matthew Pocock  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 Encoder 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 Encoder. Its shorter and clearer.
Overall, I'd say focus users on the concrete versions like StringEncoder.

On 16 August 2011 21:38, Gary Gregory  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: [VOTE][DAEMON] release 1.0.6 and 1.0.7 Maven artifacts

[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

[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 Encoder 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 Encoder if we wished.
The problem with this is that not every Encoder 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
Encoder>. 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 Encoder, Encoder. 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 Encoder {
  public ENC encode(DEC dec);
}

## javap
public interface Encoder{

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

}

## java
public interface StringEncoder extends Encoder {}

## javap
public interface StringEncoder extends Encoder{

}

## java
public class IdE implements Encoder {
  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 Encoder {
  @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  wrote:

> On Aug 16, 2011, at 23:47, sebb  wrote:
>
> > On 17 August 2011 04:30, Gary Gregory  wrote:
> >> On Tue, Aug 16, 2011 at 11:14 PM, sebb  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
> >> org.apache.commons.codec.net.URLCodecpublic java.lang.String
> getEncoding()
> >
> > DIfficult to read, but looks like the Clirr repo

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

[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: [compress] close() and archives/streams in an invalid state

[Honton, Charles]

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.  (A new class
for commons-io?)

Chas Honton


On 8/16/11 11:16 PM, "sebb"  wrote:

>On 17 August 2011 03:42, Stefan Bodewig  wrote:
>> On 2011-08-15, sebb wrote:
>>
>>> On 15 August 2011 09:56, Stefan Bodewig  wrote:
 Hi,
>>
 while working on the Zip64 stuff I deliberately created some invalid
 archives to test I get the expected exceptions.  While doing so I
 realized I couldn't close the underlying stream because
 ZipArchiveOutputStream's close would throw an exception as finish()
 failed before ever closing the wrapped stream.  The calling code may
not
 even have a handle to the underlying stream if it used the File-arg
 constructor and so in the end a broken archive leaks the file
 descriptor.
>>
 Then I went looking through the other implementations and found we are
 consistent here as far as archivers and bzip2 go.  All of them will
not
 close the underlying stream if the archive/stream is invalid.  I'm not
 sure what gzip does as it just delegates to close in the Java
classlib's
 GZipOutputStream.
>>
 I wonder whether we should rather change the behavior to always close
 the underlying stream or whether we should add a new method - I called
 in destroy in ZipArchiveOutputStream - that does so.
>>
 Or maybe we just document it for 1.3, add destroy as a non-common
method
 where needed (like in ZIP, in all other cases the user code should
have
 access to the underlying stream) - and revisit this in the 2.x
 timeframe, even though I can't see what could be broken by always
 closing the stream in a finally block.
>>
 Does anybody see a good reason why the close behavior should stay the
 way it is right now?
>>
>>> For output, it seems sensible to close the underlying stream on
>>> failure, as the content is likely to be garbage.
>>
>> Yes, this is the case I was talking about.
>>
>>> For input, there might be a use case for leaving the stream open, in
>>> case some kind of recovery is possible.
>>
>> All our implementations - except for the new dump code, that doesn't
>> properly handle close ATM - try to close the input stream regardless of
>> whether there has been a problem with the archive or not (they don't
>> even check).  This is what I'd expect it to do as well.
>>
>> Some of the guard against closing System.in, but not all.
>>
>>> 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.
>
>> 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
>


-
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

[sebb]

On 17 August 2011 06:18, Stefan Bodewig  wrote:
> On 2011-08-17, sebb wrote:
>
>> On 17 August 2011 03:42, Stefan Bodewig  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: svn commit: r1158504 - /commons/trunks-proper/

[sebb]

On 17 August 2011 05:38, Stefan Bodewig  wrote:
> On 2011-08-17,  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: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[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

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

[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: 
http://vmgump.apache.o

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

[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] 
-

Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Arne Ploese]

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  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.com>wrote:
> > >>
> > >>> 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 
> > >>> 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

Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy

[Arne Ploese]

Ted,

please just take your code and move Iterator 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  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.com>wrote:
> > >>
> > >>> 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 
> > >>> 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

Re: [bcel] Backwards Incompatible Change to Visitor

[Torsten Curdt]

On Wed, Aug 17, 2011 at 8:06 AM, Stefan Bodewig  wrote:
> Hi,
>
> with svn revision 1158060 the bcel.generic.Visitor interface has become
> package private, breaking the Gump builds of Xalan XSLTC,
> commons-javaflow and likely other downstream code.

Gump is so cool :)

cheers,
Torsten

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

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

[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-email has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 174 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-email :  Commons Email Package


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/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-email-*[0-9T].jar] identifier set to project 
name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/email/pom.xml
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/gump_work/build_apache-commons_commons-email.html
Work Name: build_apache-commons_commons-email (Type: Build)
Work ended in a state of : Failed
Elapsed: 38 secs
Command Line: /opt/maven2/bin/mvn --batch-mode 
-Dmaven.jar.mail=/srv/gump/packages/javamail-1.4/mail.jar --settings 
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/email]
M2_HOME: /opt/maven2
-
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.439 sec
Running org.apache.commons.mail.EmailLiveTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.241 sec
Running org.apache.commons.mail.SendWithAttachmentsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec
Running org.apache.commons.mail.DataSourceResolverTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.mail.util.MimeMessageParserTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.121 sec
Running org.apache.commons.mail.EmailTest
Tests run: 40, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.227 sec
Running org.apache.commons.mail.EmailAttachmentTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.259 sec
Running org.apache.commons.mail.ImageHtmlEmailTest
Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.176 sec <<< 
FAILURE!
Running org.apache.commons.mail.DefaultAuthenticatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.mail.util.URLFactoryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.mail.SimpleEmailTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.mail.MultiPartEmailTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec
Running org.apache.commons.mail.InvalidInternetAddressTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.mail.InvalidAddressTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec

Results :

Failed tests: 
  testSendHtml(org.apache.commons.mail.ImageHtmlEmailTest)

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/email/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 37 seconds
[INFO] Finished at: Wed Aug 17 07:50:26 UTC 2011
[INFO] Final Memory: 32M/78M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 06000617082011, vmgump.apache.org:vmgump:06000617082011
Gump E-mail Identifi