Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11237&projectId=129
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 14 Aug 2011 07:21:24 +
Finished at: Sun 14 Aug 2011 07:23:50 +
Total time: 2m 26s
Build Trigger: Schedule
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11238&projectId=129
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 14 Aug 2011 08:20:52 +
Finished at: Sun 14 Aug 2011 08:23:24 +
Total time: 2m 32s
Build Trigger: Schedule
On 12.08.11 08:41, Stefan Bodewig wrote:
> Hi,
>
> while looking through the Gump setup for JCS I realized the artifactId
> inside the POM had been changed to commons-jcs while the groupId still
> is org.apache.jcs. Does it make sense to keep the old groupId when
> you change the artifactId anywa
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-vfs2 has an issue affecting its community integration.
This issue
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
That was because the POM was still showing 3.0.1, and Continuum can
only deploy SNAPSHOTS.
I've update the pom to 3.0.2 SNAPSHOT, and the build now succeeds.
By the way, the build failures would not happen if release tags were
created from a new checkout, as the trunk would then always be in
SNAP
On 14 August 2011 10:38, Thomas Vandahl wrote:
> On 12.08.11 08:41, Stefan Bodewig wrote:
>> Hi,
>>
>> while looking through the Gump setup for JCS I realized the artifactId
>> inside the POM had been changed to commons-jcs while the groupId still
>> is org.apache.jcs. Does it make sense to keep
Le 12/08/2011 21:29, Oliver Heger a écrit :
On the [configuration] main site there is a link to old how-to documents
targeting the ancient version 1.2. As nobody is supposed to still work
with this version, I guess it should be okay to remove them. If there
are no objections, I will do this.
Th
On Aug 14, 2011, at 8:22, sebb wrote:
> That was because the POM was still showing 3.0.1, and Continuum can
> only deploy SNAPSHOTS.
>
> I've update the pom to 3.0.2 SNAPSHOT, and the build now succeeds.
>
> By the way, the build failures would not happen if release tags were
> created from a new
On 14 August 2011 14:34, Gary Gregory wrote:
> On Aug 14, 2011, at 8:22, sebb wrote:
>
>> That was because the POM was still showing 3.0.1, and Continuum can
>> only deploy SNAPSHOTS.
>>
>> I've update the pom to 3.0.2 SNAPSHOT, and the build now succeeds.
>>
>> By the way, the build failures wou
On Sun, Aug 14, 2011 at 9:41 AM, sebb wrote:
> On 14 August 2011 14:34, Gary Gregory wrote:
>> On Aug 14, 2011, at 8:22, sebb wrote:
>>
>>> That was because the POM was still showing 3.0.1, and Continuum can
>>> only deploy SNAPSHOTS.
>>>
>>> I've update the pom to 3.0.2 SNAPSHOT, and the build
Le 12/08/2011 21:17, Oliver Heger a écrit :
[configuration] still has build files for Maven 1. Any objections if I
remove them?
RIP Maven 1 :)
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For a
On 14 August 2011 03:02, sebb wrote:
> On 12 August 2011 20:56, Gary Gregory wrote:
>> Hello All:
>>
>> For a first cut at generics support in Codec, please checkout the
>> branch
>> https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
>>
>> I wrote a migration guide in the ro
I don't understand this failure. I've run the build with both Maven 2 & 3 and
it doesn't fail. The message it fails with is
[INFO] [jar:jar {execution: default-jar}]
[INFO]
[ERROR] BUILD ERROR
[INFO] ---
On 14 August 2011 14:47, Gary Gregory wrote:
> On Sun, Aug 14, 2011 at 9:41 AM, sebb wrote:
>> On 14 August 2011 14:34, Gary Gregory wrote:
>>> On Aug 14, 2011, at 8:22, sebb wrote:
>>>
That was because the POM was still showing 3.0.1, and Continuum can
only deploy SNAPSHOTS.
>>>
Me neither - try asking on builds@a.o
On 14 August 2011 15:29, Ralph Goers wrote:
> I don't understand this failure. I've run the build with both Maven 2 & 3
> and it doesn't fail. The message it fails with is
>
> [INFO] [jar:jar {execution: default-jar}]
> [INFO]
> ---
On Sat, Aug 13, 2011 at 10:02 PM, sebb wrote:
> On 12 August 2011 20:56, Gary Gregory wrote:
>> Hello All:
>>
>> For a first cut at generics support in Codec, please checkout the
>> branch
>> https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
>>
>> I wrote a migration guide
On Sun, Aug 14, 2011 at 10:32 AM, sebb wrote:
> On 14 August 2011 14:47, Gary Gregory wrote:
>> On Sun, Aug 14, 2011 at 9:41 AM, sebb wrote:
>>> On 14 August 2011 14:34, Gary Gregory wrote:
On Aug 14, 2011, at 8:22, sebb wrote:
> That was because the POM was still showing 3.0.1,
This is a vote to release Apache Commons VFS 2.0.
Since the last candidate the package name was changed from vfs to vfs2. Many of
the Jira issues were reviewed and those that required a possibly incompatible
API change were addressed. Most instances of StringBuffer were replaced with
StringBui
FastMath.java:1008 says:
* for extra precision (i.e. exp(x) = result[0] ° result[1]
The operator symbol is mangled (probably due to conversion between encodings).
I'm not sure what the operator should be - dot product perhaps?
To avoid further corruption, ideally the symbol should be rep
On 14 August 2011 15:47, Gary Gregory wrote:
> On Sat, Aug 13, 2011 at 10:02 PM, sebb wrote:
>> On 12 August 2011 20:56, Gary Gregory wrote:
>>> Hello All:
>>>
>>> For a first cut at generics support in Codec, please checkout the
>>> branch
>>> https://svn.apache.org/repos/asf/commons/proper/co
On 14 August 2011 16:25, Ralph Goers wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many
> of the Jira issues were reviewed and those that required a possibly
> incompatible API change were addressed. Most in
FWIW, the source zip has a dist folder with a pom.xml in it. Not a
blocker but should be fixed.
Gary
On Sun, Aug 14, 2011 at 11:25 AM, Ralph Goers
wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many
> of the
Yes.
On Aug 14, 2011, at 9:07 AM, sebb wrote:
> On 14 August 2011 16:25, Ralph Goers wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>>
>> Since the last candidate the package name was changed from vfs to vfs2. Many
>> of the Jira issues were reviewed and those that required a poss
When building the source distribution I get the following error:
Tests run: 975, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar {execution: default-jar}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
On 14 August 2011 17:09, Gary Gregory wrote:
> FWIW, the source zip has a dist folder with a pom.xml in it. Not a
> blocker but should be fixed.
I think that's intentional - it's the distribution module, which is also in SVN.
> Gary
>
> On Sun, Aug 14, 2011 at 11:25 AM, Ralph Goers
> wrote:
>>
Why? The source has a dist directory with a pom.xml in it. I thought the
source zip was supposed to capture what was tagged?
Ralph
On Aug 14, 2011, at 9:09 AM, Gary Gregory wrote:
> FWIW, the source zip has a dist folder with a pom.xml in it. Not a
> blocker but should be fixed.
>
> Gary
>
Interesting. That is the same error that Continuum reported. I have no idea
what it is and can't seem reproduce it on my MacBook. I will give it a try on
Ubuntu.
The surefire report will look strange. This is a multi-module project. You need
to go to the "Core" component to see real reports.
R
My mistake then.
Gary
On Aug 14, 2011, at 12:28, Ralph Goers wrote:
> Why? The source has a dist directory with a pom.xml in it. I thought the
> source zip was supposed to capture what was tagged?
>
> Ralph
>
> On Aug 14, 2011, at 9:09 AM, Gary Gregory wrote:
>
>> FWIW, the source zip has a
On 14 August 2011 16:25, Ralph Goers wrote:
> This is a vote to release Apache Commons VFS 2.0.
>
> Since the last candidate the package name was changed from vfs to vfs2. Many
> of the Jira issues were reviewed and those that required a possibly
> incompatible API change were addressed. Most in
FYI
Begin forwarded message:
> From: Dennis Lundberg
> Date: August 14, 2011 9:58:15 AM PDT
> To: bui...@apache.org
> Subject: Re: [continuum] BUILD FAILURE: Apache Commons - Commons VFS -
> Default Maven 2 Build Definition (Java 1.5)
> Reply-To: bui...@apache.org
>
> Hi Ralph
>
> The problem
Thanks, Sebb. See below.
On Aug 14, 2011, at 9:50 AM, sebb wrote:
> On 14 August 2011 16:25, Ralph Goers wrote:
>> This is a vote to release Apache Commons VFS 2.0.
>>
>> Since the last candidate the package name was changed from vfs to vfs2. Many
>> of the Jira issues were reviewed and those
On 14 August 2011 18:03, Ralph Goers wrote:
> Thanks, Sebb. See below.
>
> On Aug 14, 2011, at 9:50 AM, sebb wrote:
>
>> On 14 August 2011 16:25, Ralph Goers wrote:
>>> This is a vote to release Apache Commons VFS 2.0.
>>>
>>> Since the last candidate the package name was changed from vfs to vfs2
On Aug 14, 2011, at 10:09 AM, sebb wrote:
> On 14 August 2011 18:03, Ralph Goers wrote:
>> Thanks, Sebb. See below.
>>
>> On Aug 14, 2011, at 9:50 AM, sebb wrote:
>>
>>> On 14 August 2011 16:25, Ralph Goers wrote:
This is a vote to release Apache Commons VFS 2.0.
Since the las
On 14 August 2011 18:49, Ralph Goers wrote:
>
> On Aug 14, 2011, at 10:09 AM, sebb wrote:
>
>> On 14 August 2011 18:03, Ralph Goers wrote:
>>> Thanks, Sebb. See below.
>>>
>>> On Aug 14, 2011, at 9:50 AM, sebb wrote:
>>>
On 14 August 2011 16:25, Ralph Goers wrote:
> This is a vote to re
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11243&projectId=129
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 14 Aug 2011 18:20:44 +
Finished at: Sun 14 Aug 2011 18:23:13 +
Total time: 2m 29s
Build Trigger: Schedule
Looking at the code here: ServletWebContextTestCase:178,640,701
// Test putAll()
Map values = new HashMap();
values.put(new Integer(1), "One"); // <-- I want to delete
this line (elijah)
values.put("2", "Two");
map.putAll(values);
The test case is testing a
Le 13/08/2011 20:53, Oliver Heger a écrit :
Hi,
as you may have noticed, I have started some work in order to prepare a
release (version 1.7) of [configuration]. I assume this will be the last
release compatible with Java 1.4.
So the release after 1.7 would be the code on the 2.0 branch ?
I
Hi,
On Aug 14, 2011, at 10:19, sebb wrote:
> On 14 August 2011 03:02, sebb wrote:
>> On 12 August 2011 20:56, Gary Gregory wrote:
>>> Hello All:
>>>
>>> For a first cut at generics support in Codec, please checkout the
>>> branch
>>> https://svn.apache.org/repos/asf/commons/proper/codec/branc
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-vfs2 has an issue affecting its community integration.
This issue
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
On Aug 14, 2011, at 2:28 PM, Emmanuel Bourg wrote:
> Le 13/08/2011 20:53, Oliver Heger a écrit :
>> Hi,
>>
>> as you may have noticed, I have started some work in order to prepare a
>> release (version 1.7) of [configuration]. I assume this will be the last
>> release compatible with Java 1.4.
>
Hi.
I'm rather confused by the appearance of sparseness handling at the level
of a "general" vector (i.e. "RealVector", "AbstractRealVector") as well as
at the level of a non-sparse data structure ("ArrayRealVector").
This makes for a lot of convoluted code containing "instanceof" operators...
I
In the Mahout matrix classes, it turned out very important to keep some
notion of sparsity in the abstract matrix and vector classes. This allows
default implementations to make use of sparsity at a pretty non-specific
level which actually substantially decreases the amount of type reflection
that
I'm in favor of moving some methods to the SparseXXX interface, but got
voted down at the time. For application developers (like me), that can
expect in advance if the Vector/Matrix is sparse or not it isn't a big deal.
But I can see how it may cause problems for other libraries that want to
le
45 matches
Mail list logo
