Re: [math] Strange svn conflict

[Daniel Shahaf]

> > - How to reproduce the errors you saw?  Can you show the output of `svn
> >  diff` at the time of a failed commit attempt?
> >
> I hope this mailing list allows for attachements, in which case you
> will find attached the patch I've been trying to commit for several
> days now. It is a rather large patch, but I don't think that this is
> the cause for our current troubles, since I've tried to commit only a
> small piece and it did not work either.
> 
> Just to be sure the trouble was still occuring, I've just tried to
> commit these changes, and here is what I get.
> 
> org.tigris.subversion.javahl.ClientException: Merge conflict during commit

(this is a server-side error SVN_ERR_FS_CONFLICT; it has nothing to do
with 'svn merge')

> svn: Commit failed (details follow):
> svn: File or directory
> 'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
> is out of date; try updating
> svn: resource out of date; try updating

You probably recognize this error as the one meaning 'run "svn update"
and try the commit again.  ("update" needs to be run on the containing
directory, not only on the files in question.)'  However, you remarked
earlier that you also get this error if you 'rm -rf' your working copy
and try to commit from a new one, right?

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

Re: [math] Strange svn conflict

[Daniel Shahaf]

Sébastien Brisard wrote on Mon, Dec 26, 2011 at 19:00:48 +0100:
> >
> > - Why would the N other files have been committed in that revision?
> >  Recall that those files had no text changes and their property lists
> >  were re-set to the values they already had.
> >
> I now recall what hapened at that time. As of r1206451 (see
> MATH-711), interface files xxxDistribution.java and default
> implementation xxxDistributionImpl.java have been merged. I did this
> piece of refactoring with Eclipse, and realized later that during the
> process, all SVN properties had gone. Or so it appeared in Eclipse
> (since you wrote that the properties had not really gone).
> 
> So r1210359 had two purposes
> 1. restore the SVN properties,
> 2. solve MATH-715 (which resulted in "real" modifications of
> PascalDistribution.java).
> I hope I am not the one to blame for the current mess. I now realize
> that I should have operated the refactoring outside Eclipse, using SVN
> to remove the interface files, and rename the implementation files.

You should tell svn about add/remove/rename operations, yes.  I suppose
eclipse would do that for you if you had an svn plugin (eg, subclipse)
installed.

The revision in question does not contain any renames, adds, or deletes.

> Also I should have used SVN as a command-line tool to check for the
> presence of the SVN properties.

Well, only if you suspected eclipse was lying to you. :)

> Again, I hope I did not cause too much
> damage. What can I do to try and repair that?
> 

Nothing, really; the revision is fine on both mirrors so I'll let it
stay this way.  What you could do is mainly ensuring this doesn't happen
again --- such as telling us how to reproduce those revisions with bogus
'log -qv' outputs.  (That's definitely a bug, and needs to be fixed.)

> >
> > - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
> >  commit.  The servers ran 1.7.0.  My client was 1.7.0 too.
> >
> Actually, I'm using this time
> svn --version
> svn, version 1.6.17 (r1128011)
>compiled Aug 25 2011, 17:51:49
> 

Yes, that's the version of the cmdline client that you use.  But the
error you pasted above ("org.tigris.subversion.javahl.ClientException")
indicates that you use at least one other client, and that's where the
SVNKit version comes in.

> Should I move to svn 1.7 ?
> 

You could try moving to 1.7, and/or using the official JavaHL bindings
instead of the third-party SVNKit implementation.  With my svn hat on,
though, I'd like to figure out how those revisions with bogus 'log -qv'
output were created, and if you have the time to provide a self-contained
reproduction recipe (starting with 'svnadmin create', and svn and/or
eclipse) we'd appreciate it.

> >
> > As to the diagnosis:
> >
> > - The non-functional propchanges should have been collapsed and removed
> >  before or during the commit.  This should happen within the FS
> >  backend: the changed-paths information should not list such files with
> >  'prop_mod=TRUE'.  I'm not sure if other layers should do such
> >  collapsing too.
> >
> I'm sorry this is far out of my league... But I do hope that I've
> answered your questions.

Yeah, that was aimed at the svn devs reading this list. :)

[ I trimmed some parts -- will reply to them later ]


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

Re: [ALL][VOTE] Rename Commons Sanselan to Commons Image

[Jochen Wiedmann]

2011/12/22 Sébastien Brisard :
> Hello,
> I am no native english speaker, but it seems to me that
> commons-imaging would suggest image analysis tools, while (as far as I
> know) sanselan is devoted to IO. In which case, maybe commons-imageio
> would be better suited?

Although you are possibly right with regards to the projects current
state, I see no necessity to indicate restrictions in the name. So I'd
consider "imaging" a perfectly valid name.

+1 to that

Jochen

-- 
“Morality is doing what is right, no matter what you are told.
Religion is doing what you are told, no matter what is right.”

H. L. Mencken (c.1925)

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

Re: [ALL][VOTE] Rename Commons Sanselan to Commons Image

[Gary Gregory]

and from +1, for "Commons ImageIO" or "Commons Imaging". I'll tally this
thread.

Gary

On Tue, Dec 27, 2011 at 1:00 PM, Jochen Wiedmann
wrote:

> 2011/12/22 Sébastien Brisard :
> > Hello,
> > I am no native english speaker, but it seems to me that
> > commons-imaging would suggest image analysis tools, while (as far as I
> > know) sanselan is devoted to IO. In which case, maybe commons-imageio
> > would be better suited?
>
> Although you are possibly right with regards to the projects current
> state, I see no necessity to indicate restrictions in the name. So I'd
> consider "imaging" a perfectly valid name.
>
> +1 to that
>
> Jochen
>
> --
> “Morality is doing what is right, no matter what you are told.
> Religion is doing what you are told, no matter what is right.”
>
> H. L. Mencken (c.1925)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[RESULT][ALL][VOTE] Rename Commons Sanselan to Commons Image

[Gary Gregory]

Part 1: This vote passes.
Part 2: New name: Commons Imaging

Part 1: This vote passes.

6 PMC +1s:
Emmanuel Bourg: Commons Imaging
Jörg Schaible: Commons Image
Henri Biestro: Commons Image
James Carman: Commons Imaging
Jochen Wiedmann: Commons Imaging
Gary Gregory: Commons Imaging or Commons ImageIO

3 PMC positive replies (but not "+1"):
Matt Benson: Commons Imaging
Sebastian Bazley: Commons Imaging, Commons ImageIO
Simone Tripodi: Commons ImageIO

3 Non-PMC positives:
Christian Grobmeier: Commons ImageIO
Damjan Jovanovic: Commons Imaging
Konstantin Kolinko: Commons Imaging

-0:
Paul Benedict

-1s:
Mark Thomas (PMC)

PMC = http://commons.apache.org/team-list.html

Part 2: New name.

Commons Imaging: 6
Commons ImageIO: 4
Commons Image: 2

Gary

On Tue, Dec 27, 2011 at 1:32 PM, Gary Gregory wrote:

> and from +1, for "Commons ImageIO" or "Commons Imaging". I'll tally this
> thread.
>
> Gary
>
>
> On Tue, Dec 27, 2011 at 1:00 PM, Jochen Wiedmann <
> jochen.wiedm...@gmail.com> wrote:
>
>> 2011/12/22 Sébastien Brisard :
>> > Hello,
>> > I am no native english speaker, but it seems to me that
>> > commons-imaging would suggest image analysis tools, while (as far as I
>> > know) sanselan is devoted to IO. In which case, maybe commons-imageio
>> > would be better suited?
>>
>> Although you are possibly right with regards to the projects current
>> state, I see no necessity to indicate restrictions in the name. So I'd
>> consider "imaging" a perfectly valid name.
>>
>> +1 to that
>>
>> Jochen
>>
>> --
>> “Morality is doing what is right, no matter what you are told.
>> Religion is doing what you are told, no matter what is right.”
>>
>> H. L. Mencken (c.1925)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [math] Strange svn conflict

[Sébastien Brisard]

Le 27 décembre 2011 13:56, Daniel Shahaf  a écrit :
> Sébastien Brisard wrote on Mon, Dec 26, 2011 at 19:00:48 +0100:
>> >
>> > - Why would the N other files have been committed in that revision?
>> >  Recall that those files had no text changes and their property lists
>> >  were re-set to the values they already had.
>> >
>> I now recall what hapened at that time. As of         r1206451 (see
>> MATH-711), interface files xxxDistribution.java and default
>> implementation xxxDistributionImpl.java have been merged. I did this
>> piece of refactoring with Eclipse, and realized later that during the
>> process, all SVN properties had gone. Or so it appeared in Eclipse
>> (since you wrote that the properties had not really gone).
>>
>> So r1210359 had two purposes
>> 1. restore the SVN properties,
>> 2. solve MATH-715 (which resulted in "real" modifications of
>> PascalDistribution.java).
>> I hope I am not the one to blame for the current mess. I now realize
>> that I should have operated the refactoring outside Eclipse, using SVN
>> to remove the interface files, and rename the implementation files.
>
> You should tell svn about add/remove/rename operations, yes.  I suppose
> eclipse would do that for you if you had an svn plugin (eg, subclipse)
> installed.
>
I'm actually not sure about that. For the record, I *do* use
subclipse, but I found it sometimes unreliable: I would sometimes be
unable to commit from within Eclipse+subclipse, while commiting from
the command-line would work perfectly. I wonder if other people have
already come across this issue.

>
> The revision in question does not contain any renames, adds, or deletes.
>
>> Also I should have used SVN as a command-line tool to check for the
>> presence of the SVN properties.
>
> Well, only if you suspected eclipse was lying to you. :)
>
see above ;)

>> Again, I hope I did not cause too much
>> damage. What can I do to try and repair that?
>>
>
> Nothing, really; the revision is fine on both mirrors so I'll let it
> stay this way.  What you could do is mainly ensuring this doesn't happen
> again --- such as telling us how to reproduce those revisions with bogus
> 'log -qv' outputs.  (That's definitely a bug, and needs to be fixed.)
>
>> >
>> > - You used "SVN/1.6.15 SVNKit/1.3.5 (http://svnkit.com/) r7406" in that
>> >  commit.  The servers ran 1.7.0.  My client was 1.7.0 too.
>> >
>> Actually, I'm using this time
>> svn --version
>> svn, version 1.6.17 (r1128011)
>>    compiled Aug 25 2011, 17:51:49
>>
>
> Yes, that's the version of the cmdline client that you use.  But the
> error you pasted above ("org.tigris.subversion.javahl.ClientException")
> indicates that you use at least one other client, and that's where the
> SVNKit version comes in.
>
>> Should I move to svn 1.7 ?
>>
>
> You could try moving to 1.7, and/or using the official JavaHL bindings
> instead of the third-party SVNKit implementation.  With my svn hat on,
> though, I'd like to figure out how those revisions with bogus 'log -qv'
> output were created, and if you have the time to provide a self-contained
> reproduction recipe (starting with 'svnadmin create', and svn and/or
> eclipse) we'd appreciate it.
>
I'll try my best to do that.

>> >
>> > As to the diagnosis:
>> >
>> > - The non-functional propchanges should have been collapsed and removed
>> >  before or during the commit.  This should happen within the FS
>> >  backend: the changed-paths information should not list such files with
>> >  'prop_mod=TRUE'.  I'm not sure if other layers should do such
>> >  collapsing too.
>> >
>> I'm sorry this is far out of my league... But I do hope that I've
>> answered your questions.
>
> Yeah, that was aimed at the svn devs reading this list. :)
>
> [ I trimmed some parts -- will reply to them later ]
>

Thanks,
Sébastien

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

Re: [math] Strange svn conflict

[Sébastien Brisard]

Hi,

Le 27 décembre 2011 14:06, Daniel Shahaf  a écrit :
>> > - How to reproduce the errors you saw?  Can you show the output of `svn
>> >  diff` at the time of a failed commit attempt?
>> >
>> I hope this mailing list allows for attachements, in which case you
>> will find attached the patch I've been trying to commit for several
>> days now. It is a rather large patch, but I don't think that this is
>> the cause for our current troubles, since I've tried to commit only a
>> small piece and it did not work either.
>>
>> Just to be sure the trouble was still occuring, I've just tried to
>> commit these changes, and here is what I get.
>>
>> org.tigris.subversion.javahl.ClientException: Merge conflict during commit
>
> (this is a server-side error SVN_ERR_FS_CONFLICT; it has nothing to do
> with 'svn merge')
>
>> svn: Commit failed (details follow):
>> svn: File or directory
>> 'main/java/org/apache/commons/math/distribution/BinomialDistribution.java'
>> is out of date; try updating
>> svn: resource out of date; try updating
>
> You probably recognize this error as the one meaning 'run "svn update"
> and try the commit again.  ("update" needs to be run on the containing
> directory, not only on the files in question.)'  However, you remarked
> earlier that you also get this error if you 'rm -rf' your working copy
> and try to commit from a new one, right?
>

That's correct. I did update on the directory, as well as checkout a
brand new working copy of Commons-Math.
Was the attached patch of any use to you?
Sébastien

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

Re: [Math] Naming confusion

[J.Pietschmann]

Am 28.10.2011 23:30, schrieb Gilles Sadowski:
> I think that something is not quite right in those class names:
...
>  2. assume that the "number" type is "Real", and drop it everywhere:
The "Real" was included (a lng time ago because implementations for
complex numbers were assumed to appear. Apparently, this didn't happen.

J.Pietschmann


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

[GUMP@vmgump]: Project commons-exec-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-exec-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-exec-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
FOO..
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.025 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.028 ms
Process completed in 2005 millis; below is its output
Process timed out and was killed by watchdog.
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2005 millis; below is its output
Process timed out and was killed.
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Executing [sh, -c, src/test/scripts/invoker.sh]
invoker.sh -- going to start daemon process
invoker.sh --  daemon process was started
cd: 21: can't cd to ../../../target
Process completed in 8016 millis; above is its output
0: process has terminated: false
1: process has terminated: false
2: process has terminated: false
3: process has terminated: false
4: process has terminated: false
5: process has terminated: false
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.81 sec <<< 
FAILURE!

Results :

Failed tests: 
  testExec_60(org.apache.commons.exec.DefaultExecutorTest)

Tests run: 95, 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/exec/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 22 seconds
[INFO] Finished at: Wed Dec 28 02:21:16 UTC 2011
[INFO] Final Memory: 25M/65M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1228122011, vmgump.apache.org:vmgump:1228122011
Gump E-mail Identifier (unique within run) #18.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

[GUMP@vmgump]: Project commons-sanselan-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-sanselan-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-sanselan-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-sanselan-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/sanselan/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/sanselan/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/sanselan/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/sanselan/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-sanselan-test/gump_work/build_apache-commons_commons-sanselan-test.html
Work Name: build_apache-commons_commons-sanselan-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins 29 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/sanselan/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/sanselan]
M2_HOME: /opt/maven2
-
Running org.apache.commons.sanselan.formats.jpeg.exif.TextFieldTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.558 sec
Running 
org.apache.commons.sanselan.formats.jpeg.exif.WriteExifMetadataExampleTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.594 sec
Running org.apache.commons.sanselan.formats.jpeg.exif.ExifRewriteTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.418 sec
Running org.apache.commons.sanselan.formats.jpeg.exif.MakerNoteFieldTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.55 sec
Running org.apache.commons.sanselan.formats.jpeg.exif.AsciiFieldTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.1 sec
Running org.apache.commons.sanselan.formats.jpeg.exif.ExifDumpTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.516 sec
Running org.apache.commons.sanselan.formats.jpeg.exif.WriteTagsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.commons.sanselan.formats.jpeg.exif.GpsTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.469 sec
Running org.apache.commons.sanselan.formats.jpeg.iptc.IptcDumpTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.461 sec
Running org.apache.commons.sanselan.formats.jpeg.iptc.IptcUpdateTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.712 sec
Running org.apache.commons.sanselan.common.BinaryFileFunctionsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.sanselan.common.RationalNumberTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.sanselan.common.bytesource.ByteSourceImageTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.494 sec
Running org.apache.commons.sanselan.common.bytesource.ByteSourceDataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.112 sec
Running org.apache.commons.sanselan.color.ColorConversionsTest
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec <<< 
FAILURE!

Results :

Failed tests:   
testCMYKtoRGB(org.apache.commons.sanselan.color.ColorConversionsTest): {C: 0.0, 
M: 0.0, Y: 64.0, K: 64.0} expected: but was:

Tests run: 86, 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/sanselan/target/surefire-reports for 
the individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 2 minutes 28 seconds
[INFO] Finished at: Wed Dec 28 02:24:30 UTC 2011
[INFO] Final Memory: 34M/83M
[INFO] 
--

Re: [ALL][VOTE] Rename Commons Sanselan to Commons Image

[Sébastien Brisard]

>> Hello,
>> I am no native english speaker, but it seems to me that
>> commons-imaging would suggest image analysis tools, while (as far as I
>> know) sanselan is devoted to IO. In which case, maybe commons-imageio
>> would be better suited?
>
> Although you are possibly right with regards to the projects current
> state, I see no necessity to indicate restrictions in the name. So I'd
> consider "imaging" a perfectly valid name.
>
That's true, and if this project was to move to image analysis in the
future, I would happily contribute!
Sébastien

>
> +1 to that
>
> Jochen
>
> --
> “Morality is doing what is right, no matter what you are told.
> Religion is doing what you are told, no matter what is right.”
>
> H. L. Mencken (c.1925)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>


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

[GUMP@vmgump]: Project commons-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 305 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: 12 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.018 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 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.038 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.184 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 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.012 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: 11 seconds
[INFO] Finished at: Wed Dec 28 07:30:44 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.

[lang] 3.3?

[Henri Yandell]

Heads up that I'm thinking that 3.3 is ready to be released. 10 issues
resolved in trunk.

Hen

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

Re: [lang] 3.2?

[Henri Yandell]

Of course, I mean 3.2. :)

On Tue, Dec 27, 2011 at 11:46 PM, Henri Yandell  wrote:
> Heads up that I'm thinking that 3.3 is ready to be released. 10 issues
> resolved in trunk.
>
> Hen

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