2011/8/4 Ralph Goers ralph.go...@dslextreme.com
The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't
have anything to do with logging.
In fact I would have said a library in general that is referenced both in
the portal application and in portlets.
Anyway you're right, if
On 04.08.11 01:08, Rahul Akolkar wrote:
On Wed, Jul 27, 2011 at 3:54 PM, Rahul Akolkar rahul.akol...@gmail.com
wrote:
I cp -R'ed the site over, but it should be republished more gracefully.
Sorry for the delay, I still need to find the time to move the site to
Maven-2. Will re-publish when
Hello.
please review a proposal for the definition of general iterative linear
solvers, as well as the implementation of the conjugate gradient method. This
is file MATH-581-06.zip attached to the JIRA MATH-581 ticket.
Thanks for your comments!
Actually, I *do* have a comment. For the time
Hi Gilles,
I'm OK to define a new exception. From your PS, I understand that I should
wait until what I've already submitted (MATH-581-06.zip) has been committed
until I submit a patch containing the new exception. Is that right?
I don't think it's necessary to open a new JIRA ticket for this, do
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
On 2011-08-04 Stefan Bodewig wrote:
On 2011-08-03, Lasse Collin wrote:
I looked at the APIs and code in Commons Compress to see how XZ
support could be added. I was especially looking for details where
one would need to be careful to make different compressors behave
consistently compared
Hello.
I'm OK to define a new exception. From your PS, I understand that I should
wait until what I've already submitted (MATH-581-06.zip) has been committed
until I submit a patch containing the new exception. Is that right?
I would have thought the other way around: First commit the
Hi,
thanks for your answer.
2011/8/4 Gilles Sadowski gil...@harfang.homelinux.org:
Hello.
I'm OK to define a new exception. From your PS, I understand that I should
wait until what I've already submitted (MATH-581-06.zip) has been
committed
until I submit a patch containing the new
I'm OK to define a new exception. From your PS, I understand that I should
wait until what I've already submitted (MATH-581-06.zip) has been
committed
until I submit a patch containing the new exception. Is that right?
I would have thought the other way around: First commit the
Actually if you just reattach revised files using the original names Kira
will do a great job of managing which is the latest. That let's curious folk
go back in history if they want to see what has changed.
On Thursday, August 4, 2011, Gilles Sadowski gil...@harfang.homelinux.org
wrote:
I'm
2011/8/4 Gilles Sadowski gil...@harfang.homelinux.org:
I'm OK to define a new exception. From your PS, I understand that I
should
wait until what I've already submitted (MATH-581-06.zip) has been
committed
until I submit a patch containing the new exception. Is that right?
I would
Hi all,
ZIP64 support in trunk is almost complete except for a case that is
pretty easy to implement but where I'll ask for API feedback once I've
managed to read up on how the InfoZIP people handle it.
There are a few places where our implementation doesn't allow for the
full range the ZIP
[...]
The management of the exception messages through String constants and enums is
in my view a very clean thing. Should we do the same for exception context
keys? Have a big enum holding keys?
I'd rather not, but I'm afraid that others will think otherwise :-}.
Or should we define
ZipFile relies on RandomAccessFile so any archive can't be bigger than
the maximum size supported by RandomAccessFile. In particular the seek
method expects a long as argument so the hard limit would be an archive
size of 2^63-1 bytes. In practice I expect RandomAccessFile to not
support
On 2011-08-04, Lasse Collin wrote:
On 2011-08-04 Stefan Bodewig wrote:
This is in a big part due to the history of Commons Compress which
combined several different codebases with separate APIs and provided a
first attempt to layer a unifying API on top of it. We are aware of
quite a few
On 2011-08-04 Stefan Bodewig wrote:
There are a few places where our implementation doesn't allow for the
full range the ZIP format would support. Some are easy to fix, some
hard and I'm asking for feedback whether you consider it worth the
effort to fix them at all.
I guess that these are
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10905projectId=70
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 5 Aug 2011 03:37:19 +
Finished at: Fri 5 Aug 2011 03:37:58 +
Total time: 38s
Build Trigger: Forced
Build
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10929projectId=108
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 5 Aug 2011 03:58:35 +
Finished at: Fri 5 Aug 2011 04:00:16 +
Total time: 1m 41s
Build Trigger: Forced
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10931projectId=116
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 5 Aug 2011 04:00:33 +
Finished at: Fri 5 Aug 2011 04:00:49 +
Total time: 15s
Build Trigger: Forced
Build
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=10941projectId=206
Build statistics:
State: Failed
Previous State: Failed
Started at: Fri 5 Aug 2011 04:07:01 +
Finished at: Fri 5 Aug 2011 04:08:31 +
Total time: 1m 29s
Build Trigger: Forced
Looks like we have been experimenting with this. Before actually
turning anything on, we need should agree that we actually want to
to do this and probably VOTE, as I assume the generated artifacts
are going to be publicly available. My personal opinion is that we
should not do this.
Phil
We can hold a vote. I would be persuaded to vote no if someone could point to
an ASF or incubator policy that says we should not do this.
Ralph
On Aug 4, 2011, at 10:08 PM, Phil Steitz wrote:
Looks like we have been experimenting with this. Before actually
turning anything on, we need
22 matches
Mail list logo
